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

This commit removes the mass_mailing.campaign model. Instead of having a fully
fledged model, we will simply inherit utm.campaign. We will also add relevant
statistics on utm campaign model in order to use it in various applications.

SPECIFICATIONS

This commit removes the mass_mailing.campaign model. Instead of having a fully
fledged model, we will simply inherit utm.campaign. This change implies that
mass_mailing.tag and mass_mailing.stage have to move to the utm model along
their associated views/data.

These changes were made so that campaigns could be used in the future
by social, mass_mailing and mass_sms and available in the same view

This commit also removes the source_id and the medium_id
fields on the campaign.

This commit also moves the unique_ab_testing field from the mass_mailing_campaign
to the mass_mailing model

Task ID: 2002029
PR: #34015

PURPOSE

Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.

SPECIFICATIONS

Rename mail.mass_mailing model to mailing.mailing. Rationale :

  * mailing is now a prefix for mass mailing models;
  * mailing.mailing is easier to read / find / understand;

Note that mail.mass_mailing.campaign is not updated as it is likely to be
removed soon and replaced by simple utm.campaign model.

MIGRATION

mail.mass_mailing model -> mailing.mailing
mail_mass_mailing table -> mailing_mailing

LINKS

Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938

PURPOSE

Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.

SPECIFICATIONS

Rename mail.mass_mailing.stage and mail.mass_mailing.tag models to mailing.
stage and mailing.tag. Rationale :

  * mailing is now a prefix for models in mass mailing;
  * mailing.stage and mailing.tag are easier to read / find / understand;

MIGRATION

mail.mass_mailing.stage model -> mailing.stage
mail_mass_mailing_stage table -> mailing_stage
mail.mass_mailing.tag model -> mailing.tag
mail_mass_mailing_tag table -> tag

LINKS

Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938

PURPOSE

Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.

SPECIFICATIONS

Rename mail.mass_mailing.list and mail.mass_mailing.list to mailing.list
and mailing.list.merge. Rename mail.mass_mailing.contact to mailing.contact.
Rename mail.mailing_list.list_contact_rel to mailing.contact.subscription.
Rationale :

  * those new names are easier to understand: mailing.list and mailing.contact
    are less mail-related, especially taking into account that SMS will allow
    to be less mail-oriented;
  * those names are easier to read / find / understand;
  * align wizard and sub-models naming with the main naming;
  * have a mailing as first part of namespacing;

MIGRATION

mail.mass_mailing.list model -> mailing.list
mail.mass_mailing.list.merge model -> mailing.list.merge
mail.mass_mailing.contact model -> mailing.contact
mail.mass_mailing.list_contact_rel model -> mailing.contact.subscription
mail_mass_mailing_contact_list_rel table -> mailing_contact_list_rel (specific
case of a decorated m2m)

fields updated (no column change)
  * mailing.list: subscription_contact_ids -> subscription_ids

LINKS

Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938

PURPOSE

Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.

SPECIFICATIONS

Rename mail.mail.statistics to mailing.trace and mail.statistics.report
to mail.trace.report. Rationale :

  * mail.mail.statistics is linked to mail.mail model. Soon this model will
    hold data related to SMS sending. It makes sense to be broader in the
    naming;
  * mailing.trace is more inlined with marketing.trace model that is the
    marketing automation model using it in marketing automation (enterprise
    application);
  * mailing.trace is shorter to write;
  * mail.statistics.report model should sense to be updated at the same
    time;

MIGRATION

mail.mail.statistics model -> mailing.trace
mail_mail_statistics table -> mailing_trace
mail.statistics.report model -> mail.trace.report

fields updated (w column change)
  * link.tracker.click: mail_stat_id -> mailing_trace_id

fields updated (no column change)
  * mail.mail: statistics_ids -> mailing_trace_ids
  * mail.mass_mailing: statistics_ids -> mailing_trace_ids

LINKS

Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938

