When a max weight is set on a packaging type is set, you get a warning
when you put in pack some content that weighs bigger than the max weight
of the packaging type
Several addons inherit from message_post method. Instead of redefining
the long list of parameters let us just use kwargs and propagate them to
the super call. Only really used parameters are set as explicit.
Purpose is to lessen issues when changing some parameters default value
or when having some API change.
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
Currently even module logs a message in all employee channel with a
message telling the module has been installed. It is not interesting
as it gives no real information and is not interesting for users that
do not use event module and/or do not have access to it.
Let us remove that data.
When reinitializing modules it is impossible to create partners if
sale is installed because sale_warn field has a required column
but no default value if the module does not depend from sale. Use
case is trying to run test_mail tests with sale installed.
As this field is not business critical it is now not required. As there
is a default value behavior should not change for users.
See also dd47abdcc3 and 06a02ae4c2.
Indeed message_post uses only keywords arguments. Let us therefore use
them when calling the method. It will lessen number of issues if someday
the argument order and/or the API of message_post changes.
It probably comes from old medium-like-stuff comment management that has
been removed since. Discussion on blog posts is now a simple chatter
and does not require all those controllers.
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
Allow to alter the behavior by introducing preparation methods that can be overwritten.
Partial merge of PR #16093, from an original idea and commit of David Arnold (XOE Solutions)
Fabien Pinckaers