**[FIX] mail: stop the bubbling of various click events**

Technical Reason:

- The events bound to the specific elements inside the `FileViewer` are
  propagating/bubbling up and are triggering the [`onGlobalClick`](https://github.com/odoo/enterprise/blob/eaf40edbbacfc6a8eb9e0137c20e7f94b1f5d723/documents/static/src/views/kanban/documents_kanban_renderer.js#L36-L42) event bound on the [`DocumentsKanbanRenderer`](https://github.com/odoo/enterprise/blob/71dbc617d6fe533c4d0153361f9711bd4c9e4885/documents/static/src/views/kanban/documents_kanban_renderer.xml#L6)

After this commit:
- Only the events bound to the specific HTMLElements are now triggered.
- We successfully prevent the unnecessary call of the `onGlobalClick`
method mentioned above.


link to the related enterprise PR (contains the test case for this fix)-
https://github.com/odoo/enterprise/pull/55150

Task-3489455

Forward-Port-Of: odoo/odoo#150754
Forward-Port-Of: odoo/odoo#142807


---

The issue of the `DocumentsInspector` losing focus on the selected document is not observed in versions saas-16.4 and above because -

**Previously (i.e. in versions 16.3 and below),**
 
- The document we click to preview used to get selected, it was then passed to the `DocumentsInspector` as the `selection` prop.
- The inspector relied on the [`nbPreviews`](https://github.com/odoo/enterprise/pull/40441/files#diff-2d135414449d55788e2e9449cab08f4d30f006fa009824bb1d17afa00c63d810R19) i.e. `props.selection.length` to evaluate which template to render for the `DocumnetsInspector`.
- It is this line --> `this.props.list.selection.forEach(el => el.toggleSelection(false));` inside [`onGlobalClick`](https://github.com/odoo/enterprise/blob/saas-16.3/documents/static/src/views/kanban/documents_kanban_renderer.js#L36-L42) method, which toggles the selection to `false` and now when the inspector appears to lose focus and paints itself with the template when no document is selected.

**Now (saas-16.4 and above)**
- We use the [`documents`](https://github.com/odoo/enterprise/pull/40441/files#diff-2d135414449d55788e2e9449cab08f4d30f006fa009824bb1d17afa00c63d810R7) prop as a condition to render the inspector. [`documents` prop initiallisation](https://github.com/odoo/enterprise/pull/40441/files#diff-0011f60b4981cbcd7e4c5f6fbee6c682ce7187f8f85d3beb3fac0bb4f07a6c01R101).
- The inspector no longer relies on the actual selection of the documents for deciding on which template to render. And hence it doesn't lose focus even if the `onGlobalClick` deselect the selected documents.
- Also, the props passed to the inspector are only reset when we close the FileViewer. 
ref - https://github.com/odoo/enterprise/blob/saas-16.4/documents/static/src/views/hooks.js#L317

PR that introduced the above changes - https://github.com/odoo/enterprise/pull/40441

Steps to reproduce the bug (starting from saas-16.4 only!):
- Go to the website app
- Enter edit mode => Bug: the editor toolbar appears for a few ms, then disappears.

This bug occurs since [1], whose original commit was actually merged in 16.0 with [2]. The reason the bug only appears in saas-16.4 and not 16.0 is because of [3].

Commits [1] and [2] change the elements that are considered "tab-able" and thus the elements that can be auto-focused by the `useActiveElement` hook. That hook is actually used when we enter edit mode since [4], as a way to declare the editor as the active element so that keyboard shortcuts work (as indicated by the related commit).

What actually happens thanks to the hook is that once we enter edit mode the "Block" button of the right panel is focused. This is because it is considered to be the first "tab-able" element (with or without [1]/[2]). Then keyboard shortcuts work as expected as the right panel is focused.

However, since [3], the `useActiveElement` hook is called "too soon". Indeed the right panel is not actually inside the "auto-focused" editor container yet**. The result is that what is now "auto-focused" is the editor toolbar***. Before [1], the element in the toolbar that was focused was an invisible one, so no bug appeared. Since [1], we only auto-focus visible elements... so we now focus a visible element in the editor toolbar, making it visible during editor instantiation.

This commit fixes the issue independently of [3] (which is why this targets 16.0: to consolidate the codebases). Actually, the use of the `useActiveElement` hook added by [4] is useless. It was fixing the issue at the time, but the real solution was to do what was done since at [5]. Indeed, the keyboard shortcuts were not working because the backend navbar was still visible (even if outside of the viewport) so it was its keyboard shortcuts that took precedence. Since [5], the use of `useActiveElement` actually has not benefit anymore. The editor is part of the backend UI, the backend UI is still focused after entering edit mode, shortcuts targeting the editor panel are thus working naturally. Removing the use of the `activeElement` hook only has one side effect: the "Block" button of the right panel is not auto-focused anymore... which is not needed.

Notes:

- The `useActiveElement` hook also has another purpose: allowing cycling using tab and shift-tab, it should work naturally as with the backend UI anyway but mainly: tab and shift-tab do not seem to be working with the editor UI anyway.

- Another hint that [4] was not right way to go is that this is the only use of the `useActiveElement` hook in the whole codebase, except for the framework use for dialogs.

- ** That should maybe be solved on its own, although maybe it is not important and risky at best.

- *** The editor toolbar should not even be instantiated that way in the first place since it will be attached to the right panel later... but that is another issue.

[1]: https://github.com/odoo/odoo/commit/c631bf09b927003edc4c2b85e8790e8e2e8c044a
[2]: https://github.com/odoo/odoo/commit/57452ee59c3e33eaa219d8d7b8d82239fd33b722
[3]: https://github.com/odoo/odoo/commit/76d4f9811b756f0e57b0a33dbba534c900c7fe15
[4]: https://github.com/odoo/odoo/commit/b0108e1876a27e83231e176cdca3e2d67d6a2a9c
[5]: https://github.com/odoo/odoo/commit/cdc8d4c889b316664323afad0d848403960150d5

task-3686730

Forward-Port-Of: odoo/odoo#151373
Forward-Port-Of: odoo/odoo#151209

**[FIX] sale_product_configurator: allow type False for customValue**

Steps to reproduce(locally):
1) Create SO with the product that has a custom value attribute
2) Leave the custom field empty
3) Save SO and open product configurator again
4) Observe TypeError traceback

