Prior to this commit, using a `/banner` block would create elements that always
have `contenteditable` attributes when saving, that are always different from
the server value which removes these `contenteditable` attributes, resulting in
a new `Wysiwyg` instance being constructed after each `save`.

Resolution:
1- Introduce new classes to handle the `contenteditable` attribute:
  `o-contenteditable-true` and `o-contenteditable-false` to avoid a namespace
  conflict with `website` specific features. They replace `o_editable` and
  `o_not_editable` for the `banner` block.
2- Ensure that `contenteditable` attribute handled by these classes are removed
  during `cleanForSave`, to create a value comparable to the server value. This
  is because the server sanitizes the `contenteditable` attribute. If both
  compared values are not equal, the current `Wysiwyg` and `Editor` instances
  would be fully replaced after each save, resulting in a loss of edition
  history. This should ideally never happen.
3- Ensure the attributes `role` and `aria-label` which are also sanitized by the
  server are removed during `cleanForSave` and maintained during
  `normalize` through `data-oe-role` and `data-oe-aria-label`.
4- Introduce a `o_editor_banner_content` class for the `banner` content, for
  ease of selector creation.
5- Ensure that the `baseContainer` created before the `banner` if it is the
  first element in the `editable` has the proper `tagName` based on the
  `HtmlField` configuration.

A `html_migrations` version is added to adjust existing `banners` to the new
classes usage.

task-4640490

Forward-Port-Of: odoo/odoo#201139

**Current behavior:**
Adding a product which is invoiced based on delivered
quantities to the delivery of a sale which has already been
confirmed, then validating the delivery, does not reflect the
change in price (which will be invoiced) on the sale order.

**Expected behavior:**
The sale order should show the actual amount of money to be
charged to the orderer.

**Steps to reproduce:**
1. Create a stored product with some price and change its
invoicing policy to 'delivery'

2. Create a new sale order, add 1 of the created product,
then confirm it

3. Open the delivery, add another line to it for the same
created product, fill in the quantities for each move, then
validate the picking

4. Check the sale order line to see that, while the price unit
is populated with the product's price, the subtotal/total fields
are not

**Cause of the issue:**
Order lines added in this manner have `product_uom_qty == 0`
which will zero-out the price computation.

**Fix:**
First, `_compute_purchase_price` is modified such that lines for
standard cost product will have a value computed (where
previously they were skipped).

