Since we got 2 constraints checking the same
thing (one python, one sql), it is better
to remove the python one, which is not
very performance friendly in case of huge
import.
When importing big amount of data, user can import
a list of uom. There is no constraint in Odoo to
force the factor to be equal to 1.0 for the reference
UoM in a category.
Onchange is not enought to ensure that constraint,
so this commit adds one in SQL for data intergrity
and to avoid problem in '_compute_quantity'
method.
Time UoM are almost Master Data for timesheet modules.
Some user remove those before installing timesheet modules, making
it impossible and crashing (as some field required a time UoM to be
set at installation).
Since we don't want to hardcode xmlids of 'Hours' and 'Days' time
UoM, we rather prevent the deletion of such UoM in the system.
The UoM can be desactivate to avoid having plenty of them in system
in use.
Task #39079
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
When converting UoM, the conversion can fail if the source and destination
uoM are not in the same category. By default, and error is raised, but using
a context key, we can receive the initial quantity.
To avoid the context key (which is not used anymore), we prefer use a dedicated
parameter to be more explicit.
Users can configure multiple references in a same
category. This might cause problems during conversion
and does not make sense.
Since this is a "late" constraint, we define it in
python to avoid conflict with existing data.
We allow user to have multiple unactive reference, but
force to have exactly one active. So when a new UoM
category is created, user have to encode the reference
unit first, and then the bigger/smaller ones.
This commit also update stock tests, since they were
redefining new reference UoM in the same category, and
finally, this commit provides some tests for this
uniqueness and custom UoM behavior.
Task #1820076
In order to restrict some uom field to some uom category, it is required to
add a measurement type on uom.category. Also, this will lessen the use of
master data.
Some technical justifications:
- measure_type is not required, to allow people creating their own
uom.category. Those ones will not interfere with addons business.
- measure_type is unique: we restrict to only one category containing
time, weight, ... in order to avoid mismatch category during conversion.
(2 different weight categories can not be converted).
- measure_type on uom.uom is stored: to allow search and domain on
field, we need to store it. Usually, UoM are not updated every day,
and the number of uom in a database is not that important.
To illustrate this mecanism, a domain is added on
'project_time_mode_id', in project module. This field
is use as timesheet default uom, and we obviously want to
restrict it to time category (timesheeting in liter does
not make sense ...)
Task #1820076
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
jem-odoo