Reason: customValue is supposed to be string but if value is not set,
it remains False which cause a type error.

After this commit: allow customValue be false

**[FIX] sale_product_configurator: set value for no_variant attribute**

Steps to reproduce:
1) Create product with an attribute that has several values and with an
attribute with 'create_mode = 'no_variant' and one value.
2) Create SO with this product, save
3) Open product configurator again and see the traceback

Reason: selected_attribute_value_id is not set.

After this commit: the attribure value is defined in get_values of
product configurator.

opw-3513685


**[FIX] sale_product_configurator,product: show archived combination**

Steps to reproduce:
1) Create SO with customizable product (example “Customizable Desk”)
2) Let default values in product configurator
3) Save SO
4) Go to product template, and in the Attribute remove all value
options, only leaving the custom value
5) Try to open the product in configurator in the saved SO

Reason:
archived combination is not loaded

After this commit:
When requested combination is archived, load it

opw-3513685

Forward-Port-Of: odoo/odoo#150653
Forward-Port-Of: odoo/odoo#146454

Description of the issue/feature this PR addresses:
The module `l10n_ch` after this commit https://github.com/odoo/odoo/commit/7a06ed07814ab8d9192d3a7ec15aba7f90f7294d  will have deprecated `account_report_expression` with dependent external values, which causes ForeignKey Violation during the upgrade. Upgrade tries to remove that `expression` because it is deprecated but it has dependent external values. 

Current behavior before PR:
Upgrade tries to remove that `expression` because it is deprecated but it has dependent external values. 
It will happen to all db's which were on at least `16.0` version before that commit https://github.com/odoo/odoo/commit/7a06ed07814ab8d9192d3a7ec15aba7f90f7294d 

Desired behavior after PR is merged:
That deprecated external values will be deleted in upgrade.
In here I delete that external values in migration file and increased the version of module from `11.1`-->`11.2`

UPG-1203672


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#150650

Before this commit, since [1], the "small" class behavior of Bootstrap was changed to use a fixed value instead of being dependent on the context (using `em` units).

This was a bad choice, given the fact that the "small" class could be used in the past with its previous behavior in custo but also in default Odoo layouts, where it could be use in more legit cases that the one Odoo currently offers: instead of applying the class to a whole paragraph, applying it to part of a title.
In that case, since [1], we can have a big title ... with a very small text next to it, which may be strange. Of course, the proper way to achieve a big title with a smaller text next to it would be to not use "small" but another hx font-size, but the legit bootstrap behavior which is to use their "small" class is thus broken.

