The 'index_content' field was only filled when uploading from the frontend.
That would lead to inconsistent results when creating/updating 'presentation' slides from the slide.slide form view.
The field was also not cleaned if the slide content changed.

As it's usage was not very clear (only on a 'search', and not very intuitive), we simply removed the field.

The completion time of a slide now has default values for slides of type

  * video (duration of the YouTube video);
  * PDF (number of pages * 5 minutes);

This computation is done when uploading a slide in frontend or by an onchange
in backend. Field can still be given / modified by elearning people as
result may not be reliable (pdf parsing is not accurate, and/or you may
estimate time differently from strict page-based computation).

The course will sum up all durations of its (active) slides. Display has been
changed from "x minutes" to "x hours y minutes".

Task ID 2007294

Task 2007294

Since af690f67 one can toggle the free preview boolean directly from
the slide list view in frontend. It is therefore not necessary to add
this checkbox when uploading it.

Task ID 2007294

PURPOSE

Improve attendees management by adding a button to remove them in backend
of eLearning.

SPECIFCIATIONS

In order to easily remove a attendee from a channel, we add a button in
the slide_channel_partner tree view, accessible from channels (attendees).
Remove a slide_channel_partner implies to remove the related slide_slide_partner.
Also code backtracking for the view of attendees of a course: we redirect
to the slide.channel.partner model instead of res.parter because
we want the possibility to create/remove/edit attendees for a
course and not making action on res.partner model itself.

Task ID 2045620

This commit adds a link to go to the "home" forum to "Forum" tab in question
page.

Task 2026846

Text colors were white on a white background which can be difficult to read
in some extreme cases. Sort of.

Task 2026846

This commit adds a function to mock multi-file drops.

Task: #2002553

closes odoo/odoo#35435

Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>

The domain could not return any invoice

closes odoo/odoo#35655

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

- Since commit https://github.com/odoo/odoo/commit/f5cd483216af01001f44a41f7d48f042b9f56ff9


the method `_lang_get` doesn't fallback on a language if the asked language
isn't found.

This causes issues with `formatLang` that uses the language on the
context, which is the language set on the client browser (in most cases).

Meaning, if 'en_US' is the only installed language and a customer
has set his browser to `fr_FR`, when calling `formatLang` this will
crash since no language has been found and `format` on `res.lang`
requires a singleton.

closes odoo/odoo#35633

Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>

Provide documentation for the `form_view_id` attribute on gantt
view.

Task-2050019

closes odoo/odoo#35590

Signed-off-by: Jérome Maes (jem) <jem@openerp.com>

All views defined in the 'enterprise' addons have their validation done
manually in their respective addons. Each one ? No, one rebel still
resists to the standart way to work.
This commit moves the gantt validation to put it in its module. The idea
is (for developper) to have only one module to change when adding feature
in gantt view.

Task-2050019

closes odoo/odoo#35576

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

PURPOSE

SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...

Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.

SPECIFICATIONS

Purpose of this merge is to add Mass SMS application allowing to send SMS
in batch. It is build on mass mailing application but with its own menus,
views and flows.

See sub commits for more details. Here is a summary of main changes
in this merge.

PHONE BLACKLIST

Add a blacklist mechanism for phone numbers used to send SMS like
what already exists for email addresses when sending emails.

Define a new phone.blacklist model, holding a number and the state of the
blacklist (active field), as well as tools methods to access it. Make it
as private as possible, accessing it in sudo once access are granted.

Define a new mail.thread.phone mixin computing the blacklist status of a
record.

BLACKLIST / ERROR IN COMPOSER

Support blacklisted and already-done numbers when sending SMS :

* blacklist support: necessary to avoid sending SMS in batch to people that
asked to stop being spammed;
* already-done support: when performing mailing in batch or doing A/B testing
we may have already-done SMS;

When sending SMS in batch, already update state and error code of SMS that
should not be sent

* blacklisted number: set to canceled, with blacklist error code;
* duplicated number: set to canceled, with duplicated error code;
* invalid number (cannot sanitize): set to error, with either missing number
if void or wrong format if not void;

SPEEDUP BATCH LOGGING

Allow quick message creation by allowing create multi on mail.message.
Also introduce a new helper tool method to log in batch on records.

IMPROVE SMS COMPOSER ONBOARDING AND USE

Clean the use and options of sms composer after FP feedback, notably

