STEPS:
* Create a BoM with two components purchased the same vendor, but with
different "Delivery Lead Time". First component must have lower value
* Create Manufactoring order, Mark as ToDo
* Open created purchase order
BEFORE: Order Date is equal "MO planned day MINUS delivery lead time for the first component"
AFTER: Order Date is equal "MO planned day MINUS maximum amout delivery lead
time for the components"
---
opw-2388031
closesodoo/odoo#62411
X-original-commit: 8f0cc3609ce7a02d0e3f39586a7b0299ab221d48
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When some bills are not paid, some with due date, some without, when registering the payment of these bills as a group payment with checks, it is not possible to print the check
To reproduce the error:
(Need account)
1. Go to Invoicing > Vendors > Bills
2. Create a new one
- Add at least one line
- Add the Payment Terms
3. Save & Post
4. Duplicate it, then Save & Post
5. Go back to Bills
6. Select the two bills
7. Click on Action > Register Payment
8. Select Checks, enable Group Payment
9. Click on Create Payment
10. Click on Print Check
11. Click on Print
=> An Odoo Error is raised
The user should be able to print it.
OPW-2389368
closesodoo/odoo#62391
X-original-commit: 4dc4dc3d20114bea54266d97de29565a1a1ac230
Signed-off-by: adwid <adwid@users.noreply.github.com>
Before this commit the dropzone was relative to div.content. This would create
some bad position where the dropzone was covering the form view but not the
chatter.
task-2389929
closesodoo/odoo#62402
X-original-commit: bb650a9a1f4ff8280bd1e3467624991bc87517b9
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Fields `views`, `closed_reason_id`, `closed_uid` and `closed_date` should not be copied while copying post.
closesodoo/odoo#62401
X-original-commit: d35acd37720e8f498f5eef319c50780eaa7cb72e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit the close button cross/multiply character was wrongly
translated in some languages (e.g. Spanish)
After this commit the close button cross/multiply character is not a
translatable text anymore
https://github.com/odoo/odoo/pull/60268
task-2365792
closesodoo/odoo#62400
X-original-commit: 517e272da81e4f5ad958d896a75d4f32b44083e5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Followup on 911ada2d02b24778435fd9174441a6834da2effa
When modifying the company_id of a pricelist, the check to ensure a website
has a pricelist available wasn't triggered.
This commits ensures the Each website has Valid Pricelist with Correct or
Empty company.
Fixes#50707closesodoo/odoo#62359
X-original-commit: f196430baa8c5e2ce403808adc26d90fe84665fa
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The 'On Hand' button triggers action_open_quants on product model. It
do not explode the kit into its component
closesodoo/odoo#62390
X-original-commit: 49b965eb1ec6a7ec6c07fa643cc6ae35ee8b5d91
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
It is better to use another naming than re-using class names. Somehow it
seems sometimes we have MRO issues.
Task ID-2390314
PR odoo/odoo#62384
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As default is called numerous times with sometimes all fields, sometimes
only one field we have to ensure we avoid computing and setting unnecessary
or wrong values. We suspect this comes from default_get being called more
often at creation time since Odoo v14.
Default values for some fields in mail composer are dependent on each other.
Especially composition mode and model / res_id(s) are important for some
fields as behavior is not the same in comment or mass mail mode (subject
set / not set, template values rendered / displayed raw, ...).
Especially subject is wrongly computed in mass mail mode. For example use a
mass mail composer action on leads without template. Indeed a default_get
is called on subject alone. As web client adds active_model / active_id
automatically default returns a value for subject while it should not as
other values (model, res_id) are not asked and therefore not correctly
computed. It makes composer compute values in comment mode while it should
stay in mass mode.
In this commit we fix that behavior by
* computing only requested values (better match returned values and asked
fields);
* avoid computing values if context values are not given (model, res_id or
res_ids, composition_mode);
Task ID-2390314
PR odoo/odoo#62061
X-original-commit: 1c8ca358d75c9fe00631731d5061674c0a3a040b
Some tests are currently dependent on bus state when computing number of
notifications sent. For example install Crm then test_mail_full. Some
tests crash as too much notifications are found in the bus.
We therefore clean remaining bus notifications before running tests to
ensure we check notifications during test itself. This make tests more
easy to reproduce.
Task ID-2390314
PR #62061
X-original-commit: 92ff1379b0492765fd0ba9863a9ce13fba7eeb4a
Purpose is to have some low level tests for composer itself allowing to
ensure its behavior. We add tests notably about default values computation
in mass mailing mode as well as template_id change and values synchronization
in composer model.
In a near future composer will probably be improved (use computed fields,
rewrite part of its logic to improve performances). Having tests done before
those tasks ensure we notice every change that might happen.
Task ID-2390314
PR odoo/odoo#62061
X-original-commit: def98d2375a8a906092293f0aa1ce03bf948d2d3
During a return the purchase_order_line field is propagate, order_line.move_ids include returned move, that why use returned_move_ids is not mandatory.
closesodoo/odoo#35878
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
For this case, if the invoice currency is different from the invoice company currency, the tax calculation is considered the value in a different currency, and the subtotal is the sum of the amount untaxed + the taxes (wrongly in company currency) result in an incorrect value. This is verified when printing the invoice report
closesodoo/odoo#62388
X-original-commit: 91f152f479923a1d28dadcb3ded7c0296cc585fc
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit the navigation toolbar was accessible after selecting
a theme before the editor was opened, which on slow connections made it
possible for users to leave the screen and miss the tour
After this commit the loader animation of the theme installation is
blocking the access to the screen until the editor is opened thus
preventing user to navigate elsewhere before seeing the tour
task-2387608
closesodoo/odoo#62029
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit makes it so the quantity of a SN in a location is now
restricted between -1 < quantity < 1 (previously it was only quantity <
1). This change provides stronger protection against a duplicated SN
(e.g. a quantity of -2 means that the SN was somehow moved from that
location twice). This restriction was also relaxed to not include
location.usage='inventory' because this could prevent the user from
fixing a duplicated SN (since they were prevented from creating a
quantity of 2+ in an Inventory Loss location).
closesodoo/odoo#59834
Task: 2336455
Related: odoo/upgrade#1839
Related: odoo/enterprise#14667
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add a new feature to automatically create/update/delete an inventory by
company for products with conflicting serial numbers. The goal
of this is to help track inventory discrepencies and prevent duplicate
serial numbers across different locations.
This follows the same logic as the negative qty count auto-inventory
feature where a dupe SN inventory will be auto-generated / auto-updated
/ auto-deleted when the "Inventory Adjustment" button is pushed and when
the scheduler is run. Note that -1 quantity of an already in use SN
counts as a duplication of a SN.
Note: a new many2many field `lot_ids` was added to inventory to more
easily track which conflicting SNs to do the inventory on.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to automatically create/update an inventory per
warehouse specific to products with negative qty in any of its
locations. The goal of this is to help track inventory discrepencies
and prevent appearance of being out of stock when there is still stock
left. This is done by having the inventories update/create whenever
the "Inventory Adjustments" menuitem is clicked. Since we don't know
when a product's stock becomes non-negative, we always re-write all the
neg products to existing draft neg inventories and remove any
pre-existing draft inventories that haven't been updated since they no
longer have any neg qty products anymore.
Scheduler will also trigger this recalculation in hopes that it will
reduce having a large number of inventories to create when the inventory
menuitem isn't opened very often.
Note: a flag `is_conflict_inventory` was added to avoid conflicts with
manually generated inventories.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to allow automated (as part of scheduler) generation
of inventory adjustments based on user set value for how often they should
be done for 'internal' and 'transit' locations.
- When is the inventory created?
When cyclic frequency is set to a non-zero value, the next date an
inventory should be automatically generated for a location is based on
whether or not a previous inventory for that location was completed.
If an inventory is overdue based on the previous inventory date, one
will be scheduled for tomorrow. If no previous inventory date exists,
schedule the next one based on today's date. A new inventory will be
created by the scheduler if there is not an existing in progress
inventory for the location (to avoid a conflict).
- What about descendant locations?
Descendent locations will not have an inventory created if their
ancestor is supposed to have a cyclic inventory done at the same time.
Note this includes when that ancestory already has an in progress
inventory and isn't having a new one created.
- What about cleaning out of date cyclic inventories?
This automation will also delete existing draft inventories that include
this location (created before the day the scheduler is run) or any of
its descendants (i.e. inventories with only that descendant location
selected to avoid deleting obviously manually created inventories).
Task: 2336455
Upgrade PR: odoo/upgrade#1839
Prior to 28762b79e3, `_enableButtons`
method is mainly called after saving changes in the record,
now, it is also called when discarding such that its argument can
become `undefined`. This causes error in pos.config form because it
uses a custom form which hooked to the said method in order to
reload the window when a module_ or group_ field is modified.
This commit prevents this error by having a fallback empty array
when `changedFields` is `undefined`.
closesodoo/odoo#62366
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a product P with purchase UOM = Unit
- Let's consider a UOM called Box such as 1 Box = Units
- P is invoiced according to its ordered quantity
- Create a PO for 1 Box of P and confirm it
- Create the bill B from PO
Bug:
The quantity of B was 10 and its UOM was Box
PS: When creating a bill from a PO, by default the quantities on the lines of B are always expected
in the UOM of their respective PO line
Introduced by: https://github.com/odoo/odoo/commit/d0455ae64ba3800c8a13c60c6b68a5638ed5d552
opw:2391243
closesodoo/odoo#62356
X-original-commit: 669d1ee563ad123a1db417306191c670ea741925
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Since commit https://github.com/odoo/odoo/commit/3ad4abe171e8e7e86ed0e7b7f000e734d8a2ad92
the default invoicing policy of a product is set to 'delivery'. This is
not ok for the delivery products: a delivery product is never delivered.
This is confusing to end users, because they do not realize that a
delivery line is not included in an invoice. This is especially true if
the delivery is free.
This commit sets the default policy to 'order' for master data and for
newly created products from the shipping form view.
opw-2387437
closesodoo/odoo#62357
X-original-commit: 4c2768846809f6687d03eb0d7f501e57c2c93a90
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On a mobile, when editing a transfer operation, it is not possible to create a new lot/serial number.
To reproduce the error:
(Need a single company configuration)
1. Inventory > Configuration > Settings
2. Enable "Lots & Serial Numbers"
3. Inventory > Products > Products
4. Create a new one
- Set "Tracking" to "By Lots"
5. Operations > Transfers
6. Create a new one
- Add the product and set a demand
7. Save & Mark as todo
8. Enable the mobile mode of your browser & Refresh the page
9. Edit the transfer
10. On the product line previously added, click on details (to set the quantitiy done)
11. Click on "Add"
12. Click on "Lot/Serial Number" field
13. Create
14. Save
=> Validation Error (field Company is missing)
OPW-2389965
closesodoo/odoo#62301
X-original-commit: 6f0c3e9b23d785d5348817d9a23e34f7d4c1f835
Signed-off-by: adwid <adwid@users.noreply.github.com>
What are the steps to reproduce your issue ?
1. Install 'Manufacture' and enable 'Work Order' in settings
2. Create product 'ProductA', enable 'Manufacture' in 'Inventory' tab
3. Create a BOM for 'ProductA'
4. For that BOM, create a new operation called 'OperationA' with PDF worksheet but don't attach any PDF
4. Go to 'Manufacture' and create a MO with 'ProductA', the 'OperationA' is automatically set in 'Work Orders'
5. Start the work order
What is currently happening ?
When you try to pause, an error is raised.
'TypeError: Cannot read property 'pdfViewer' of undefined'
What are you expecting to happen ?
Start and pause the work order even without attached PDF.
Why is this happening ?
'this.pdfViewer = existing.data('PDFViewerApplication').pdfViewer'
When there is no pdf attached. The data 'PDFViewerApplication' does not exist.
How to fix the bug ?
Change worksheet default value to text, and make the field mandatory in case of a PDF type
opw-2387428
closesodoo/odoo#62350
X-original-commit: 8597aada3d9bacc3cff4707bb78a7bc48d723cfb
Related: odoo/enterprise#14992
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Blocks and Rainy / Airy and Zigs merged together
Fix color of Bold 5 and bold 6 shape that are not easy to use due to contrast
with black, now it is grey by default.
task-2357174
closesodoo/odoo#62352
X-original-commit: 978fcbd4f6ba9f618b69560cb5fbe26602828bcb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit Bold shape 10 & 11 had no transparent color
After this commit Bold shape 10 & 11 have a transparent color instead of
their former color #3 (#F6F6F6)
task-2357174
https://github.com/odoo/odoo/pull/59613
X-original-commit: 71b3b2d61b7acad601da38457671a20357298587
Before this commit, it was impossible to write to a delegated m2o field
if the length of the recordset was greater than 1.
The reason was because the special case for delegated fields inside
fields.Many2one.convert_to_cache would check for `record.id` which is a
bit misleading, since record can be greater than one.
The solution is to check whether any of the records are real records
instead, as if all of the records are NewRecords, then the parent is a
NewRecord too.
Fixes#62069closesodoo/odoo#62343
X-original-commit: 76bf9dc94165c79be873a8864bfdb50a0a636084
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before, on request by groups, now we use a variable is_system / is_designer
to make only once the request.
closesodoo/odoo#62313
Related: odoo/enterprise#14970
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose
=======
The goal of this contraint is to prevent employees to take a time off
when he's not supposed to work (example: after the end of his contract).
But, in some conditions (example: we change the contract end date), the
number_of_days is not recomputed, and the constraint is raised
when unlinking the time off.
Move the chunk of code at the validation level, to prevent validating
a time off if the employee is not supposed to work.
closesodoo/odoo#62337
X-original-commit: c0e082ee1fba7cecc711f724974d79ed65bab29b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
It's possible to create a new activity when editing a existing activity (done
and schedule next). In this case, we must refresh the activity list, otherwise
they wont be in the chatter.
task-2389961
closesodoo/odoo#62333
X-original-commit: 26a2c047a2757c600b3128fe753fa1328043a245
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
Remove unused blank templates in crm and mail.
SPECIFICATIONS: TEMPLATES MOVE
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
SPECIFICATIONS: REMOVE BLANK TEMPLATES
Crm and mail hold a blank template that adds no real value. Its purpose was to
give a base for salesmen to perform a mass mailing on leads. Using a template
and its action menu entry it was possible to launch a mail composer in
mass mail mode on leads.
However template itself is not necessary. Same goal can be achieved with
a standard action. As template was blank and creating noise we can remove
it and simplify available templates.
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Mail holds a blank template that adds no real value. Its purpose was to
give a base for parner managers to perform a mass mailing on leads. Using a
template and its action menu entry it was possible to launch a mail composer
in mass mail mode on leads.
However template itself is not necessary. Same goal can be achieved with
a standard action. As template was blank and creating noise we can remove
it and simplify available templates.
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
Crm holds a blank template that adds no real value. Its purpose was to
give a base for salesmen to perform a mass mailing on leads. Using a template
and its action menu entry it was possible to launch a mail composer in
mass mail mode on leads.
However template itself is not necessary. Same goal can be achieved with
a standard action. As template was blank and creating noise we can remove
it and simplify available templates.
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#19366
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#19366
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
Ivan Yelizariev