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.
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
This commit improves fleet contracts management through a better integration
of activities and addition of automated activities. Several things are done
in this commit :
* fleet vehicle log contract does not inherit from mail.activity.mixin.
This commit adds the inherit so that fleet users and managers can now
schedule and manage activities on vehicle contracts. This will help them
in their daily job;
* automatic activities generation is added when contracts are nearly expired
and renewal is required;
* a menu to configure activity types is added. Indeed fleet managers should
be able to see and configure activity types related to their job;
* filters are added to be able to use the systray and to filter the kanban
view based on activities
Having automated activities allow to replace some messages posted on the
contract. Indeed currently there are messages posted on vehicles about
contracts to renew. As we now have automated activities on contracts to
remind assigned people to renew it the log can be safely removed. It will
lessen noise generated on chatter.
Currently there is no place to indicate who is responsible of managing
fleet contracts. As we plan to integrate activities to fleet app having
responsible to push notifications is necessary.
This commit adds a responsible field following Odoo convention, aka a
user_id field linking res.users records. It is also added on the view.
Currently a note is posted on the fleet with 'name has been added to
the fleet'. It is not really interesting as it is no notified to
anyone and it makes some noise. Let us therefore fall back on the
standard behavior.
Steps to reproduce the bug:
- Go to Fleet
- Group by status
- Click on a vehicule
- Click on Costs
Bug: A traceback was raised because a group_by was made on the model "fleet.vehicle.cost"
for the field "state_id" and this field doesn't exist on this model.
opw:1815454
New feature:
- New Transparent tag visual (grey border & text, white bg),
- By default, newly created kanban tags are transparent,
- Tag's colorpicker has now a 'Hide in Kanban' checkbox,
to select the transparent color.
Toggling off 'Hide in Kanban' sets the color of the tag as follow:
- Previous color, if 'Hide in Kanban' was toggled on on the
same formview session.
- Color 1 (dark orange), otherwise.
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
Purpose: Improve fleet for a better usability
Dashboard:
- Replace 'leasing' button by a contract status icon in kanban tiles
- Add a link to contract
- Link to vehicule form when clicking on the tile
Vehicle form:
- Track contract status in a chatter
- Add a model_year
Contracts:
- Imporve the states names
- Split service types in two list views service/contracts
- Execute a cron once a day to upgrade contract status
- Add a new contract status is introduced 'Expiring Soon' to help
spot contracts that will expire until 15 days with a filter.
- Add a 'group by vehicle' to improve list usability
Fuel logs view: Add an an odometer column
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
Yannick Tivisse