* see https://s.nimbusweb.me/share/3167586/ap1xpy95rz29a5cys576 as basis;
* globally, do not display invalid recipients, only valid / invalid count
as well as current selection / active domain counts;
* consider logging a note as default behavior when using the composer;
* simplify code: when doing a mass SMS, send SMS and attach a simple note
to the document;

Limit use of templates to models that are really capable of sending
SMS. Templates are now available on models that inherit from mail.thread
and effectively have fields used in SMS sending.

MASS MAILING PREPARATION

Prepare mass mailing module to addition of mass_mailing_sms.

Mailing model: mailing type
* add a mailing_type selection field;
* mass mailing contains only 'mail';
* synchronize medium accordingly;
* update actions of mass mailing application to add a domain on mailing
type being 'mail';

Mailing contact
* remove is_email_valid field as its purpose is achieved by email_normalized
field coming from address mixin (added by blacklist management);

Mailing contact subscription
* clean a bit fields and views as this should stay a technical model;

Trace model and report: trace type
* add a trace_type selection field;
* mass mailing contains only 'mail';

ADD MASS MAILING SMS

Create a new application called "Mass SMS" that follows the structure of
mass_mailing application.

General guidelines

* use the fa-comment icon for this module;
* add a "Notification type" field to the mailings: email or sms. Set it
invisible and set as domain from context when choosing mass mailing or
mass sms application (menus / action specific);
* adapt the metrics from Mass Mailing to SMS
* sent = received = whether the SMS was sent or not;
* opened => we don't have this information;
* replied => we don't have this information;
* clicks = from link tracker (no change of behavior);
* bounced = SMS that failed to be delivered because the format is wrong;
* exception = any issue when sending SMS;
* keep the Mailing Lists menu, hide email related fields on contact model;
* settings: hide the "Specific Mail Server" feature

Opt-out and blacklist handling

* we do support mailing lists because they could come from different sources
and are a way to communicate with a specific audience (and not just a list
we bought), e.g. subscribe to this list to be kept updated whenever this
product is back in stock, or to receive results of this ...
* if the SMSing is from a list, opt-out removes ourselves from the list;
* if it is from the contact ==> Sent to blacklist;
* allow to attach unsubscription links in sent SMS, redirecting to a new
route in mass mailing SMS allowing quick unsubscribe and/or blacklist
of phone numbers;

Error management

* if the user clicks on Send Now / Schedule / Test and does not have enough
credits, open the "Insufficient credits" modal in a lazy option (aka when
having failed statistics linked to insufficient credits);
* on the mailing, we however display this failure as :
* a message on the mailing kanban view
* a message on the top of the form view + same behavior as the mailing and
"Could not be sent" https://www.screencast.com/t/BExgd1Gc;



LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481b)

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

* remove center buttons, corresponding features either moved to fields
list (handle / bin on exported, etc...) or removed
entirely (e.g. clear)
* replace XLS to XLSX format, increases rows# to 1048579
* add FAYT filtering of available fields
* sort available fields alphabetically (CI) always
* change export templates UI: remove buttons

TaskID: 1910953

closes odoo/odoo#32339

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

- Clean form view
- Add a new widget to check if IBAN account number is correct
- On the res.partner model, default value for "is a company" is True.

TaskID: 2025362

closes odoo/odoo#34691

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Purpose of this commit is to help discovering the new mass SMS application
by adding some data. Some mass mailing data is also udpated to be a bit
more interesting / up to date.

LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481b)

PURPOSE

SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...

Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.

SPECIFICATIONS

Create a new application called "Mass SMS" that follows the structure of
mass_mailing application.

General guidelines

  * use the fa-comment icon for this module;
  * add a "Notification type" field to the mailings: email or sms. Set it
    invisible and set as domain from context when choosing mass mailing or
    mass sms application (menus / action specific);
  * adapt the metrics from Mass Mailing to SMS
    * sent = received = whether the SMS was sent or not;
    * opened => we don't have this information;
    * replied => we don't have this information;
    * clicks = from link tracker (no change of behavior);
    * bounced = SMS that failed to be delivered because the format is wrong;
    * exception = any issue when sending SMS;
  * keep the Mailing Lists menu, hide email related fields on contact model;
  * settings: hide the "Specific Mail Server" feature

Mailing form view

  * add an "SMS Content" tab between Mail Body and Options. In there, we should
    have the following fields:

    * content
    * opt-out link: provide a link to the Unsubscribe page. Make it as short
      as possible;
    * SMS Template

  * add an "SMS Text Message" Medium;