Then for `_compute_margin`:
use `qty_delivered` and an on-the-fly calculated
`price_subtotal` to find a margin value for a SOL added from a
delivery (which is determined when `product_uom_qty == 0` and
`qty_delivered != 0`

opw-4210056

Forward-Port-Of: odoo/odoo#186236

Steps to reproduce:
- go to a blog post with several paragraph
- edit translations

Issue 1:
- select several paragraph completely and use the translate tool
- insert the translation
=> the translation are not inserted

Issue 2:
- select 3 paragraphs but don't start at the beginning or end of
  the text
- insert translation
- see that all translations is inserted at end of paragraph 1, paragraph
  2 is emptied and paragraph 3 selected part is removed
- save
=> paragraph 1 and 2 are deleted (so we show original lang value),
   selected part of paragraph 3 is removed

Why:

In the blog post content, we are inside a "blog.post().content"
editable field, this allows the editor to select several translations
nodes which will work wrongly with the editor because translation mode
only expect to change the content of translation nodes.

The first paragraph translation is saved empty because the editor is
cloning the node with the same "data-oe-translation-source-sha"
because we are inserting several paragraphs inside it.

Fix: in translation mode, make the editable node of html fields around
translation nodes uneditable so we can't select several translation
nodes thanks to how browser handle selection and content editable.

Note: the added test step is very light, because in javascript it is
programmatically possible to select 2 separate content editable. At the
step that is added in the tour, with the fix it is not possible to
select both the H1 and P nodes.

opw-4221993
opw-4482717

pr note: opw-4221993 could possibly solved by this fix too (the video reproduction seemed to be about a bulleted list but I could not reproduce, and the original report video is deleted)

Forward-Port-Of: odoo/odoo#204188
Forward-Port-Of: odoo/odoo#197511

**Problem:**
In the purchase app, when selecting 2 Purchase Orders that have
different currencies, and clicking Action then Accrued Expense
Entry, a traceback will appear. It works as intended if the two
Purchase Orders have the same currency, but if there is more than
one currency, the traceback will be displayed.

**Steps to reproduce:**
- Go to the purchase app and select two Purchase Orders that have
different currencies (you can make a group by Currencies).
- Click on Action then Accrued Expense Entry.
- The traceback appears.

**Cause of the issue:**
https://github.com/odoo/odoo/blob/a07a8589a8cb391a801ef1ffd60e02d83fc963f8/addons/account/wizard/accrued_orders.py#L246
The currency is given as a parameter to a function that requires
only one parameter. With this code, if there are multiple
currencies in orders, all of them will be given, which
creates a traceback.

**Fix:**
After checking with a PO, the multiple currency use case is not
supported. Hence make sure that there is only one currency in the
quotations we are trying to work with. If there is more than one,
we throw an error telling the user to only pick quotations with
the same currency.

opw-4562933

Forward-Port-Of: odoo/odoo#204007
Forward-Port-Of: odoo/odoo#202733

* stock{,_barcode, _barcode_quality_control}, quality_control

### Issue:

Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.

The above issue can be triggered in many situations. Here are the two major ones:

### Use case I:

Creating a delivery or an internal transfer on the fly from the barcode app.

### Steps to reproduce:

- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133

### Use case II:

Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailled operations.

### Steps to reproduce:

- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.

### Fix:

We ensure the creation of quality checks for moves that end up being created but will never be confirmed.

### Technical limitation:

Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.

Enterprise: https://github.com/odoo/enterprise/pull/81850

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

Forward-Port-Of: odoo/odoo#203662
Forward-Port-Of: odoo/odoo#202725

We encountered an error when trying to open `Furniture` or `Clothes` from the 
`Dashboard` if the Administrator has been assigned Admin rights to a new user.

Step to Reproduce:
- Install the Point of Sale module without demo data.
- Navigate to `Settings` > `Users` and `create` a new user with `Admin rights` of POS.
- Log in with the newly created admin user.
- Try to load sample data for `Furniture` or `Clothes`.

Traceback:
```
while parsing /home/odoo/src/odoo/saas-18.1/addons/product/data/product_demo.xml:5, somewhere inside
<record id="base.group_user" model="res.groups">
            <field name="implied_ids" eval="[(4, ref('product.group_product_variant'))]"/>
        </record>
```

Error[2]  generated when solving above problem :

Traceback :
```
while parsing /home/odoo/odoo/community/addons/point_of_sale/data/orders_demo.xml:86, 
somewhere inside <function model="pos.session" name="update_closing_control_state_session" eval="[[ref('pos_closed_session_1')], '']"/>
```

This issue was occuring since new users does not have access right of `res.groups`.

This commit will fix the above errors by using Superuser environment to load data..

sentry-6239966848

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

Forward-Port-Of: odoo/odoo#195374

Relocated the get_fiscal_year_start_date method from l10n_in_reports_gstr to l10n_in_reports to ensure availability even if the GSTR module is uninstalled.

This improves modularity and prevents dependency issues.

Trace-back:
```RPC_ERROR

Odoo Server Error

Occured on 77578514-18-0-all.runbot143.odoo.com on model account.report and id 10 on 2025-04-01 13:02:27 GMT

Traceback (most recent call last):
  File "/data/build/odoo/odoo/http.py", line 1962, in _transactioning
    return service_model.retrying(func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 156, in retrying
    result = func()
             ^^^^^^
  File "/data/build/odoo/odoo/http.py", line 1929, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http.py", line 2177, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http.py", line 727, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/web/controllers/dataset.py", line 36, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/api.py", line 533, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 5225, in get_report_information_readonly
    return self.get_report_information(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports_cash_basis/models/account_report.py", line 17, in get_report_information
    info = super().get_report_information(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 5209, in get_report_information
    'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2544, in _get_lines
    dynamic_lines = self._get_dynamic_lines(options, all_column_groups_expression_totals, warnings=warnings)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2996, in _get_dynamic_lines
    rslt = self.env[self.custom_handler_model_name]._dynamic_lines_generator(self, options, all_column_groups_expression_totals, warnings=warnings)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_in_reports/models/l10n_in_report_handler.py", line 173, in _dynamic_lines_generator
    self._get_out_of_fiscal_year_reversed_moves(options)
  File "/data/build/enterprise/l10n_in_reports/models/l10n_in_report_handler.py", line 146, in _get_out_of_fiscal_year_reversed_moves
    ('reversed_entry_id.invoice_date', '<', AccountMove.get_fiscal_year_start_date(self.env.company, datetime.strptime(options['date']['date_to'], '%Y-%m-%d')))
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'account.move' object has no attribute 'get_fiscal_year_start_date'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
    RPC_ERROR
        at makeErrorFromResponse (https://77578514-18-0-all.runbot143.odoo.com/web/assets/3b85f28/web.assets_web.min.js:3153:163)
        at XMLHttpRequest.<anonymous> (https://77578514-18-0-all.runbot143.odoo.com/web/assets/3b85f28/web.assets_web.min.js:3158:13)```

Forward-Port-Of: odoo/enterprise#82775
Forward-Port-Of: odoo/enterprise#82681

Description
-----------
The non-stored field `user_has_access` is the primary `ir.rule` used for a `knowledge.article` and is included in every query. As a result, the method `_search_user_has_access` is frequently called and quickly becomes a performance bottleneck. This is particularly noticeable when opening the Knowledge app, as it involves reading the displayed article along with loading the sidebar.

This update optimizes the method as follows:

- For generic article access, the optimization leverages the field `inherited_permission`, which already contains the propagated `internal_permission` of the article along the hierarchy. This removes the need to recompute these permissions dynamically with a complex query since the data has already been precomputed.
- For member access, the query logic has been revised while maintaining the same outcome: Previously, the process involved: `for all articles, append the member and their permission, recurse into child articles for all in-sync and permissionless articles, and propagate the member's permission. Finally, discard all articles without any set permission.`, The new approach reverses the logic to avoid the need for discarding at the end and iterating through all articles: `for the articles the member belongs to, propagate the member's permission to its child articles, provided the child is in-sync, has no explicit permission, and the partner is not already a member of that article.` Although the last condition may seem counterintuitive, the initial set of articles considered encompasses those the member is linked to already. This also avoids cases where a parent article's member permission would overwrite differing permissions on its child articles.
- Additionally, `set` manipulations are used to handle IDs, thereby preventing the injection of large ID lists into multiple domain leaves. This improves query parsing and avoids poor query execution plans that could be caused by excessively large ID lists.

Benchmark
---------
On odoo.com, opening the Knowledge app from the Apps dashboard:

| Request              | Before | After | Speed-up |
|----------------------|--------|-------|----------|
| web_read             | 1.69s  | 160ms | **10x**  |
| get_sidebar_articles | 1.64s  | 160ms | **10x**  |

In a shell, searching articles with `[('user_has_access', '=', True)]`:

| User Type             | Before | After | Speed-up |
|-----------------------|--------|-------|----------|
| `sudo`                | 251ms  | 35ms  | **7x**   |
| regular internal user | 577ms  | 58ms  | **10x**  |

Reference
---------
task-4633813

Notice
------
⚠️ Note to clients/partners that might read this: For the full benefits of the patch, deploy the indexes that were added in this PR. This can be done by Upgrading the module `knowledge`, or creating the indexes manually in database. The patch should still be a net-benefit even for database without the indexes deployed.

Forward-Port-Of: odoo/enterprise#80971

Currently, an exception is generated when the system tries to find the 'Out of Contract'  work_entry_type after it has been deleted.

Steps to Reproduce:

1 - Install hr_payroll module without demo data
2 - Navigate to hr payroll -> configuration -> work entry types 
3 - delete the 'Out of contract' work entry type
4 - Navigate to hr payroll -> Contracts -> Contract 
5 - Create a contract with a start date next to the current. 
6 - Navigate to hr payroll -> payslips ->  To pay
7 - Try to create Payslips To Pay for created contract 
8 - an error occurs

Error:
```ValueError
External ID not found in the system: hr_payroll.hr_work_entry_type_out_of_contract
```
This issue[1] occurs because when the system tries to reference the missing 'Out of Contract' work entry type it results in a ValueError due to a missing required record. The same issue [2] occurs in the `l10n_hk_hr_payroll` module.

[1] - 
https://github.com/odoo/enterprise/blob/265177dfd281f3aa1d61db6587ddfa37790570fe/hr_payroll/models/hr_payslip.py#L597

[2] -https://github.com/odoo/enterprise/blob/31e56779f8e0011ddc5c1a2821f68c8f041efbe4/l10n_hk_hr_payroll/models/hr_payslip.py#L180

This fix resolves the issue by ensuring that if the `Out of Contract` work entry type is missing, it returns a false value. A similar fix has been applied in `l10n_hk_hr_payroll`. Additionally, code has been added to prevent the deletion of any work entry type using @api.ondelete.

sentry-6277939517

Forward-Port-Of: odoo/enterprise#82659
Forward-Port-Of: odoo/enterprise#79053

When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref.

(Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.)

Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a now FBM offer.

While that second case would only require the user to delete and recreate a new offer (which would be a bother but not that problematic), sending a quantity to a FBA offer would trigger a well known problem of ghost listing on Amazon, where Amazon will consider having both channels, and randomly set an order as either FBA or FBM, until that ghost listing quantity drop down to 0.

When catching a discrepancy, we'll thus reset the value of the amazon_feed_ref, so that it'd be pulled again later if needed by the sync inventory with, this time, the correct value. This would also stop the inventory synchronization of a potentially FBA offer.

As for any stock synchronization that might happen between the listing changes from Amazon side and the first order received in FBA, we decided against forcing the FBM quantity to 0 on all FBA offer every time, to avoid sending too many useless calls for a corner case. As the product was until now sold in FBM, in most cases, it can still be until the end of the ghost listing. If not, our support is aware of it and can force the quantity to 0 again.

opw-4681035

Forward-Port-Of: odoo/enterprise#82754

* stock{,_barcode, _barcode_quality_control}, quality_control

### Issue:

Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.

The above issue can be triggered in many situations. Here are the two major ones:

### Use case I:

Creating a delivery or an internal transfer on the fly from the barcode app.

### Steps to reproduce:

- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133

### Use case II:

Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailed operations.

### Steps to reproduce:

- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.

### Fix:

We ensure the creation of quality checks for moves that end up being created but will never be confirmed.

### Technical limitation:

Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.

Community: https://github.com/odoo/odoo/pull/202725

opw-4480104

Forward-Port-Of: odoo/enterprise#82291
Forward-Port-Of: odoo/enterprise#81850