This commit keeps the current possibilities (big title with very small text next to it) but does it by using new custom Odoo classes instead of changing the Bootstrap "small" one. That way, legit custo in previous versions (or trying to use default Bootstrap in this version) will be supported.

Note that this commit will impact existing 17.0 users though: if they actually configured a big title with small inner text... those will become big title with slightly smaller inner text (the default Bootstrap behavior). Worse: a big title whose size was reduced using the font-size selector and choosing "small" will now become a big title. We think this is worth the risk (see PR description for more visual details).

However, notice that "legit" use case of the "small" font-size in 17.0 will be kept untouched: e.g. adding a small text on its own or next to a paragraph: the "smaller" Bootstrap behavior is now computed based on the ratio of the configured base and small font-sizes.

Note that some additional "bugs" were found investigating this:
- Form descriptions use the "small" class for no reason and should probably not be possible to customize ("font style"-wise) anyway.
- The use of the "small" *tag* should probably be reviewed in all Odoo layouts and/or its interaction with the editor be fixed.

[1]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0

| Before this PR | After this PR |
| -------- | -------- |
| ![default_before](https://github.com/odoo/odoo/assets/10338094/e3b49b7d-bc7f-4115-8145-56d19b1d147b)   | ![default_after](https://github.com/odoo/odoo/assets/10338094/9faa6f73-772e-4318-8ea3-ced2a51d0423)  |
| ![custo_before](https://github.com/odoo/odoo/assets/10338094/77a4824c-32a8-4b1e-a4d1-664b81d9e557)   | ![custo_after](https://github.com/odoo/odoo/assets/10338094/cb196592-7ff1-4927-b01d-0687cae50be5)   |

=> Legit use cases untouched, weird use cases impacted (should be rare, especially see also the weird margin-top in the second one), custo use case (@JKE-be 's case) solved.

Forward-Port-Of: odoo/odoo#149590

Steps:
- Install subscription app and razorpay provider.
- Configure and publish razorpay provider.
- Create a subscription and pay via razorpay.
 - Now change system date to next recurring date.

 Issue:
 - Subscription is in `Payment Failure` state even though payment is successfully captured.

 Cause:
 - Because of concurrent update in database while creating transaction from token for recurring charges
 - When razorpay make tokenize request via `_send_payment_request` method then transaction process data via `_handle_notification_data` and from web-hook so it tries to write on transaction with same data multiple times and at same time subscription also tries to write so because of concurrent update it skips to write on subscription and subscription stays in `Payment Failure` state.

 Fix:
 - Handle writing on subscription in there state changing method instead of trying to write in between when transaction processing so it does not skip writing on subscription and properly set/remove subscription state.

 task-3652228

Forward-Port-Of: odoo/enterprise#53792

**[FIX] documents: validate document existence using `datapoint_id`**

Issue:
- The existing condition inside the `insert()` method incorrectly identifies
the incoming new record (data) as an already existing record inside
`this.store.Document.records`

Reason:
- It uses `id` to check for a new document, but the `id` remains the same in
the following cases.
   - In case of replacing a document with a new document.
   - Replacing the requested document with the new document.

- As a result, the records inside the `this.store.Document` remains inconsistent
with the records present in the database.

After this commit:
- We use the `id` of the record (ex- `datapoint_32`) to check for the
presence of a new document.

link to the issue being tested by the test case in this commit
(also the related community PR - https://github.com/odoo/odoo/pull/151144)

Task-3489455

Forward-Port-Of: odoo/enterprise#54969
Forward-Port-Of: odoo/enterprise#50098


---

- The test case in this forward port PR is different from its predecessor in the [v16.3 PR](https://github.com/odoo/enterprise/pull/50098) because 
  - It was based on checking the resultant UI changes caused by the call of the `onGlobalClick` method (inside the `DocumentsKanbanRenderer`).
  - But, the test case here directly checks if the method is called, and does not rely on the UI changes.
- Reason to change the test case - 
  - **The functional issue of the inspector losing the focus (as mentioned in https://github.com/odoo/odoo/pull/142807) is not observed for versions 16.4 and above.**
- Please take a look at the related community PR for more information.