Mailing actions

  * add an "SMS Sent" smart button. Use the fa-comment-o icon and it should
    redirect to the same list views as the "Email sent" smart button and list
    the contacts to which an SMS was sent;
  * add a "Mobile" field in the list views of the "Email sent" smart button:
  * adapt the TEST button > Test Mailing modal to SMS (we should have 1 button
    for Email and 1 for SMS); update description;
    * default value for the Recipients field should be Name of the current
      user, work mobile/phone number;
    * If there are no Work Mobile/Phone numbers set on res.users, display
      (123)-456-7890 instead;
    * rename the Send Sample Mail button into Send Sample SMS;

  * adapt the SEND NOW button > Confirmation modal to SMS. Change the message
    into "This will send the SMS Text Message to all recipients. Do you still
    want to proceed?"
  * hide the following elements:  Subject, From, Reply to, Attachments, Mail
    Server, Mail Body tab; Opened, Replied;
  * adapt the label of the following "warnings" to SMS
    * x SMS Text Message(s) have been ignored and will not be sent.
    * x SMS Text Message(s) are in queue and will be sent soon.
    * x SMS Text Message(s) could not be sent.

Mailing kanban view

  * hide the following stats: https://nimb.ws/grvBn0: Opened, Replied;

Mailing list / contact management

  * following fields should be left empty: https://nimb.ws/3HBeJL: Opened,
    Replied;
  * when browsing through mailing lsits and contacts through the Mass SMS
    application, update actions and views to hide fields related to
    email and display only phone-related information;

UTM Campaign

  * form view > Related Mailings tab: the following fields should be left
    empty if notification type = SMS: https://nimb.ws/nfvr1O: Opened, Replied

Mass Mailing > Reporting (mail.trace.report model)

  * adapt the reporting based on the fact that we do not have the following
    metrics for SMS: Opened, Replied;

Mass Mailing > Configuration > Blacklist

  * do not display any email information (phone blacklist is about phone);
  * support phone blacklist. Phone blacklist is therefore a separate model
    from mail.blacklist to simplify management. It is included in sms sending
    process like mail blacklist when mailing in mass;

Opt-out and blacklist handling

  * we do support mailing lists because they could come from different sources
    and are a way to communicate with a specific audience (and not just a list
    we bought), e.g. subscribe to this list to be kept updated whenever this
    product is back in stock, or to receive results of this ...
  * if the SMSing is from a list, opt-out removes ourselves from the list;
  * if it is from the contact ==> Sent to blacklist;
  * allow to attach unsubscription links in sent SMS, redirecting to a new
    route in mass mailing SMS allowing quick unsubscribe and/or blacklist
    of phone numbers;

Error management

  * if the user clicks on Send Now / Schedule / Test and does not have enough
    credits, open the "Insufficient credits" modal in a lazy option (aka when
    having failed statistics linked to insufficient credits);
  * on the mailing, we however display this failure as :
    * a message on the mailing kanban view
    * a message on the top of the form view + same behavior as the mailing and
      "Could not be sent" https://www.screencast.com/t/BExgd1Gc;

LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481b)

PURPOSE

SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...

Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.

SPECIFICATIONS

Prepare mass mailing module to addition of mass_mailing_sms.

Mailing model: mailing type
  * add a mailing_type selection field;
  * mass mailing contains only 'mail';
  * synchronize medium accordingly;
  * update actions of mass mailing application to add a domain on mailing
    type being 'mail';

Mailing contact
  * remove is_email_valid field as its purpose is achieved by email_normalized
    field coming from address mixin (added by blacklist management);

Mailing contact subscription
  * clean a bit fields and views as this should stay a technical model;

Trace model and report: trace type
  * add a trace_type selection field;
  * mass mailing contains only 'mail';

Various
  * clean some bits of code in views, remove old code bits;
  * add anchors to ease view inheritance to be able to customize views for
    SMS mailings;
  * ensure all views in mass mailing filter content on mail type (mailing
    and traces being type mail only);
  * rename some methods to be more updated with current guidelines, notably
    main action methods;

LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481b)

PURPOSE

SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...

Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.

SPECIFICATIONS

Limit use of templates to models that are really capable of sending
SMS. Templates are now available on models that inherit from mail.thread
and effectively have fields used in SMS sending.

