- remove the "delete" button with the base.group_no_one gruop from
 the sign.request kanban view (accessible through form if needed,
 and archive should be promoted)

- delete the menu "Properties" on the sign.template kanban dropdown
 (replaced below)

- add a button (secondary) at the right of the "tags" and at the
 left of the "saving" indicator that takes you the form view of
 the template

- remove the "Edit Fields" stat button from the form view of the
 sign.template (I just reversed the logic, you now go from the
 field edition to the advanced properties instead of the opposite)

 - create a new group "Manage template access" that can be enabled
 through the Sign Settings for the whole db have the (remaining)
 fields "group_ids"' and "user_id" of the sign.template model
 visibility be controlled by that group in the template form
 view and in the template edition view

- unhide the tab "Fields" from the debug mode in the view
 sign.template.form

- delete the menu "signature requests items" completely

- remove menu "Field Types", but add an equivalent action
 to access them from the Settings (see screenshot "Field Types")

- add a help string/tooltip on the field "tip" on model
 sign.item.type: "Hint displayed in the signing hint"

task-id : 2871447

The master plan finally comes to an end.

Thanks to:
- odoo/odoo#87522 refactoring `load_views`,
- odoo/odoo#94337 refactoring `common.Form` to prevent changing
    invisible fields in unit tests using `Form` instances,
- odoo/odoo#95729 refactoring the behavior of `groups=` in views,
- odoo/odoo#98551 removing the need of the `groups_id` many2many field
    on back-end views.

The result returned by `get_view`/`get_views` can now finally be easily
and efficiently cached, in order to cache back-end views.

The goal of this revision is to cache the model views and fields
already post-processed for the web client
(with the modifiers, etc., already computed)
without group restriction.
Then, from this cached version, post-process group related features,
such as removing nodes restricted with a `groups=` attribute,
set the create/write button according to the user access rights to models, ...

Not including the groups in the cache key allows:
- to have less cached versions,
  (otherwise it would be one cached version per different group combination)
- to not have to fetch the user groups to compute the key
  (with the current cache key,
  there is nothing to fetch from the database to compute the key)

Besides, post-processing the groups features
after taking the view from the cache of the view doesn't take a tremendous time:
 - parsing arch from/to string with etree is fast,
 - removing the `groups=` nodes using etree is fast,
 - adding the `create="False"`, `write="False"`, `delete="False"` on the view
   root node according to the access right of the user on the model is fast.

This allows way faster calls to `get_views` by the web client,
as the server no longer need, for each call, to fetch the views in database,
combine the inherited views, post-process the modifiers attributes, etc.

Timing tests are available on the community pull request odoo/odoo#99417

This PR aims to deeply change the behavior of sale_subscription following https://github.com/odoo/enterprise/commit/e09167bbbd5f4b731624af05831dfdcdab56828b and https://github.com/odoo/enterprise/commit/8fe6c96558bc9fb9f3655fa52fcbea3fea38afdd We decided to revert one behavior of these commits. We will only allow one invoicing periodicity per contract. Having the possibility to have several different periodicity per contracts had several drawbacks:

- It brings a lot of code complexity
- From a functional point of view,  it can be difficult to have a global point of a view on a client contract when several renewals and upsell happened.
- It is not a primordial need.

This PR updates sale_temporal, sale_subscription* and sale_renting* and bring several fixes.

[IMP] sale_temporal: create recurrence object and fields from sale order lines
-------------------------------------------------------------------------------------------------------

Before this PR, https://github.com/odoo/enterprise/commit/e09167bbbd5f4b731624af05831dfdcdab56828b and https://github.com/odoo/enterprise/commit/8fe6c96558bc9fb9f3655fa52fcbea3fea38afdd introduced the product pricing records linked to sale order lines. It was inspired by the rental module and seemed fitted for subscription.
Unfortunately, after some deep testing, we came to conclusion that this design
was not the best suited for subscription management.

We decided to move back the start_date and next_invoice_date to sale_renting
as sale.order would carry these value in sale_subscription. This commit
introduces a few changes:

