Log an info when a field is computed and stored, but not all its dependencies
are stored. Also allow to set explicitly `depends` on a field; this is useful
to restrict the dependencies of a related field.
In other words, when a field F depends on a non-stored field G, it also depends
on G's dependencies. This guarantees that whenever a dependency of G is
modified, F will be invalidated and marked to recompute (if necessary).
The transitive closure of dependencies is not computed over stored fields.
Anyway stored fields already trigger the recomputation of their dependent
fields during their recomputation. The performance impact on the loading of a
registry is negligible (less than 1%), and the increase of recomputation
triggers is small (less than 10%).
Assuming that `field.cache_key(record)` is independent from `record.id`,
compute the cache key once for all records, and avoid using `browse` on all
record ids. This makes `get_records` about 20 times faster.
This has a good performance impact on `field.modified_draft()`, which is used
during onchanges for invalidating fields.
As this class has grown a lot some methods have been put a bit anywhere
in the file. To prepare future improvements it is easier to regroup
them a bit.
remove_accent from mail_alias is also moved to tools in order to separate
tools from business or class specific code.
Current behaviour when duplicating a record:
apply copy override in the user language (e.g. "%s (copy)")
copy the previous term in all the other languages (including)
So if product was named:
cheeses (en)
kaas (nl)
fromage (fr)
Duplicating the product, while in French, will result into:
cheeses (en)
kaas (nl)
fromage (copie) (fr)
This is a problem if there is a unicity constrain on the field, it will be
raised (there is already a product named 'cheese')
After this PR:
Duplicating the product, while in French, will result into:
fromage (copie) (en)
kaas (nl)
fromage (copie) (fr)
This applies **only** if there is an override of copy
This is detected by comparing the old and new value for the user language
Fixes#7010Closes#22052
When having an automated action which
triggered upon changing a field to write on another
(no python code, but operatiing with ir.server.object.lines)
Before this commit, the onchange was not performed.
This was because there was no active id
(in fact the code did not take object(<NewId>) into consideration)
After this commit, the onchange is performed.
OPW 801424
Added Unique Entity Number (UEN) to company and partner to use them in the IRAS Audit File (l10n_sg_reports)
Changed vat_label on Singapore
Added new taxes (2019)
Fixed the Chart of Account (account codes and types)
Added 'Permit Number' and 'Permit Number Date' on invoices
This will avoid unique constrain to be raised in the scenario of a record having
multiple ir.model.data entries to the same record.
This can be reproduced in standard with the following scenario
1. The product.template product_product_4_product_template has multiple variants
product_product_4
product_product_4b
product_product_4c
...
2. At the creation of the records, ir.model.data are automatically created
product_product_4_product_template
product_product_4b_product_template
product_product_4c_product_template
...
While this could/should be fixed too. Having several ir.model.data to the
same record is not forbidden and could be reproduced in different ways.
3. Export the translations
#. module: product
#: model:product.product,description_sale:product.product_product_4
#: model:product.product,description_sale:product.product_product_4b
#: model:product.product,description_sale:product.product_product_4c
#: model:product.template,description_sale:product.product_product_4_product_template
#: model:product.template,description_sale:product.product_product_4b_product_template
#: model:product.template,description_sale:product.product_product_4c_product_template
msgid ""
...
As the field description_sale is present on both model and is translatable
4. Load a .po file with these translations
The 3 product.template entries points to the same record, making the unique
constrain raise an error
This error can also be reproduced with the project_time_mode_id_duplicate_xmlid
field creating two xmlid for the same ir.model.fields
Closes#21472
Previous to this commit, we try to load as many fields as possible
during module installation, however sometimes some fields are not ready
to be loaded, which is the case for custom monetary fields, thus when
trying to find the current model's currency_id field it would not find
it at all, generating an assertion error.
This commit changes this by completely skipping monetary fields if they
are not ready to be loaded.
OPW 787223
In many2many lists, the remove record from the widget is a trash bin.
It is confusing, as people feel they are deleting it when they are
only unlinking it.
So in many2many, we propose to change the trash icon by a 'X'.
This icon appears in many2many relations and in many2many widgets:
even though hr.expense.sheet defines the expense lines as a one2many,
it uses a many2many widget, so we use a 'X' instead of the trash bin.
To avoid ambiguity, we decided to rename 'delete' to 'remove'.
Specification
=============
When user is creating a new company (in a multicompany environment), by default, he should have access to this company.
Also, do not allow to create new company from allowed companies dropdown
Christophe Simonis