- Create a contract for a vehicle
- Renew the contract and set old one to closed
- Run the cron 'Fleet: Generate contracts costs based on costs
frequency'
The closed contract is reset to expired.
The contract should remain closed.
opw-1949470
closesodoo/odoo#31974
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If fleet.vehicle_state_active is not found in the system then the method
will raise an error, hence it won't allow creating any fleet.vehicle
closesodoo/odoo#30925
Instead of searching for the driver name and return thousands of partner
ids in the vehicule search, use a database join and a search on the
driver name.
closesodoo/odoo#29288
The _name_search did override the domain's search
by OR'ing it with a loose condition on the driver_id.
As a result if an upstanding Odooer added a strict filter on the driver_id,
it was ignored in favour of the loose one.
opw 1915639
closesodoo/odoo#29515
Specification
=============
- Adapt the formula used in the code with the current legal value.
- Add the LPG fuel type in standard fleet module.
- Adapt the atn furmula in the code with the current legal value.
closesodoo/odoo#29833
Purpose
=======
An alert is sent when the vehicle contract will be outdated in less than a month.
This could be a parameter than could be set on the res.config.
Specification
=============
Use ir.config.parameter in all the cases
Default value is 30 days
Consider 'diesoon' contract as an 'in progress' contract
closesodoo/odoo#29704
Purpose is to clean the use of tracking parameters on fields. Parameters are
merged and is now tracking=<int> or tracking=True.
This commit is linked to task ID 1903814 and PR #28430.
Check that it makes custom binary fields into attachment as that's the
main reason for the change: when users create binary fields via Studio,
they're necessarily db-stored (as the interface doesn't allow altering
the attachment attribute and it's unclear how we'd handle users
switching it on/off every time), which significantly bloats their
database (and burns storage & backup space), especially as the primary
use case for binary fields is adding images and documents to records.
* check that binary fields are properly created as attachment=True
* add attachment=False on fields where that seems relevant (most but not
all of the fields previously using the default)
* remove occurrences of attachment=True
closesodoo/odoo#29308
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Purpose of this commit is to improve automated activities in fleet.
Currently they are not always updated or rescheduled. Specifically when
updating the expiration date or the responsible automated activities should
be updated accordingly.
This commit is linked to task ID 1838956 and PR #25899.
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Add grouping possibility on model make for vehicles in the fleet.
Deleted redundent controll on make image for vehicles if model changed.
fixed _name_search for FleetVehicle
project : RD for Dummies
task : [Fleet] Allow to filter/group by Make on vehicles
Purpose
=======
We can not get the list of vehicles who have been assigned to a driver.
Specification
=============
The user is able to get the list of the vehicles assigned to a specific driver, by searching the driver's name with the "Assigned to" filter.
Purpose
=======
The method _name_search and _search add support to search as another user.
All the overrides of name_search and search redefine the behavior of the search.
This bring inconsistencies as the result of a call to _name_search and name_search
could differ on certain modules, which is not acceptable.
Specification
=============
Example:
~~~~~~~~
If the name_search method is overridden to search also on the driver name,
then calling name_search with a label 'JF' will return all the cars with a name containing
'JF' or all the cars with a driver name containing 'JF'. Let's say that we have a ir.rule
preventing a user to read the cars of another company. Then the call to name search only returns
the cars satisfying the previous condition AND belonging to his company.
Now, we want to overpass this constraint. We call _name_search with the attribute name_get_uid=1.
Then the call to _name_search returns all the cars from all the companies with a name like 'JF',
but nothing is done about the driver_name.
Example of wrong search redefinition on a model
-----------------------------------------------
@api.model
def name_search(self, name, args=None, operator='ilike', limit=100):
domain = args or []
domain = expression.AND([domain, [('name', 'ilike', name)]])
partners = self.env['res.partner'].search([('name', operator, name)])
if partners and name:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partners.ids), ('driver_id', '=', False)]])
rec = self.search(domain, limit=limit)
return rec.name_get()
Example of correct search redefinition on a model
-------------------------------------------------
@api.model
def _name_search(self, name, args=None, operator='ilike', limit=100, name_get_uid=None):
domain = args or []
domain = expression.AND([domain, [('name', operator, name)]])
partner_ids = self.env['res.partner']._search([('name', operator, name)], access_rights_uid=name_get_uid)
if partner_ids:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partner_ids), ('driver_id', '=', False)]])
rec = self._search(domain, limit=limit, access_rights_uid=name_get_uid)
return self.browse(rec).name_get()
The same logic should be applied on the overrides of the search method.
1/ Use track_visibility instead of overriding write method on a fleet.vehicle
Instead of posting messages in the write method to notify that the record value
changes, use the attribute track_visibility='onchange' instead.
2/ Add track_visibility='onchange' on some fields
3/ Track visibility on 'recurring_cost_amount_depreciated'
Purpose
=======
Currently it's impossible to know who was driving a given car at a given time.
We have some piece of information like the immatriculation date of a vehicle
or the date of the first contract. But it's not enough.
This is problematic to solve a rather common issue:
- Who is gonna pay the fine for having exceeded the speed limit?
Specification
=============
Introduce a simple model fleet.vehicle.assignation.log, containing info about:
- The driver
- The vehicle
- The start Date
- The end Date
A simple button on the fleet vehicle should be sufficient to solve the issue.
We cannot generate data from the salary package as these dates can't be predicted
at the contract signature.
The goal of this field is to be able to keep the value of the first contract
even if it has been closed/deteled.
It could be used to compute the depreciation of the car.
Christophe Simonis