[MOV] move sale_payment into sale
=================================

Almost all use cases of sale require sale_payment down the line.

There is only one case which does not: using sale_management without website_sale or website_quote.

However, since we want to move most of the features of website_quote into sale_management, moving sale_payement first will make the task easier.

[MOV] move website_quote into sale and sale_management
======================================================

We want to use some features of website_quote without having to install the whole module.

The main issue with website_quote was that it had a requirement on website.

What is common to website_sale and sale_management has been moved into sale. This is primarily the sales order portal view.

What is only related to sale_management has been moved into it. This is notably: sales order templates, optional products, sign and pay, ...

Everything that requires website has been moved into a new module named sale_quotation_builder. This is related to using the HTML builder to customize the quotation view.

Models, files and routes have been renamed to better convey their purpose and to follow guidelines more closely.

[IMP] merge sales order portal views
====================================

The old sales order view on the portal has been merged into the one from website_quote. The new view contains features of the two.

A lot of fixes and improvements have also been done, related to BS4 issues but also to improve the sales order view in general.

[IMP] add new settings
======================

The commit adds new settings related to activating the features that previously were activated by installing website_quote.

PR: #26345
Task: 49205, 1838924

Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
  the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
  The share link can be used in this case.

Specifications
==============
For any object inheriting form portal.mixin:
    - Add a button SHARE (not visible in edit mode)
    - When clicking on this button, a popup opens with :
        - A warning message for tasks and projects only (see below)
        - the link (like in gmail) that can be copied
        - Recipients
        - mail composer (with preselected template) ==> see below
        - button [Send Link] [Copy Link] Discard
        - After sharing document, put internal note like
          "Document shared to xyz,...." with template message
    - Anyone with the link, even anonymous user (not logged in) can have access
      to the document with the access token provided in the url.

Impacted models:
    - account.invoice (Community)
    - project.project (Community)
    - project.task (Community)
    - purchase.order (Community)
    - sale.order (Community)
    - helpdesk.ticket (Enterprise)

Warning messages and access rules:
    Allowed :
        - SO canceled or draft will be accessible with the link
          with access_token
        - If the customer account is B2B (signup not enabled), the recipient
          will anyway see the document as the user specifically wants the
          recipient to see the document.
    Restrictions :
        - For Project and Task, if the privacy is not public, then, there is a
          contradiction between the access_token mechanism
          and the privacy of the document.
        - A warning message will be displayed in the share wizard to inform the
          user if the document cannot be visible by the recipients and to
          ask him to set the privacy to 'Visible by following customer'.
          The send button will, in that case, be hidden.
        - To avoid to block the share for a new project, default privacy value
          is now set to 'Visible by followong customer'

Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
  to the portal.mixin to be able to use it in a generic way for each object
  inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
  into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
  portal module
- Remove the init_column + default value for the access_token
  > old records have an access_token,
  > new one won't but it will be generated on demand via the get_access_token
  Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
  (except for task and project where button not in action menu but 'simple'
  button for task and project because other modules already provide action
  to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
  if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
    If false : The direct portal view url
    If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code

- Bug fix :
    - Before, if user was not logged and record had partner_id,
      if partner id was null, post message was done as admin.
      Now, the post message is done as public user.
    - If the user had an uid but had no access_token, he could be able
      to gain the access token of the record.
      check_access_rights was missing in the get_access_action.

Task ID : 30985
Closes #25629

The goal is to be able to more easily create section and notes on sale order, invoice, and quote.

================================
Problems of the existing feature
================================

The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here.

Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present.

==================
New implementation
==================

Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section.

We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal.

=========
Reasoning
=========

We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code.

Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by).

The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note).

We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier.

No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done.

===========
Limitations
===========

The current solution has several limitations:

* since the sections don't have business logic, it's not possible to make any reporting based on them

* any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display

- when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section

===========
Technically
===========

The commit will:

* update the models to add the display_type field (along with related sql constraints to guarantee integrity)

* add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button

* add some business checks to not apply business to section/note (product_id and account_id became non-required fields)

!!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix.

* update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently)

!!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix.

Task #53996
PR #25209

Both features already existed but it was not possible to enable both.
This makes that possible. When both are enabled the quotation first has to be
signed, then it can be paid.

Purpose
=======
No way to combine digital signature and online payments to confirm orders.
A customer signature matters for big deals, in order to keep an official print
of customer agreement.

Specs
=====
- when the customer signs online, a new pdf is generated with the customer
  signature on it and posted as a note in the chatter, replacing the current
  signature jpg.

- show the signature in the portal view, with both sale_management and
  website_quote module

- change in settings: Digital Signature and Electronic Payment are now 2
  checkboxes instead of a radio button

- these settings must be company-specific (add company icon if multi-companies,
  like other company-specific settings)

- when both modes are activated, it first request the signature, then the
  payment

- the order is confirmed after payment

opw-1818837
Closes #24174

It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log

This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.

To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.

Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043

[FIX] add domain based on journal to payment tokens

Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200

- When a quotation if viewed by a customer, a note is posted in the quotation's chatter saying "Quotation viewed by customer".
  This is causes issues if the quotation is accessed without the access token and by a partner that do not have the rights to write on the model "sale.order".

  To address this issue we provide to the "_message_post_helper" function the sale order's access token to bypass the accesses checks.

  OPW-1839183

Commit 542201eed39 added the possibility to configure a set of countries for a
given payment acquirer.
Commit 194d52e8fda35 refactored the payment form, but forgot to take the country
into acount.

opw 1837819