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
Improve mail template preview wizard by improve its views and displaying
more rendered fields. It helps users knowing what will be sent to customers.
SPECIFICATIONS
Rename template model to mail_template_preview to better match the mail
template namespace.
Remove _inherit on mail.template and instead choose fields to compute
and display. Indeed lot of fields are unnecessary or badly computed.
Instead just add fields on the wizard that depends on mail template
and will be computed based on mail_template_id field of wizard.
Improve error management.
LINKS
Task 2085912
PR #38708
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to lessen size of technical "Email" menu and move some
discuss menu entries in their own menu. It will be the new first menu
entry in technical, before Emails that is more technical.
Some menu items are moved in this new menu, notably followers, messages
or mail blacklist.
Emails menu is also reordered, to have notably all channels related
entries together, ...
Task 2118599
PR #39460
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When using sudo, the administrator is logged as deleting the action.
For audit reason, log the correct user.
To avoid access rights errors, only group system can delete the action.
When using sudo, the administrator is logged as deleting the action.
For audit reason, log the correct user.
To avoid access rights errors, only group system can delete the action.
Purpose
=======
The attribute name isn't required on the <filter> tag. If not set, it can't be selected with a xpath and it can't be overwritten.
A lot of PR are coming from the community just to add a name on a filter because:
- It can't be selected with a xpath.
- It can't be used with `default_search_foo` on an action context.
Specification
=============
Make the atttribute name required
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
Now there should be only one button box per page, and the name should be
"button_box".
Conflicts:
addons/crm/crm_tip_data.xml
addons/event/event_tip_data.xml
addons/fleet/fleet_view.xml
addons/hr/hr_view.xml
addons/hr_recruitment/hr_recruitment_view.xml
addons/project/project_tip_data.xml
addons/purchase/purchase_tip_data.xml
addons/sale_crm/sale_crm_view.xml
addons/website_quote/views/website_quotation_backend.xml
openerp/addons/base/res/res_partner_view.xml
Conflicts:
addons/account_reports/views/partner_view.xml
Conflicts:
addons/claim_from_delivery/claim_delivery_view.xml
addons/stock/stock_view.xml