* web, website, mass_mailing
Before this commit, the editor allowed defining the margin of some
elements and the height of some elements. There were three main
problems with this system:
1) When an user dragged the arrow, he often expected to change the
size of the element while he was in fact changing the margin
2) When changing the margin, you increase the space between two
elements but with a white space (while most users want a space
with the same color of the block they are resizing = padding)
3) When changing the height, the user was able to hide snippet parts
and the height was not consistent accross screen sizes
Now, the only thing you can edit is padding. There is only one arrow
for each direction, which allows increasing spacing and consistent
dimension at the same time.
The only feature that is lost with this change is the ability to
control vertical alignement of colored columns. This is not a problem
as colored columns are rare in our current snippets and there still
have the possibility to add margin classes by hand if necessary (there
are also plans to control vertical alignement another way).
Note: margin classes are kept for compatibility.
When reinitializing modules it is impossible to create partners if
purchase is installed because purchase_warn field has a required
column but no default value if the module does not depend from
purchase. Use case is trying to run test_mail tests with purchase
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 71181a0e39, dd47abdcc3 and 06a02ae4c2.
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)
qsm-odoo