- We needed a new type of records: sale.temporal.recurrence. It is defined by
  the duration and unit that were previously defined on the product_pricing.
  We could not used uom because it would be impractical to deal with time UOM.
  One month do not always contain the same number of days and a year
  do not always contain the same number of days. Creating recurrence specific
  UOM would be quite complex to use as it should not be mixed with existing time
  UOM.
- As some SO now have a longer duration (rental, subscription), we added a new
  field: internal note to help the user to centralize the information about the contract.
- As the pricing override the pricelist item price value, we decided to display
  the information on the pricelist view to help people to configure their pricelist
 rules.

[IMP] *sale_subscription*,partner_commission: Save recurrence on the sale.order and not the line
---------------------------------------------------------------------------------------------------------------------------------
In this PR, we adapt the sale_subscription's modules to the changes in sale_temporal.

Most of the changes consists to move the recurrence from the line to the
sale.order. The next_invoice_date and start-date is now stored on the SO.
The recurrence_id field is a sale.temporal.recurrence record and it defines
the periodicity of the sale.order. The next_invoice_date is directly derived
from it.

We also decided to move the pricing_id field to the sale_subscription module
because it was not useful in rental.

This commit introduce also a big change in the invoicing of subscription.
Before this PR, the payment_mode field on a sale.order.template would define
if the recurring invoices should be:
manual: created manually by the salesmen
draft_invoice: created in draft
validate_send posted and sent
success_payment: paid with a payment token and then sent.

Remove the payment_mode field on sale.order.template
--------------------------------------------------------------------------

After this PR, recurring invoices are created and posted if there is no
payment token on the sale.order and charged with automatic payment if the
payment_token is present. It bring more flexibility and allows a customer to
don't save his payment method if he don't want to.

[FIX] *sale_renting*: Apply change to sale_temporal to sale_renting
------------------------------------------------------------------------------------------
*sale_renting* module are updated to rely on the sale.temporal.recurrence records.

The sale.order.line don't have the next_invoice_date value. Only the
return_date remains for rental lines.

[FIX] sale_subscription: payment update next invoice date for auto_invoice
---------------------------------------------------------------------------------------------------

Reproduce:
- automatic_invoice setting is set
- Create a draft subscription with a valid payment token
- Send the quotation to the customer
- Customer sign and pay the sale order
--> Two invoices are created.

- One during the sale flow (_reconcile_after_done --> _invoice_sale_orders)
- The other invoice is created when the invoicing cron of subscription run.
It happened because the next_invoice_date was not updated after the first
invoice.

After this commit, the next_invoice_date can be updated from 3 locations:
- In _create_invoices on sale.order when the automatic payment by token
  is disabled.
- In reconcile_pending_transaction on sale.order for subscriptions with valid token
  It ensures that the next_invoice_date is only updated once the payment
  succeed to avoid proving a service when the customer has no valid payment
  method.
  _invoice_sale_orders  on payment.transaction for the first invoice with automatic payment when
  a valid token is saved on the order.

We tried to override _create_transaction in the portal to use a proper
callback_method to reuse reconcile_pending_transaction but after that,
_reconcile_after_done and _invoice_sale_orders are called by the sign code
and the sale order is invoiced twice.

[FIX] sale_temporal: compare abs value when looking for the best pricing
--------------------------------------------------------------------------------------------------

Before this commit, the lowest price would be selected to return the best
pricing rule. When negative price are set, the highest 'discount' would be
returned each time. jackpot !

Various
----------

- Improve the amount of information logged in the child contract when creating
  a renew or an upsell.
- fix close button. Before this PR, the close button canceled the SO but when it needs to be closed with a reason.
- Before this PR, nothing prevented a quotation to be confirmed when there
  was already a confirmed quotation for a subscription. This would create two
  running contract for the same client. This commit prevent it by raisong an
  error when the salesmen try to confirm the second quotation.
- Add some badge information to help understand if a SO is renewed, renewing, upselling, a renewal or an upsell.

taskid: 2942621