Technically this is done through a not stored field on ir.model that is
searchable. SMS sending capabilities is based on

  * having fields holding phone numbers, as defined on mail.thread in SMS;
  * having fields holding partners, as defined on mail.thread in SMS;

This implied some code rewriting notably about finding default SMS
recipients on a given model, in order to have fields instead of directly
returning partners.

LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481b)

PURPOSE

SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...

Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.

SPECIFICATIONS

Clean the use and options of sms composer after FP feedback :

  * see https://s.nimbusweb.me/share/3167586/ap1xpy95rz29a5cys576 as basis;
  * globally, do not display invalid recipients, only valid / invalid count
    as well as current selection / active domain counts;
  * consider logging a note as default behavior when using the composer;
  * simplify code: when doing a mass SMS, send SMS and attach a simple note
    to the document;

Some other points

  * make name of sms templates translatable;
  * improve various wording, notably in sms widget;
  * display error code in sms list view;
  * update sms composer actions accordingly by correctly setting active id
    or ids;

LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481b)

PURPOSE

Allow quick message creation by allowing create multi on mail.message.
Also introduce a new helper tool method to log in batch on records.

SPECIFICATIONS

Purpose of this commit is to add a way to log notes in batch on a document.
Those notes are logged without any notification mechanism, allowing to
attach a note in as few queries as possible.

This is implemented by

  * allowing create multi on mail.message. Nothing changes in its behavior
    except that it is not working on a list of dictionaries;
  * adding a ``_message_log_batch`` tool method allowing to post a batch
    of notes on records;
  * adding a tool method to correctly find author / email_from, to be used
    in various message_post / log / notify methods in order to have the
    same behavior in all those methods;

Logging in batch will soon be used in SMS when attaching a note to sent
SMS without having extra notifications. This will be used notably when
performing mass SMS without using the standard notification mechanism.

LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481b)

PURPOSE

SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...

Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.

SPECIFICATIONS

Purpose of this commit is to support blacklisted and already-done numbers
when sending SMS.

  * blacklist support: necessary to avoid sending SMS in batch to people that
    asked to stop being spammed;
  * already-done support: when performing mailing in batch or doing A/B testing
    we may have already-done SMS;

When sending SMS in batch, already update state and error code of SMS that
should not be sent

  * blacklisted number: set to canceled, with blacklist error code;
  * duplicated number: set to canceled, with duplicated error code;
  * invalid number (cannot sanitize): set to error, with either missing number
    if void or wrong format if not void;

Support of blacklist / duplicated / invalid will notably be used when
performing SMS marketing (mass SMS) and marketing automation using mass
SMS.

LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481b)

PURPOSE

SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...

Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.

SPECIFICATIONS

Purpose of this commit is to add a blacklist mechanism for phone numbers
used to send SMS like what already exists for email addresses when sending
emails.

Define a new phone.blacklist model, holding a number and the state of the
blacklist (active field), as well as tools methods to access it. Make it
as private as possible, accessing it in sudo once access are granted.

Also clean phone validation tools: lessen number of tool functions and update
caller to simplify code readability. Some fixes are also included in this
commit, notably blank spaces cleaning in phone numbers.

Improve phone.validation.mixin to add a tool method computing a sanitized
number, in addition to formatting it to national / international.

Define a new mail.thread.phone mixin computing the blacklist status of a
record. This mixin

  * inherit from phone.validation.mixin in order to have access to some
    base phone number parsing capabilities;
  * computes a sanitized phone number based on ´´_phone_get_number_fields´´.
    It takes first sanitized value, trying each field returned by the
    method. That means one sanitized phone number is available per record
    even if several fields are available;
  * compute blacklist state of records. It is based on phone.blacklist
    model and give an easy-to-use field and API to manipulate blacklisted
    records;
  * give some API methods :

    * ``_phone_set_blacklisted``: set recordset as blacklisted;
    * ``_phone_reset_blacklisted``: reactivate recordset (even if not blacklisted
        this method can be called safely);

Put menus in technical in order to have access to it. Add a Phone / SMS
menu below "Email" and use it to store SMS / Phone actions.

Finally prepare tests addition by performing some light cleaning while adding
blacklist tests. Purpose is to ease future tests related to SMS.

LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481b)

closes odoo/odoo#35622

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

closes odoo/odoo#34931

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Before this commit,
In top-right corner, the avatar that is being shown doesn't correctly
look like a circle if the shape of the avatar is rectangle.

