This commit is the counter-part of an enteprise commit introducing
the Documents app.

Here is a summary of what has been done:
  - tweak unlink of ir_attachment to prevent unlink recursivity
    (when attachments are attached to ir_attachments)
  - improve ir_attachment kanban view
  - add several arguments to binary_content controller:
    - 'force_ext': to force the extension in the filename, base on
      mimetype
    - 'share_token' and 'share_id': to autorize download from a
      share link
  - add 'thumbnail' field on ir_attachment to optimize Kanban view
  - add 'upper_limit' argument to image to allow to bypass the
    500*500 size limit
  - DocumentViewer now handles text files

More information available on task 1853490

Co-authored-by: Pierre Paridans <app@odoo.com>
Co-authored-by: sri-odoo <sri@odoo.com>
Co-authored-by: ThanhDodeurOdoo <tso@odoo.com>

Overwrite bts4 custom-checkbox design (un-checked state only).
Use outline rule to avoid conflics with :focus and :hover states.
The change has been added in ui.scss to affect both backend and frontend.

In a test, we might want to check the domains given to RPCs with
assert.step/verifySteps. Before this rev., if there were an
'active' field on the model, ['active', '=', true] was
automatically added to the domain by the MockServer in place, thus
altering the expected domain in the test.

This rev. allows to instantiate a FieldMany2one Widget with option
'noOpen' (which hides the external button allowing to open the
related record in a dialog).

This option already existed, but it had to be specified in the
nodeOptions (i.e. in the view arch), which is not convenient for
standalone fields for which there is no view.

Part of task 1853490

This rev. allows to instantiate a Chatter Widget with option
'display_log_button' (which shows the 'Log note' button).

This option already existed, but it had to be specified in the
nodeOptions (i.e. in the view arch), which is not convenient when
a Chatter is instantiated outside the context of a FormView.

Part of task 1853490

This allows to define extensions of KanbanRenderer using specific
Widget (probably extensions of KanbanRecord) to render the records.

Replace current UI of the snippet background options with the
same one as the standard editor colorpicker

task-37974
Closes #26274

- Custom color can now be applied to elements
- Find used custom colors in the page and add them as colorpicker
  suggestions
- Current color is selected in the picker when you open the custom
  color wizard

task-37974
Closes #26274

- Split editor button: one for font color and one for background color
- Remove recent color button feature
- Add only theme colors and remove other color sections like
  graypalette/standard colors
- Button's icon for font color and background color buttons have the
  same color of currently selected element

task-37974
Closes #26274

Moved from the themes repository.

Now, users can use a snippet which showcases the latest blog posts as
soon as they install the blog app.

Note: in the future we may want to develop a snippet which can showcase
any model records (products, projects, ...).

task-1874216

commit cf4d4a05 removed the reconciliation menu. The menu should not have been removed.

 - reworked the multi.compose.message model to manage
   several documents simultaneously
 - Added a letter model for asynchronous processing
 - usability improvement of the modal

Added an option to display the address of the partner on a single line.

In the commit 4a40db20. the implementation of read_group_fill_temporal was
simplified during final review and tests needed to be adapted.

Also fix the implementation issues as detected by the tests.

If the email is invalid (incorrect pattern),
the mailing status is set to canceled and will be flaged as ignored
in the mail.mail.statistics

In order to avoid sending mail indefinitely to a wrong email address,
Take the mail statistics for the recipient of the last 3 month :
	if more than 5 mails bounced (with interval of more than 1 week)
		the email is blacklisted.

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

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

Before, the line chart was rendered with a right margin of 0 px meaning the
right border of the graph was stucked against the right border of the screen
cutting out the last x-axis label. This was uggly. This commit fix that
situation by adding a right margin of 80 px.

This commit only applies for chart grouped on date or datetime fields.

In that case:
- Line Charts : fill missing groups and doesn't display undefined values.
- Bar Charts : doesn't fill missing groups but display undefined values.
- Pie Charts : doesn't fill missing groups but display undefined values.

This commit is part of task #1835644

This commit add an extra parameter 'fill_temporal' to read_group which allows
the orm to add missing groups for date intervals. This is useful for charts.

Suppose that we are in a use case where data are grouped by a date fields
(typically months but it could be another interval) and displayed in a Bar Chart
or a Line Char.
Let's says a request has to group records by month for August, September
and ...December.  If we don't changed anything, we would get a Bar Chart
looking like this :
                                        ___
                              ___      |   |
                             |   |     |   |
                             |   | ___ |   |
                             |   ||   ||   |
                             |___||___||___|
                              Aug  Sep  D
December follows directly after September, it can be unintuitive for the
user, so we change that. We add some fake records for each missing months
between the earliest and the lastest date of the result
                                             ___
                         ___                |   |
                        |   |               |   |
                        |   | ___           |   |
                        |   ||   |          |   |
                        |___||___| ___  ___ |___|
                         Aug  Sep  Oct  Nov  Dec

This commit is part of task #1835644

Part of Task #1835644

Master is going wild. https://github.com/odoo/odoo/commit/b6f7ad3adb23fff1aa888d8315aca8157b555b03 added activity
data but https://github.com/odoo/odoo/commit/83fc5dc03ce92df9b920386f9215cdc5504c3be1 renamed the field.

The commit https://github.com/odoo/odoo/commit/01216345e28374b554bfe95df82d607c591271cf#diff-6bc8c8d6d3cf3075da7e6f417cf28434L33
removes the methods `_confirm_so`, `_generate_and_pay_invoice`, but the
commit doesn't apply these changes everywhere.

