This removes the measure_type field which has become unused and
causes issues when users try to add new uom categories.
Task-2043927
closesodoo/odoo#41056
Related: odoo/enterprise#6945
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Parentheses in the label of units of measure sometimes make
reading needlessly uncomfortable.
Specification
=============
Remove parentheses in the name of every standard uom.uom and hardcoded
occurence on views/field names.
TaskID: 2030444
closesodoo/odoo#34492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This reverts commit 43d51466c8.
Reasons:
- too complex having 2 UoM "Hours"
- impossible with UoM to modelise month: is that 30 days or 31 ?
Task-1971491
closesodoo/odoo#34497
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit introduces the duration (time) units of measures, flagged as internation
unit of measure. We already have the "working time" UoM, but those ones are customizable
and might differ from the International System of Units; indeed, one working day means
8 hours (more or less) for some company.
The rational here is, when we are handling datetime, we need to get the UoM in the Odoo
System to convert the result; for instance, computing the difference between 2 datetimes
will return the number of days (or hours). But you need to match it with an odoo UoM to
extract informations from that value.
This unit of measure 'duration' is like a master data, because existing in the real world
and that many module will depend on.
Task-1971491
closesodoo/odoo#32840
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit rename the measrurement_type 'time' into
'working_time' to be more precise, as time might means
duration.
This changes prepare the distinction between 'working time'
and international duration unit.
Task-1971491
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.
jdoutreloux