Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@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
ZeroDivsionError: float division to Zero is generated because for assigning
value to 'factor' of uom in method '_set_ratio', it tries to divide value by
Zero for uom_type 'Bigger'.
Steps to reproduce:
1) Install 'Inventory' module.
2) Click on 'Configuration' > 'Settings'.
3) Activate 'Units of Measure' > click on 'Units of Measure' button under it.
4) Click on 'Create' button to create new uom category.
5) Give any name > in 'Units of Measure' page, click on 'Add a line'.
6) Enter name and select type as 'Reference unit of measure for this category'.
7) Now, add another line and select type as 'Bigger than the the Reference unit
of measure' and set the 'ratio' value to Zero, Error will be generated.
By applying this,it will check for the value of 'ratio' to prevent division by 0
sentry - 4174584503
closesodoo/odoo#122680
X-original-commit: b79e5afeba7f9517e0325a7a4f9b2373bf5317ed
Signed-off-by: William Henrotin (whe) <whe@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>
Steps to reproduce the bug:
- Create a user with only "Inventory/Administrator" access right
- Connect with this user
- Go to Inventory/Configuration/UoM Categories
- Try to add/delete/change any unit of measure in any category
Problem:
an access error is triggered `You are not allowed to access 'Model Data'
(ir.model.data) records.`
opw-2905840
closesodoo/odoo#96137
X-original-commit: 8e58feb6e6151db8e47af4f296d5eb552532cb29
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create new UOM categories
- Add a new reference UOM
- Add another line, for example:
- type: “Smaller than the reference”
- Ratio: 4
- Click outside the line
Problem:
The type is changed to “Bigger” and the ratio is reset to 0,
because we are trying to change the type and the factor based on the value of the current uom factor,
but as this factor has not yet been calculated in `set_ratio` the changes will be distorted.
This part of the code in the onchange is useful when for example we already have a UOM category saved,
and we change the reference, in this case all the UOM will have to be calculated again
Solution:
Don't change the factor and the type in the onchange if it's a new line
opw-2754303
closesodoo/odoo#85214
X-original-commit: daf0dd44345de9877e2e79035d05ddca6c19064b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, the user was able to change the UoM type from
"Reference Unit" to "Bigger" or "Smaller" and let an UoM category with
no reference.
So, to force UoM category to have at least one Reference Unit, the user
can't change the reference unit if there is no other unit set as
reference.
task-2581265
Part-of: odoo/odoo#74695
This could save some time when `_compute_quantity` is used thousands times in
request and there are thousands UOMs in the system
* if qty is zero, then result is zero
* if to_unit is the same, then result is `round((qty / factor) * factor) = round(qty)`
---
opw-2549026
closesodoo/odoo#72582
X-original-commit: a122db226cdf801675daaee5a69bcb47a47ab174
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
1) forbid deletion of main uoms & categories
2) warn modifications of main uoms data.
Except for the working Hours uom, which isn't a strict UoM
representation and could change between countries (and/or be deleted).
3) Also move the Dozen UoM to demo datas, it's a confusing UoM and isn't
used by the majority of databases.
4) Restrict deletion of used uoms on main models.
On sale orders and account moves the uoms couldn't be deleted thanks to the
SQL constraint covering the display_type logic, but the generic error message
is more clear for a user when deleting an uom.
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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>
Edit the liters uom (default in its category) and change its category to
unit. You now have two references uom in the unit category. Try to set a
third one and now it fails.
This was because the constraint is implemented with an sql query but
since the new ORM the update in database are delayed. We force a
database update with flush so that the query gant get all the
informations it needs.
closesodoo/odoo#41621
X-original-commit: 68ced7972db64b22a4ff031bba0f78c06a88372d
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
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'`
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>
What's the deal with SQL queries?
The query in _check_category_reference_uniqueness returns:
category_id | uom_count
-------------+-----------
(0 rows)
but if we removed AND U.active = 't', we would have had:
category_id | uom_count
-------------+-----------
8 | 0
(1 row)
As a result, the check on uom_data['uom_count'] == 0 could simply never be true.
opw 1959679
closesodoo/odoo#32788
Signed-off-by: Nans Lefebvre (len) <len@odoo.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
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.
Xavier Morel