In stock:
1. remove string of action_show_details button, only show icon
2. late filer have been megered with planning issues filer,
update the name. (also in mrp)
3. add width to json_lead_days_popover field to show it properly
4. change inventory adjustment empty screen image.

In purchase:
1. in reminder mail, show "undefined" when no date. This will
only be shown in preview. When no date, we won't send reminder mail to
the vendor.
2. remove old book icon for document in setting.
3. check if there is date_planned when craete a confirm date url
4. RFQs late filter now show all late RFQs with in state "draft",
"sent", and "to approve".
5. improve the the words in KIP and empty screen and list view

Task 2298950
PR #55155

closes odoo/odoo#55740

Related: odoo/enterprise#12344
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Some change to imporve reminder mail usability:

1. Scheduled date on POL of the PO form now is always editable.
2. Improve tooltip for the reminder email
3. don't show number of days when reminder email not checked on
   both PO and partner form.
4. only show "confirm receipt date" button in debug model
5. In the mail, format date by partner.lang
6. Add button to send preview reminder mail
7. On default, receipt_reminder_email on res.partner is False
8. merge expected_date with date_planned (done by FP)

Task 2265912
PR #52693

1. automatically send a reminder mail to vendor to confirm the receipt
date. If confirmed, (confirmed by vendor) will be added next to the
receipt date. If not, vendor can update the date on the portal website.
An warning activity will be set for the purchase representative for this
update.

2. Vendor can also comfirm recieption of the PO when we 'send PO by mail'.
If confirm, (confirmed by vendor) will be added next to the confirmation
date. An filter is added in the PO search view to show all unconfirmed
PO.

Task 2230811
PR #49921

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

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>

When an email was sent from a PO, the sender was by default the user who created the PO.
The sender is now replaced by the current user.

TaskID: 1934477

closes odoo/odoo#30660

Usability change:
- Remove amount from RFQ template
- Remove origin from both templates
- Modify last sentence to a proper English
- Add partner reference in PO template

Technically remove the conidtion on object state in
order to guess if it's a RFQ or a PO since the check
is already made in python and it exists a template
for the RFQ and a template for PO.

This commit is related to task ID 1835441

In this commit we improve templates used in purchase. 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 1843151 (and 1868112) and to PR #25346
(and #25889).

Purpose

 * use the new notification template allowing to display the payment button
   only in emails;
 * reorder the fields definition to ease the reading;
 * slightly clean the email body using a maximum of div and br tags as it
   seems better integrated with Odoo edition capabilities;

This commit is linked to task ID 1860049 and PR #25824.

formataddr (from the email python library) writes email_from as '"name" <email>'
in the email_from field of the mail.compose.message record.
When the mail is rendered, onchange_template_id is triggered.
This then overwrites the values of email_from among other fields.
What happens is that it uses the email_from field from the template to render
the email_from, bypassing what was put by formataddr before.
What happens in some cases is that it is rendered as 'name <email>'
(note the quotes have been stripped away).
If name contains arbitrary symbols, e.g. name = 'pépé [company] <pdg>, ohlala',
then getaddresses which is supposed to parse the (name, email) pairs gets thrown
off (in particular, <pdg> will be interpreted as an email address, and many
other problems with the various special symbols).
It then gives these wrong elements as email addresses, which will usually crash
when getting non-ascii symbols (i.e. these strings don't respect the relevant
RFC for email addresses).

Closes:
https://github.com/odoo/odoo/issues/23502
https://github.com/odoo/odoo/pull/2311823118

opw 815202
opw 1824243