The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
PURPOSE
=======
When you start a new trial of an app without demo data, you
want to have everything perfect and ready for your own configuration
closesodoo/odoo#122308
Taskid: 3328654
Related: odoo/enterprise#41423
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This PR :
- Adds 2 new default contract types to the data : Omnium and Leasing
- Lets the user search models by manufacturer name and model name
task - 3249291
closesodoo/odoo#117059
Signed-off-by: Kevin Baptiste <kba@odoo.com>
before this commit, in the list view of
fleet (fleet.vehicle),
services (fleet.vehicle.log.services) and
odometer(fleet.vehicle.odometer) the vehicle_id
and model_id field with many2one_avatar is
not showing the image of vehicle and model.
* open fleet -> fleet -> fleet
* switch to list view
* model field will be with empty image
* similarly in services and odometer menus
after this commit, the widget will be removed
from the field as the avatar field doesn't
exists in the model level.
closesodoo/odoo#117752
X-original-commit: e57b6f898775a0e432ae1a21266a0f4bf82c0242
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Minor usability changes:
* Reorganize menu to be more consistent with other HR apps;
* Tweak several views;
* Don't expire contract when date is set to Today - they will be
automatically expired the next day;
* Show contract name on form view.
closesodoo/odoo#92604
Related: odoo/enterprise#27919
Taskid: 2856135
Signed-off-by: Kevin Baptiste <kba@odoo.com>
There shouldn't be a distinction between full hybrids.
'hybrid' and 'full_hybrid_gasoline' are replaced in this commit by a unique 'full_hybrid'.
fixes task 2629318
taskID 2753096
closesodoo/odoo#90413
Related: odoo/enterprise#26886
Related: odoo/upgrade#3494
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
There was some confusion about all the types of hybrid vehicles.
Also changes the order in which they are displayed.
TaskId-2629318
closesodoo/odoo#82672
X-original-commit: 73171da60059c85355e8675061db485e84aedb05
Related: odoo/enterprise#23460
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Overall UI review of the fleet app.
Also changes the behaviour of shared fields between vehicles and vehicle
models.
Task ID: 2468228
closesodoo/odoo#72943
Related: odoo/upgrade#2601
Related: odoo/enterprise#19356
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Adds two new columns to the vehicle model tree view.
Changes the name of the vehicle model action.
Modifies the order by which vehicle manufacturers are ordered.
Adds filter and modify goupby on vehicle, vehicle model/brand.
Task ID: 2487706
Revamp the kanban view of fleet.vehicle.log.services.
Add some ux improvements (new filters, better naming,..).
Fix bug where contracts/services of archived fleet.vehicle were
not counted in statinfo.
When a fleet.vehicle is archived, archive its related contracts/services.
closesodoo/odoo#62556
Taskid: 2389823
Related: odoo/upgrade#2063
Related: odoo/enterprise#15036
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently, in Configuration > Service Type > Add a new service type.
The category field is mandatory but it does not appear on list view.
So in this commit, display the mandatory category field on list view
Currently, in Configuration > Manufacturers. The count of Models is
always 0 because the it's compute stored field without the depends
so not computed each time.
So in this commit, fix the count of models by adding a correct trigger
closes odoo/odoo#55475
Taskid: 2296851
Closes: #54515
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently when user change the image on a vehicle, it change it
for the car manufacturer and the goal of this image is to recognize
the manufacturer of the vehicle.
After this commit is applied, the model and vehicle image will be
fixed as per the selected brand image. user will not be able to
change from the vehicle and model.
closes odoo/odoo#44153
Taskid: 2168922
Closes: #44153
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
It is currently difficult to know exactly what is used for costs
and services on the contracts.
Hence it make it difficult to evolve the fleet application
We should clean the models in order to have something that is clearer
Specification
=============
Cleanup of models: removed Fuel and Cost. Contract and Services are no
longer inheriting Cost and are seperate models simplifying the use of
Fleet. A contract now has included services and they are no longer
generating cost.
closesodoo/odoo#34090
Taskid: 1931775
Related: odoo/enterprise#4572
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The big images are probably never going to be used for the following models:
- pos category
- fleet brand
- livechat channel
- mail channel
- payment acquirer
And if big images are needed some day the model should use image.mixin instead.
PR: #34925
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Basically when someone requests a new car, getting that car ready takes
some time, this means that during the waiting period, that person is
still driving its old car.
This commit adds a field future_driver_id on fleet.vehicle to tackle
that problem and a boolean plan_to_change_car on the partner to track
who wants to change car.
+ Apply some linting to the files
This commit cleans the vehicle form view, the vehicle contract form
view, the cost list view and adds a manager_id field on the
vehicle.model which is then used as a related on the vehicle.
Task: 1930298
closesodoo/odoo#31197
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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.
Rémy Voet (ryv)