After this commit,
The avatar appears in the top-right corner will be shown in correct circle
shape, irrelevant of the image is square or not.

task-2042276
closes: #35265

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

image widget control button icon(Edit and Delete) not displayed in one line
button tag is used for control buttons and button tag has default padding
so removed default padding added by browser by explicitly defining padding 4px

task-2042276
closes: #35265

TaskID: 2040826

closes odoo/odoo#35394

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Since the POS customer display is not anymore a stored field, we don't
need to keep this override of write and create.

closes odoo/odoo#35638

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

When a session is opened on a POS config, we don't want to let users
editing the pos config as modifying journals, payment method,
pricelists,... Could lead to inconsistancies between what has been
encoded on the pos orders and what are the available values on pos
config.

Before this commit, it wasn't taking into account the rescue sessions,
only the normal ones.

The line number was only indicative and was not used by the system.
When the translations source were updated, a big part of the diff was
only about the line numbers.
Ignore the given res_id value and export the line at 0

When reading the po file, the res_id from the file is still read and
stored in database but should be ignored

closes odoo/odoo#35582

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

We've adapted the tests to work with the new implementation
of payments and session closure. And we've added some new
ones to have a better coverage on point_of_sale module.

TASK-ID: 1862388

closes odoo/odoo#33578

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Main goal of this task is to create single accounting entry
(AE) when closing a pos.session instead of individual AE for
each order in the session.

This significantly minimizes the number of created journal
entries by point_of_sale which also results to faster closing
of session when there is large numbers (order of thousands)
of orders. It also eases the reconciliation of payments because
on one hand, cash payments are automatically reconciled and on
the other, other payments are combine in a receivable line
based on the payment method.

**Important points to note**

1. Two new models (pos.payment.method and pos.payment) are
introduced replacing the functionalities of account.journal
(and account.bank.statement) and
account.bank.statement.line, which served before as payment
methods and payments.

2. The creation of single AE relies on the receivable_account_id
defined in each pos.payment.method. This receivable_account_id
is supposed to be different from the account module's receivable
account, thus, a new receivable account for pos is introduced
in each localization.

3. A simple example below can illustrate this change.

Given the following orders:

    +---------+----------+----------+-----+-------+-------+
    | order   | payments | product  | qty | price | total |
    +---------+----------+----------+-----+-------+-------+
    | order 1 | cash     | product1 |  10 |    10 |   100 |
    |         |          | product2 |   5 |    20 |   100 |
    +---------+----------+----------+-----+-------+-------+
    | order 2 | bank     | product2 |   7 |    20 |   140 |
    |         |          | product3 |   1 |    30 |    30 |
    +---------+----------+----------+-----+-------+-------+
    | order 3 | bank     | product1 |   1 |    10 |    10 |
    |         |          | product2 |   3 |    20 |    60 |
    |         |          | product3 |   5 |    30 |   150 |
    +---------+----------+----------+-----+-------+-------+

Instead of generating 3 accounting entries, a single
accounting entry (linked to the pos.session) will be created.
This accounting entry will have the following lines:

    +---------------------+---------+------------+
    | account             | balance | reconciled |
    +---------------------+---------+------------+
    | sale                |    -590 |    -       |
    | pos receivable cash |     200 |    yes     |
    | pos receivable bank |     390 |    no      |
    +---------------------+---------+------------+
    | Total balance       |     0.0 |            |
    +---------------------+---------+------------+

Note that the cash receivable line is already reconciled
because it can assumed that the payment is already received.
The unreconciled receivable line can be reconciled manually
using the reconciliation widget.

More examples can be seen in the tests.

TASK-ID: 1862388

A new feature[*] in point_of_sale (PoS) which minimizes the
creation of account.move records in closing a pos.session relies
on a receivable account made specifically for PoS.

This commit addresses this feature's requirement by adding a
new receivable account to each localization.

[*] point_of_sale: single AE for a pos.session

TASK-ID: 1862388

Now we hide the generate return label if this option is not available for the current carrier.
Before this fix, we could set the field to true even if the option was not available for this particular carrier.

Task-Id: 1956970

closes odoo/odoo#35178

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

PURPOSE

Add some improvements in mail gateway: remove private discussion, improve
bounce management, allow resetting bounce counters, improve automatic set or
reset of blacklists and ease mass mailing inheritance.

MAIN SPECIFICATIONS

