Since de4213b771f641cbc218ebb1f759b09e064100bf it is not possible to anyone except admin to use templates
with a report defined on it. This could be annoying.

Purpose of this commit is to allow multi-create in alias mixin by correctly
creating / updating aliases in batch.

Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872

Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>

Previously a blacklisted phone number or email address could only be
removed from their respective blacklist by going to the corresponding
blacklist view [in mass_mailing_(sms)] and manually
archiving/deactiviting the entry. All users could see that an email was
blacklisted via an fa-ban icon added next to their corresponding field
in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via
extension).

This commit adds additional fa-ban icons next to blacklisted phone
numbers and makes all instances of these icons clickable to remove them
from their corresponding blacklist using a wizard. There are several
limitations to this implementation including:

1. If both a mobile and phone number field appear within a crm lead
instance, then only the mobile field will indicate if it is blacklisted
(due to current implementation of PhoneMixin which only checks 1 phone
value against the blacklist and "sms" which returns mobile numbers first).
I.e. if a phone field value is blacklisted, but a value is typed into the
mobile field, then the phone field will never indicate that it is blacklisted.

2. If someone clicks on a unblacklisting icon after changing the
corresponding field value without clicking off the field input, then the
latest typed in value will be the one submitted for unblacklisting,
which may not actually be blacklisted (due to "is_blacklisted" flag
being a computed field and it not having a chance to re-compute to hide
the button).

3. If someone changes values in the blacklist, then someone who already
has a form open will not see icon disappear until something triggers a
re-compute of the "phone_sanitized_blacklisted" flag (this was already the
case with the icon, but now a user may try to unblacklist a value that is
already unblacklisted.)

4. Since the icon needs to be visible by everyone to indicate whether or
not a phone/email is blacklisted, users without corresponding unblacklist
permissions will be able to click on the icon. When they click on it, they
will be informed they do not have permission to unblacklist. A wizard was
determined to be the best way to implement this unblacklisting for the
following reasons:
  - A "Unblacklisting Reason" is needed and will not be stored as a field.
  - A field widget is unable to do this due to security settings +
    inability to refresh view after unblacklisting with a
    "Unblacklisting Reason" without wiping unsaved changes.

Additionally, to better align with GDPR, the corresponding form view for
the phone/email blacklist has been updated to use the same wizard to
track "Reason for unblacklisting". Unfortunately there is no
straightforward way to prevent direct "Archive" action, so users are
still able to bypass unblacklisting without being asked for a "reason
for unblacklisting".

Supports task: 2117635
Upgrade PR: odoo/upgrade#939
COM PR: odoo/odoo#45315

Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value

account*: use account.group_account_user for all transient by default
	  remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
      additional verifications are made to ensure they are executed
      only on the documents the user has access to you
      give portal access to mail.compose.message as portal still does
      some actions like posting messages on the forum
      add ir.rule to avoid reading somebody else messages
      increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
     partner manager for actions linked to partners
     avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
     give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
	    event user inherit from  sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
    manager can set a plan according to group on button
    anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
	 as the source is an account.move
	 keep the payment.acquirer.onboarding.wizard to system user
	 only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
	       never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
      add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
	     add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation

base: base.language.*: allow employee (cf lang_install)
      change.password.user: can not read change password wizard of
      other users
      test.*: no access is needed

Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl

Purpose of this commit is to improve model of followers, notably management
code and its use in routes. Indeed it is quite an old model and code had
to be cleaned a bit to improve code readability and maintenance.

In this commit we

  * remove unnecessary code examples in gamification about followers: using
    that model as example of code for goals is probably not a good idea as it
    is technical;
  * rewrite routes called by JS are simplified to better match JS
    implementation;
  * introduce computed fields to fetch related partner or channel name,
    email (partner only) and active status;

LINKS

Task 1933771
Task 2078313

closes odoo/odoo#39808

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Remy Voet <ryv@odoo.com>
Co-authored-by: jgi-odoo <jgi@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>

From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.

We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.

Task ID 1853147
PR #32243

This was already performed on 3c568aec0b46, but there still are some
remnants on model access records.

Fixes odoo/odoo#25408
Closes odoo/odoo#37946

closes odoo/odoo#37958

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

Task 2078313

Purpose
=======
Improve mailing subscription to be more compliant with the European GDPR law.
Keep a list of people who does not want to receive promotional emails
(or mass mailing in general) anymore.

Specifications
===========
This commit is regrouping some main changes on mass mailing.
- Added blacklist : Avoid sending mass mailing to blacklisted recipient
  (blacklisted = email address that doens't want to receive mass mailing anymore)

Detailed implementation
===================
Mail :
- Add Blacklist mechanism in mail module (NOT in mass-mailing) :
  as we can send mass-mail without the mass-mailing module
- Unicity in email -> To avoid error in import, override the create and return
  the existing record if any, else, create the record normally.
- Blacklisting is done by email address and is cross model.
  Will apply to model that inherit the blacklist.mixin.
- field 'is_blacklisted' -> computed : check if email is in blacklist
  + search method to be able to filter on is_blacklisted
- When a email address is blacklisted, it will never get mass mailings anymore.
  Even if the email address is added to another mailing lists
- Avoid sending notification to blacklisted recipients when sending email
  in mass mail mode. If the recipient is blacklisted, we should not even send a
  notification in the recipient's chatter for an email that he won't even
  receive.
- When a email address is blacklisted, it can still get 'normal' mailings.
- The blacklist shoud be accessible in
  Mass Mailing / Configuration / Blacklist
  and Settings / Technical / Email / Blacklist
  -> Renaming Settings / Technical / White / Black List config menu item
     into Channel Moderation to avoid confusion with Mass Mail Blacklist
- Add indexes to the blacklist table (on email) to make it fast for access for
  the different use cases
- _primary_email : attribute that must be overriden to specify which field must
  be used as email in the blacklist mechanism.
- Filtering the blacklisted recipient in mail composer :
  done in mail._get mail value()
  In case of real mass mailing, we need the statistics to be computed in order
  to know how many recipients were ignored in the mail.
  So we cannot avoid sending mail but instead flag the mail as canceled.

Task ID 33224