The purpose of this commit is to improve the repairs module general
workflow, to make it more intuitive and more flexible.
1. Change in the way the Repair Reference is created. It is now always
autogenerated. A new Repair Description can be used.
2. Make the 'Parts' and 'Operations' tabs editable up until (and
including) the stage 'Under Repair'.
3. Make the 'Lot/Serial Number' Field non mandatory for tracked
products, up to and including to the stage 'Under Repair'. If the
user forgot to specify the serial number and clicks on 'End Repair',
shows the exisiting error message.
4. Add product moves related to the repair order in a smart button at
the top right of repair, just like for a finished manufacturing order.
5. Add a Sale Order field in the repair form to make it easier to
perform return if needed.
6. When a component is not tracked by serial/lot number, leaves lot/serial
number read only.
7. Separationo of notes and internal notes into 2 seperate tabs.
8. Lot/serial field always visible but readonly when no tracking.
Task ID-2424420
closesodoo/odoo#66496
Related: odoo/upgrade#2327
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.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.
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
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose: use more email_formatted when possible, clean and simplify
email_from, email_to and partner_to computation.
Next step is to try to extract some common patterns in tools or methods in
order to simplify template creation and customization.
Related to task 1972615
Linked to PR #32872
Purpose of the task is some demo data values are not matching with the products
mentioned so update the demo data values with matching product.
Task: 1892754
closesodoo/odoo#28573
In this commit we improve templates used in repair. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843395 (and 1868112) and to PR #25294
(and #25889).
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
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.
This commit removes the location_dest_id on repair orders. This field
was used to move the product to a specific location after the repair was
done. It makes the usability of the repair order smoother and the user
can still make a transfer to move the product to another location
afterwards.