Remove private discussion support in mail gateway. It is not really supported
since several versions. This merge removes remaining code in gateway.

Perform all incoming email parsing in message_parse and its sub methods. That
way future processing can use parsed values instead of re-doing parsing of
required information.

Add ``_message_parse_extract_bounce`` parsing sub method to parse bounce
information and use it in mass mailing.

Add ``_routing_handle_bounce``: handle bounced emails by notably updating
the bounce counter on blacklist records.

Add ``_routing_reset_bounce``: handle valid incoming emails by notably
resetting bounce information on that specific email.

Have ``_message_receive_bounce`` and ``_message_reset_bounce`` being
void in mail.thread and updating reset counter in blacklist enabled records.

Update blacklist / unblacklist in mass mailing, take into account traces and
partner information.

Add tests.

See sub commits for more details and explanation.

LINKS

See task 1893155

closes odoo/odoo#35284

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

PURPOSE

Add some improvements in mail gateway: remove private discussion, improve
bounce management, allow resetting bounce counters, improve automatic set or
reset of blacklists and ease mass mailing inheritance.

SPECIFICATIONS

The number of message bounce is incremented each time the email bounce
on a specific email address. To have a correct information, we should
reset to zero this counter if we receive a mail from this address.
Indeed, if we receive an email from an email address, this email is
active and the message bounce number (if > 0) is not relevant anymore.

Only models inheriting form blacklist are impacted by this improvement
in order to limit a bit side effect.

Also, add a check in autoblacklist rule. No need to check the stats
if message_bounce is < 5.

This commit introduces

  * ``_routing_reset_bounce`` routing method managing the bounce reset;
  * ``_message_reset_bounce`` model method that resets bounce counter
    in blacklist enabled models;

LINKS

Related to task ID : 1893155
Linked to PR #33340

PURPOSE

Add some improvements in mail gateway: remove private discussion, improve
bounce management, allow resetting bounce counters, improve automatic set or
reset of blacklists and ease mass mailing inheritance.

SPECIFICATIONS

Purpose
  * move bounce information detection in message parsing. It allows to have
    this information available in various steps of routing instead of having
    to manually re-compute them;
  * handle bounce in specific methods allowing easy override;
  * improve bounce management, notably when detecting a bounce not linked
    to the bounce alias configuration;
  * better integration with blacklist mechanism;

Specifications
  * compute bounce information in ``_message_parse_extract_bounce``.It parses
    bounce information and returns a dictionary allowing to update parsed email
    values;
  * remove override in mass_mailign that basically does what mail already
    does;
  * manage bounce in ``_routing_handle_bounce``;
  * when detecting a bounce, correctly call the bounce management method on
    all models inheriting from blacklist;
  * correctly update bounce counter;
  * bounced mailing traces and automatic blacklist in mass mailing should
    be done in ``_routing_handle_bounce``;
  * add some tests;

LINKS

Related to task 1893155
Linked to PR #33340

PURPOSE

Add some improvements in mail gateway: remove private discussion, improve
bounce management, allow resetting bounce counters, improve automatic set or
reset of blacklists and ease mass mailing inheritance.

SPECIFICATIONS

Parsing email values: make message_parse effectively prepare all required
values for later processing

  * update message_parse to add some more data directly in parsed dictionary
    and avoid having to parse value again in later processing and computation.

    * notably recipients computation is now done directly in parsing. It
      includes email check and reconstruction using tools methods. That way
      routing just has to handle those values and not compute part of them;
    * from and cc are correctly managed with parsed and cleaned (sanitized)
      versions in dictionary;
    * remove all code decoding message header and replace them by fetching
      the parsed value instead;

  * filter parsed values before calling message_post to ensure right values
    are given to it instead of having to manage them in message_post. Indeed
    caller has to give the right input;
  * make parsing sub-methods (extract payload, post process payload) have
    a dictionary as input and output to always manage a dictionary of values
    through the parsing methods and update their namespace;

Routing: remove deprecated code parts

  * remove use of email_references regex. Indeed emails are routed using their
    messageId and not the regex anymore since several versions [1];
  * clean some unnecessary variables;
  * simplify variable type input, like message_parse accepts only valid
    email.message instances and to avoid several decode / encode. Tests are
    updated accordingly;

Update docstrings of those methods.

LINKS

Related to task 1893155
Linked to PR #33340

[1] See df037e29 and 0028c421