Hence we had dead code still remaining in website_sale

Currently when in payment is configure in automatic invoice mode,
customers don't receive anything.
If they want to see their invoice, they have to log into their portal
account.

Task #1866497
Closes #25864

Purpose
=======

- Propose other payment acquired than the predefined ones
- Improve the layout for this step

* web, web_editor, website_theme_install, portal, theme_default,
theme_bootswatch

See sub-commits for details.

task-31677

* web, web_editor, website, website_theme_install, portal,
  theme_default, theme_bootswatch

The purpose of this task is to make the customize dialog as generic as
possible, that is theme-independant:

1) The design is now totally generic (Odoo visuals)
2) The XML definition is form-view like. This allows themes to extend
   the dialog without any risk of breaking the style and also allows to
   not care about lots of technical details.
3) New options have been included. Those were themes options that are
   now generic and which themes can simply adapt without touching the
   customize modal (navbar colors, footer color, navbar layout, fonts,
   body background, ...).

The color palette can now also be customized with user colors.

Using sass functionnalities, color palettes and fonts integration is now
a lot better.

Thanks to @qha-odoo for the original design.

task-31677

The theme will be reviewed and merged with website app.

Task id: 1866074

PURPOSE
=======

Creates a QR code which, when scanned, automatically populates a SEPA transfer form.
If your banking app provides this feature, you can populate an entire transfer form
at the touch of a button, just by scanning the QR code.

This was implemented in order to use it in ecommerce or portal payment views of
quotations and invoices.

SPECIFICATIONS
==============

Sepa qr code:
-------------

- Generate the qr code:
   - To figure out. a payment can be done on sales orders, invoices or not related to
     anything (simple payment form)

- Configuration:
   - Add a new settings in the invoicing config menu "SEPA QR Code" to activate QR
     Code payments
   - Show an explicit warning if the journal is not well configured to manage qr
     code (bank account set, etc.)

- Display: show the qr code after the 'Thank you' message (in web page and printed
  documents).

מזל טוב

The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.

Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily

Adapt the css and views to be easier to switch direction

Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language

add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY

This commit brings a new module to handle the automatical
purchasing of services, like stock does but without using
routes.

On a service product, a checkbox need to be check and a
supplier has to be defined. On SO confirmation, a Purchase
Order will be generated.

See commits details for more details.

Task #39340
Closes #25221

This commit adds a new module providing the automatically services
purchasing feature ("Service Subcontracting").

The product of 'service' type can be flag (in the purchase tab of
its form view) as "purchase automatically".
When adding an sale order line with that kind of product, it will
generate a Purchase Order for the supplier of the product, on Sales
Order confirmation. The PO will contains one line with the quantity
on the sale line, with the UoM conversion (purchase uom might be
different from the sale uom on product configuration). The generated
PO is in draft state.

Then several cases can happen:
1/ Increasing the quantity on the sale line
    - If PO is draft state ('draft', 'sent', 'to approve') : increase
      the quantity on the PO
    - If PO is confirmed state ('purchase', 'done', 'cancel') : create
      a new PO
2/ Decreasing of quantity on the sale line
    - in any cases: shedule a next activity on the PO
3/ Cancelling SO: shedule a next activity on the impacted PO
4/ Cancelling PO: shedule a next activity on the origin SO

The introduction of this module required to move the link between
sale.order.line and purchase.order.line from stock_dropshipping to
thie module, and put sale_purchase as a dependency of
stock_dropshipping.

This commit also brings some test cases.

Task #39340
Closes #25221

Now, the style of exception activity depends on
the activity subtype, since a global warning type
exists.

Add a data common for all models have the 'decoration'
type set to 'warning' to schedule alert activities.
This can be usefull when activities are generated on
related model changes.

Task #39340

This commit extends the activity API to allow scheduling
activity with a Qweb template to format the activity message.

Task #39340

Impacted modules: sale, sale_timsheet, sale_stock, delivery and
event_sale

The commit ee2b9fae split the
implementation and the api of the `action_confirm` method of
a Sales Order.

This commit tries to go further:
1/ change this API: the private method is the implementation that
should be extended when the confirmation should generated other
documents. The state change is extract to be sure that in all
override of `_action_confirm` the SO state will be 'sale' (and
not 'done', in case of activating the options).

2/ adapt other module to this new API. Some of them does not required
the change to correctly work, but it can introduce future bugs.
Doing it now is better ;-)

3/ With this new implementation, we can prioritize SO line treatment
on confirmation. We want the stockable lines to be processed before the
service ones. Indeed, the line (service and stockable) that should
create a purchase order (future dev for services) will search for an
existing PO, but stock has more precise criteria than services. So,
service SO line will find the existing PO from stock while the opposite
is not true.
So, this is why we are now calling `_action_launch_procurement_rule`
before the `super`.
The rest of the treatments (event, delivery, ...) depends on the module
loading order.

Task #39340.

This commit dissolves module into sale and sale_stock. Indeed
some fields will be needed for services in next development.
- module is replace by a group in sale
- `commitment_date` and `expected_date` are moved into sale
directly, because they are meaningful for purchasing services
- `expected_date` implementation change when sale_stock is
installed, as the picking_policy of the SO determine if the
min or max dates should be chosen.
- `effective_date` is moved to sale_stock
- tests are moved into sale_stock, and tagged to be executed
after install (post install) otherwise it fails (since
sale_order_dates was a leaf module, it makes sense).

From a functionnal point of view, nothing should have changed,
except that user can see `commitment_date` and `expected_date`
even if sale_stock is not installed, by activating a group.

Task #39340