When using only mass mailing two issues arise when trying to send mass
mailings containing links

 * a link.tracker is created for each link to shorten; however rights are
   given currently only in website_links for website designers and not to
   marketing users that use mass mailing. This commit adds the rights for
   link.tracker model to those people;
 * a link.tracker.code is created to hold the shortened versions of the
   links. As it is a technical model it is now done as superuser as rights
   on link.tracked model has already been granted and adding rights on such
   a technical model is not necessary;

A test is added that checks what is done with links when sending mass
mailings. It helped spotting the hereabove issue.

This commit is linked to task ID 1889703 and PR #27526.

Campaign Tags and Campaign Stages was accessible in debug mode even if
campaign was not activated in the mass_mailing settings.
there are now not available if the option is not activated.

Purpose
=======
- Apply the blacklist implementation to 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.
- Allows the recipient to update himself his mailing preferences

Specifications
===========
This commit is regrouping some main changes on mass mailing.
  Apply Blacklist for following models through blacklist.mixin :
    - crm.lead
    - res.partner
    - mail.mass_mailing.contact
    - mail.channel.partner
- Opt_out per mailing list instead of per mailing contact.
- Replace opt_out by blacklist in crm.lead + res.partner models
- Added 'ignored' state for mass_mailing. Ignored = blacklisted, opted-out
  Ignored email are not included into final statistics to avoid confusion.
- Unsubscribe(d) pages migrated from website_mass_mailing to mass_mailing module
  as thoses pages should work without having the website module installed

Detailed implementation
===================
Mass-mailing :
	- A blacklisted email is notified by the ban icon next to the email field.
	  (at the left of the email field for display purpose)
	- Renaming the '_get_blacklist' method that was actually
	  searching opt_out list into 'get_opt_out_list'
	- Opt out per mailing list : Add opt_out + related fields (for display and
	  ergonomy reasons) on the relational model
	- Display relational model tree view instead of mass_mailing.contact tree
	  view when clicking on mass_mailing_list in kanban view
	  -> In order to be align between contact_nbr displayed in kanban tile and
	     the content of the tree view
	  -> mass_mailing contact is accesible via the user icon in this tree view
	- Remove custom filters 'filter_contact_subscription' and
	  'filter_contact_unsubscription' as opt_out is not on mass_mailing.contact
	  model anymore
	- Add 'is_public' to mailing list
	    The name of this mailing list can be seen (or not) by recipient in
	    the unsubscription page
	    If the mailing lists used in the mass mailing are not public,
	    the user in only informed that he has been unsubscribed.
	    If the mailing lists are public, the user is informed that he has been
	    unsubscribed from the mailing lists
	    and he has the choice to modify his subscription to all the public
	    mailing list he is or was subscribed to.
	- Unsubscription Page :
		- mass_mailing_contact :
		  Opt_out per mailing list, done by email and not by id, as multiple
		  contact can have the same email
		  The recipient can add/remove himself to/from the blacklist
		  The recipient can send a feedback about why he unsubscribed
		- crm.lead + res.partner :
		  Once the recipient unsubscribe, he is automatically blacklisted
		  The recipient can 'Come back' and remove himself from the blacklist
		  if he changes his mind
		- Show blacklist button parameter added in config :
		  The idea is to enable/disable the fact that the recipient can add
		  himself to the blacklist by showing or not the 'blacklist me' button
		  Only applies for mass_mailing.contact. The recipient, once
		  blacklisted, can always, no matter the value of this parameter,
		  'come back' and unblacklist himself

crm.lead + res.partner :
	- Replace opt_out by blacklist in crm.lead + res.partner models.
	  As when a res.partner or crm.lead unsubcribe, we assume that the recipient
	  does not want to receive mass mailing anymore, at all, even if we adds him
	  to a mailing list afterwards. He is then blacklisted to avoid this.
	  With this behaviour, if a new lead is created with the same email address,
	  he won't be able to receive mail in mass_mode.
	  But he will still be able to receive '1 to 1' direct email.

Task ID 33224
Closes #25966