This commit improves the handling of a document's discoverability setting (`is_access_via_link_hidden`) when it is moved between folders.

Previously, when a document was moved, it would inherit the discoverability setting from the destination folder. This could lead to unintended changes in a document's visibility. For example, a publicly discoverable document could become private (requiring a direct link) simply by being reorganized into a different folder.

This behavior was inconsistent with a previous improvement that prevented discoverability from propagating downwards from a parent folder to its children. See PR-93697.

With this change, a document's discoverability is now treated as an intrinsic property that is fully preserved when the document is moved. It is no longer affected by the settings of its destination folder.

To ensure clarity for the user, the move confirmation dialog has been updated to reflect this new logic. It now correctly informs the user that the document's original discoverability setting will be maintained.

Task-5159832

Forward-Port-Of: odoo/enterprise#97045

Currently, an error occurs when user sets the resource on a resource leave.

**Steps to Reproduce:**

 - Install `hr_contract` with demo data.
 - Go to `Resource Time Off`.
 - Create a new record and remove the `start date` value.
 - Select the `Anita Oliver` resource `(employee record with running contract)`.

**Error:**
`TypeError: '<=' not supported between instances of 'datetime.datetime' and 'bool'`

**Cause:**
This error occurs when the user removes the start date and sets a resource that is linked to an employee with a contract. In this case, the system groups leave records based on the contract [1], and while computing calendar_id for the leave, it filters records by checking whether the leave start date falls between the contract start and end dates [2]. Since the leave start date is False, the comparison raises the error.

Another issue is that when the user changes the start date, the calendar_id should be updated based on the employee’s current contract.

**Fix:**
This commit ensures that when setting or changing the resource_id, for contracts with and without a start date, the calendar_id is computed correctly.

[1]: https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L17

[2]- https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L29

**No Task ID**


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

Forward-Port-Of: odoo/odoo#244372
Forward-Port-Of: odoo/odoo#241638

Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t see what you were typing.

This happens because, in this case, the browser opens the virtual keyboard in overlay mode and does not resize the viewport. This seems to be a common behavior for inputs inside fixed or overlay-based layouts such as bottom sheets.

Strangely, when you clicked on an input that was already the active element, the keyboard still popped up, but the viewport was resized and the bottom sheet remained visible. In this situation, the browser treats the keyboard appearance as a viewport change and recomputes the layout to keep the active element visible (safe mode?).

To fix this inconsistency, we now explicitly control how the virtual keyboard affects the layout by forcing the bottom sheet to resize with the viewport. This is done by using `interactive-widget: resizes-content`, which ensures the viewport is resized when the keyboard appears and prevents the bottom sheet from being covered.

Note that we should probably apply this change on the web as well, but it seems that we currently don’t have any inputs inside bottom sheets there. Since this is a fix, we prefer to apply it only where it is necessary for now.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#interactive-widget

opw-5491343

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#244538

In the shop floor when you edit the quantity of components, all the components for the internal localization will appear instead of only the one from the source location

Steps to reproduce:
-------------------
- Active lot/serial number in settings
- Create component A tracked by lot, and add quantities in two location (WH/stock and WH/random)
- Create a product with a bom that use component A
- Create an operation for that bom
- Update the bom to consume the component during the operation
- Create a workorder for the product, confirm it and go to the shop floor
- Click on the operation
- Edit the quantity of components
-> all internal localisation appear (WH/{stock/random})

Observation:
-------------
The domain consider all localisation where the usage is internal: https://github.com/odoo/enterprise/blob/e99c20547528f6664d091cd230ce94cf76a08eb1/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L119

opw-5268989

Forward-Port-Of: odoo/enterprise#102902

When adding a product with never variant, their name and values are not translated in the language of the partner.

### Steps to reproduce:

* Activate the setting Variants and Variant Grid Entry.
* Create a product , add a translation for its name.
* Create a attribute  and a translation for its name, with variant creation set to never.
* Create values for the attribute and add translation for their name.
* Add the attribute and it's values to the product .
* Create a contact and change it's language to the language of the translation.
* Create a purchase order set the contact as the vendor
* Add the product, and set the grid number to 1
-> the attribute and attribute value is not translated.

### Observation:

When adding a product via the variant grid, the attribute and value names are added. For other attribute creation types, this information is retrieved directly from the product:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase/models/purchase_order_line.py#L283-L288
But in case of never attribute, the name it retrieved after and we don't set the context:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase_product_matrix/models/purchase.py#L173-L174
-> we retrieve the information but in the wrong language

opw-5396058

Forward-Port-Of: odoo/odoo#242692

Steps to reproduce
-----
- Enable routes
- Unarchive MTO
- Create a MTO product with a vendor
- Create a final product
- Create a MO for final product
- Confirm MO
- Open catalog
- Add 0.5 of the MTO product
- Open the linked purchase

> Quantity on the PO is 1

Cause
-----
The catalog creates a move with a default quantity of 1 when the product is clicked. Then, when the user updates the quantity in the catalog, it triggers a `write` of the `product_uom_qty` (which triggers a procurement).

Error comes from the code added in commit c0f00e4, which changed the `_run_procurement` of `stock.move` to avoid creating returns for done moves.

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L493-L497

In our case, all of the conditions are met:
- the quantity update is negative
- the move is MTO
- `move_orig_ids` is empty, so the `all()` is also true

This means the move gets skipped for procurement, although that was not the goal of the commit.

Even if we were to fix this last condition, there is also a problem with

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L505-L507

that was also affected by the mentioned commit. Since `move_orig_ids` is empty, `possible_reduceable_qty` is 0. And because `procurement_qty` is negative, taking the max of the 2 will always mean `procurement_qty` is 0.

This again does not match the goal of the original commit.

-----
Ticket:
opw-5440296

Forward-Port-Of: odoo/odoo#245865

### Issue:
Stripe payment is failing in some special currencies (e.g. ISK, UGX).

### Steps to reproduce:
1- Configure Stripe
2- Enable ISK currency
3- Create a SO with ISK currency and generate a payment.
4- Pay using Stripe.

The payment will fail due to the amount mismatch.

### Cause:
Commit https://github.com/odoo/odoo/commit/9493475273a40320228b92940be15ad8cb0643cb added support for special currency but did not adapt amount validation method in fw.

In stripe payload, we are using `const.CURRENCY_DECIMALS` as `arbitrary_decimal_number` to convert the amount to minor currency unit:
https://github.com/odoo/odoo/blob/6e2a29bbb23a8233132dc039d144d97be4feb3af/addons/payment_stripe/models/payment_transaction.py#L161-L166

However, we are not using the same constant in conversion back to major currency unit in `compare_notification_data`:
https://github.com/odoo/odoo/blob/6e2a29bbb23a8233132dc039d144d97be4feb3af/addons/payment_stripe/models/payment_transaction.py#L393-L395

opw-5871420

Forward-Port-Of: odoo/odoo#245911
Forward-Port-Of: odoo/odoo#245689

*= co, ec, kr, us, zm

Currently, the `Other Expense(expense_other)` account type, introduced in 
saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, 
even though it's correctly implemented in the standard reports.

**Steps to reproduce:**
- Install the `l10n_co_reports` and `accountant` modules.
- Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet.
- Ensure the `report` smart button is set to `Balance Sheet (CO)`.
- Equity > Previous Years Unallocated Earnings and click the `info icon`.
- Observe the formula of `balance_domain`.

**Observation:**
The formula does not include the `expense_other` account type.

**Root Cause:**
After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated 
Earnings balance domain only in the main `account_reports` module. The 
corresponding localization reports mentioned above were not updated 
accordingly, resulting in incomplete Balance Sheet formulas.

**Fix:**
This commit updates the Balance Sheet report and includes the `expense_other` 
account type in the Previous Years Unallocated Earnings balance domain, 
aligning them with the standard reports.

[1]:
https://github.com/odoo/enterprise/pull/101591

[2]:
https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205

opw-5491639

Forward-Port-Of: odoo/enterprise#105838
Forward-Port-Of: odoo/enterprise#105262

Steps to reproduce the bug

- Create a storable product P1:
  - Tracking: Serial Number
- Log in as Marc Demo
- Create a sales order with 1 unit of P1
- Validate the delivery using serial number SN1
- Log in as Mitchell Admin
- Go to Settings:
  - Manage Users
    - Mitchell Admin
      - Sales: User: own documents only
- Go to the Serial Numbers list view:
  - Try to open SN1

**Problem:**
An access error is triggered:

```
Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Mitchell Admin (id=2) doesn't have 'read' access to:
- Sales Order Line, S00025 - P1 (Deco Addict) (sale.order.line: 51)

Blame the following rules:
- Personal Order Lines
```

When clicking on SN1, the `stock.lot` form view.
it's contains the field "sale_order_count", which is a computed field that needs to access all `sale.order` records using the serial number in order to compute the count.

Since Mitchell Admin is restricted to his own sales orders only, an access error is raised during the computation.

There is also a many2many view widget that triggers an access errors. This widget can be removed since the smart button is now available. The widget has already been removed in v19.

**Solution:**
In this view, any stock user, admin or not, must be able to see how many sales orders use a given serial number, regardless of whether those sales orders belong to them or not.

opw-5400731

Forward-Port-Of: odoo/odoo#246009
Forward-Port-Of: odoo/odoo#244570

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs.

Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs.

[opw-5165200](https://www.odoo.com/odoo/project.task/5165200)

## Steps to reproduce:

[Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing)
1. Navigate to Apps and install l10n_mx_edi.
2. Switch to any of the Mexican companies that appear.
3. Navigate to Accounting > Configuration > Currencies.
4. Click into the USD currency.
5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field).
6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible.

[Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing)
1. Navigate to Accounting > Customers > Invoices.
2. Select New to create a new invoice.
3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES).
4. Add the 45 day Payment terms. This should change the payment policy to PPD.
5. Change the currency to USD.
6. Add the product FURN_8220 (or any with the unspsc_code_id set).
7. Set the unit price of the product to 58968.29.
8. Confirm the invoice.
9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again.
10. Select Register Payment, then Confirm Payment.
11. Select the Update Payments smart button.
12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.

Forward-Port-Of: odoo/enterprise#105102
Forward-Port-Of: odoo/enterprise#102557

Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being called as many times as there are open tabs. This used to be particularly annoying with the ringtone, which would play in unison. To solve this problem, we decided that only the "main tab" should be responsible for playing the ringtone. Since there can only be one main tab at a time, there can only be one ringtone at a time. Problem solved. This seemed to be an easy and effective solution.

However, we were informed that sometimes the call wouldn't ring at all 🤬
This called the reliability of the system into question. What would happen if:
- The main tab loses the WebSocket connection?
- The main tab is throttled?
- The main tab was never interacted with, preventing us from playing audio?
 - The notification arrives after the main tab is killed and before a new main tab is elected?

This commit attempts a new approach ⋆✴︎˚｡⋆
All tabs receiving incoming call notifications will now send a message to a central authority—The _SharedWorker_ 🙀—along with information about whether or not they can play audio. The SharedWorker then selects the first tab that can play audio and assigns it the task of playing the incoming ringtone.

This is expected to solve the problems mentioned above, as it guarantees that the "player tab" is a tab that:
- effectively received the incoming call notification
- is allowed to play audio

[Task-5411760](https://www.odoo.com/odoo/project.task/5411760)
Backport of https://github.com/odoo/enterprise/pull/104885

Forward-Port-Of: odoo/enterprise#105022

*= co, ec, kr, tw, zm

Currently, the `Other Expense(expense_other)` account type, introduced in 
saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, 
even though it's correctly implemented in the standard reports.

**Steps to reproduce:**
- Install the `l10n_co_reports` and `accountant` modules.
- Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet.
- Ensure the `report` smart button is set to `Balance Sheet (CO)`.
- Equity > Previous Years Unallocated Earnings and click the `info icon`.
- Observe the formula of `balance_domain`.

**Observation:**
The formula does not include the `expense_other` account type.

**Root Cause:**
After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated 
Earnings balance domain only in the main `account_reports` module. The 
corresponding localization reports mentioned above were not updated 
accordingly, resulting in incomplete Balance Sheet formulas.

**Fix:**
This commit updates the Balance Sheet report and includes the `expense_other` 
account type in the Previous Years Unallocated Earnings balance domain, 
aligning them with the standard reports.

[1]:
https://github.com/odoo/enterprise/pull/101591

[2]:
https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205

opw-5491639

Forward-Port-Of: odoo/enterprise#105262

Server actions that were standalone (not a child) and embedded on
a documents folder cannot be executed anymore when they are linked
to a parent action.
Before saas-18.3, the embedded child action would still be in the
documents' available_embedded_actions, and couldn't be removed,
such that a fix was necessary.

From saas-18.3 onwards, children embedded actions are no longer
visible.

As this precise case wasn't explicitly tested, we continue the
FW-port with the (adapted) test.
Furthermore, we add a garbage collection of the embedded actions
for children actions, as they cannot be executed anymore.

Initial FIX:

### ISSUE

It is possible that certain embedded actions visible in a folder
cannot be found or deleted through the interface, as they are not
displayed under the folder's server actions list when clicking on
the gear icon.

This is caused by overly broad filtering in
documents.document.get_documents_actions, which removes all child server
actions regardless of whether they were embedded in the folder.
So if a user creates two embedded actions inside a folder, then modifies
the underlying server actions so that one is the child of the other,
the embedded action associated with the child server action would
disappear from the folder's actions list but would still be embedded in
the folder making it impossible to remove it through the UI

This patch updates the logic so that only non-embedded child actions are
excluded. Embedded actions remain visible and manageable as expected.

opw-5213881

Forward-Port-Of: odoo/enterprise#105235
Forward-Port-Of: odoo/enterprise#100395

**Steps to reproduce:**
* Install the `stock_barcode`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#105535
Forward-Port-Of: odoo/enterprise#102714

Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t see what you were typing.

This happens because, in this case, the browser opens the virtual keyboard in overlay mode and does not resize the viewport. This seems to be a common behavior for inputs inside fixed or overlay-based layouts such as bottom sheets.

Strangely, when you clicked on an input that was already the active element, the keyboard still popped up, but the viewport was resized and the bottom sheet remained visible. In this situation, the browser treats the keyboard appearance as a viewport change and recomputes the layout to keep the active element visible (safe mode?).

To fix this inconsistency, we now explicitly control how the virtual keyboard affects the layout by forcing the bottom sheet to resize with the viewport. This is done by using `interactive-widget: resizes-content`, which ensures the viewport is resized when the keyboard appears and prevents the bottom sheet from being covered.

Note that we should probably apply this change on the web as well, but it seems that we currently don’t have any inputs inside bottom sheets there. Since this is a fix, we prefer to apply it only where it is necessary for now.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#interactive-widget

opw-5491343

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#244538

The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference.

It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`.

Before this commit:
- functionally: The obvious matching was denied and the accountant had to manually make the match.

- technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word.

After this commit:
- functionally: The obvious match is made.

- technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word.

task-id: None (The issue arose on odoo.com and was brought by APFA)

When adding a product with never variant, their name and values are not translated in the language of the partner.

### Steps to reproduce:

* Activate the setting Variants and Variant Grid Entry.
* Create a product , add a translation for its name.
* Create a attribute  and a translation for its name, with variant creation set to never.
* Create values for the attribute and add translation for their name.
* Add the attribute and it's values to the product .
* Create a contact and change it's language to the language of the translation.
* Create a purchase order set the contact as the vendor
* Add the product, and set the grid number to 1
-> the attribute and attribute value is not translated.

### Observation:

When adding a product via the variant grid, the attribute and value names are added. For other attribute creation types, this information is retrieved directly from the product:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase/models/purchase_order_line.py#L283-L288
But in case of never attribute, the name it retrieved after and we don't set the context:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase_product_matrix/models/purchase.py#L173-L174
-> we retrieve the information but in the wrong language

opw-5396058

Forward-Port-Of: odoo/odoo#242692

Steps to reproduce
-----
- Enable routes
- Unarchive MTO
- Create a MTO product with a vendor
- Create a final product
- Create a MO for final product
- Confirm MO
- Open catalog
- Add 0.5 of the MTO product
- Open the linked purchase

> Quantity on the PO is 1

Cause
-----
The catalog creates a move with a default quantity of 1 when the product is clicked. Then, when the user updates the quantity in the catalog, it triggers a `write` of the `product_uom_qty` (which triggers a procurement).

Error comes from the code added in commit c0f00e4, which changed the `_run_procurement` of `stock.move` to avoid creating returns for done moves.

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L493-L497

In our case, all of the conditions are met:
- the quantity update is negative
- the move is MTO
- `move_orig_ids` is empty, so the `all()` is also true

This means the move gets skipped for procurement, although that was not the goal of the commit.

Even if we were to fix this last condition, there is also a problem with

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L505-L507

that was also affected by the mentioned commit. Since `move_orig_ids` is empty, `possible_reduceable_qty` is 0. And because `procurement_qty` is negative, taking the max of the 2 will always mean `procurement_qty` is 0.

This again does not match the goal of the original commit.

-----
Ticket:
opw-5440296

Forward-Port-Of: odoo/odoo#245865

Issue:

When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.

Cause:

A previous change (#237235) added the `abs` function so the `TotalTaxesWithheld` would be always with positive value. But this also affects the calculation of taxes `TotalTaxOutputs` in some cases, such as if the invoice line has negative values.

Steps to reproduce:

- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous

A correct invoice should be for example:

```
Product        Price       Taxes       Amount
---------------------------------------------
PRODUCT-A       1000    21%VAT 15%WHI    1000
Discount        -100    21%VAT 15%WHI    -100
---------------------------------------------
                       Untaxed amount     900
                      Withholding 15%    -135
                              VAT 21%     189
                      -----------------------
                                 TOTAL    954
```

This PR replaces #240808 

---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#244428

Problem:
- In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used for the record that is already confirmed) and notifications go to the sales partner instead of the actual assistant.

Current behaviour:
- Confirmed orders automatically confirm attendees, reducing the value of the wizard step and sending emails to the wrong recipient.

Expected behaviour:
- Paid attendee registrations created from Sales should remain in “draft” until attendee details are provided.

Solution:
- Do not set ‘state=“open”’ for payment records created from a sale involving
  the data wizard for records. Ensure they remain in “draft”.
- Confirm registrations once attendee details are present.

Advantages:
- Restores the usefulness of the attendee editor: confirmation occurs after data entry, so notifications are directed to the attendee, not just the sales partner.
- Meets functional expectations for administrative control and proper recipient targeting.

Tests to reproduce the error:
- Create quote with payment entry
- Confirm SO
- Enter attendee details and confirm
- Registrations change to ‘open’ and a confirmation email is sent to the order partner and not to the registered attendee.

@Tecnativa TT58160

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

Forward-Port-Of: odoo/odoo#230500

**Steps to reproduce:**
* Install the `stock_barcode`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#102714

**Issue**
When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities.

**Steps to reproduce**
- Create a product with a BOM using a component with qty 6.
- Create an MO producing qty 1.
- Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed).
- Click “+1”.
- Edit the component qty from 6 to 3.
- Exit the operation.
- Re-enter the operation.
-> The component shows 3/3 instead of 3/3 and 0/3.

**Cause**
On exit, `_onExit`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489
calls `post_barcode_process()`, which triggers `split_uncompleted_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16
correctly creating a `stock.move.line` with qty 3.

However, `_truncate_overreserved_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40
then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49

This happens because the newly created move line is initialized with `reserved_uom_qty = 0`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256
leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6.

opw-5166763

Forward-Port-Of: odoo/enterprise#100314

First PR of multiple to rework the map UI / UX.

In this first PR we focus on the change from numbering the map marker 
according to the list item number to numbering the map marker by the 
number of records with the same address (previously done with badges)

Furthermore, now that the list between the task and the pin on the map
is less evident (no more numbering to link the two), we add some hover
effects: on the map marker hover we highlight the list item, and on the
list item hover, we make the map marker bigger in the map.

List of all changes:

- Side panel - Removed List title
- Side panel - Replaced the drag handle from the far right to far left of the task.
- Side panel - Removed numbering of tasks. 
- Side panel - Move and restyled "View in Google Maps" button to control panel.
- Side panel - On hover of the list item make the related map marker bigger.
- Side panel - Add some coloring change to the handle on the handle hover.
(This was done in an accounting module, and I find it a good addition to 
the mouse pointer changing on handle hover)
- Map - On hover of the marker, make the marker bigger and highlight the
related list item.
- Map - Remove badges from map marker with multiple records address.
- Map - Change numbering from representing the list item number to the
number of records with the same marker. 
- Map - On the mobile view, no more toggling of tasks.

--> We do not yet address any grouping logic.

task#5259181
documentation PR: odoo/documentation#16092

Following PR: odoo/enterprise#104812

Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method.

Steps to replicate:
- Install `l10n_mx_edi` and `accountant` with demo and switch to `ZAPATERIA URTADO ÑERI` (Mexican company).
- Go to `Accounting > Configuration > Payment Way Codes (MX)`.
- Open `Efectivo` and change its code to `02`.
- Create a new Invoice, select `Efectivo` in the Payment Way.
- Add a customer and a move line, then confirm the invoice and send it (make sure CFDI is checked).

Error:
```
  File '/home/odoo/src/enterprise/19.0/l10n_mx_edi/models/account_move.py', line 424, in _l10n_mx_edi_get_extra_invoice_report_values
    cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
  File '/home/odoo/src/odoo/19.0/odoo/orm/fields.py', line 1659, in __get__
    record.ensure_one()
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(1, 22)
```

Cause:
- Issue originated through this [PR] that gave access to write on the model.
- As the user made the codes of two payment methods same, the [search] returned two records and while accessing `payment_method.name` on two records it results into this error.

Solution:
- Made the fields read-only to prevent users from changing the payment method codes established by the Mexican government.
- Added limit to the search query to prevent multiple records (Just for safety).
- Removed unlink rights on the `l10n_mx_edi.payment.method` model.
- Added a SQL constraint to allow only unique values for the code.
- Removed the form view.
- Added the field `active` to the list view and made it editable.

PR for stable(18.0): https://github.com/odoo/enterprise/pull/103944

[PR]: https://github.com/odoo/enterprise/pull/38046

[search]: https://github.com/odoo/enterprise/blob/18117c6a9fbf270ace1c551616828a85713d5225/l10n_mx_edi/models/account_move.py#L423

sentry-7171030995

In the shop floor when you edit the quantity of components, all the components for the internal localization will appear instead of only the one from the source location

Steps to reproduce:
-------------------
- Active lot/serial number in settings
- Create component A tracked by lot, and add quantities in two location (WH/stock and WH/random)
- Create a product with a bom that use component A
- Create an operation for that bom
- Update the bom to consume the component during the operation
- Create a workorder for the product, confirm it and go to the shop floor
- Click on the operation
- Edit the quantity of components
-> all internal localisation appear (WH/{stock/random})

Observation:
-------------
The domain consider all localisation where the usage is internal: https://github.com/odoo/enterprise/blob/e99c20547528f6664d091cd230ce94cf76a08eb1/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L119

opw-5268989

Forward-Port-Of: odoo/enterprise#102902

This commit improves the handling of a document's discoverability setting (`is_access_via_link_hidden`) when it is moved between folders.

Previously, when a document was moved, it would inherit the discoverability setting from the destination folder. This could lead to unintended changes in a document's visibility. For example, a publicly discoverable document could become private (requiring a direct link) simply by being reorganized into a different folder.

This behavior was inconsistent with a previous improvement that prevented discoverability from propagating downwards from a parent folder to its children. See PR-93697.

With this change, a document's discoverability is now treated as an intrinsic property that is fully preserved when the document is moved. It is no longer affected by the settings of its destination folder.

To ensure clarity for the user, the move confirmation dialog has been updated to reflect this new logic. It now correctly informs the user that the document's original discoverability setting will be maintained.

Task-5159832

*= co, ec, kr, us, tw, zm

Currently, the `Other Expense(expense_other)` account type, introduced in 
saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, 
even though it's correctly implemented in the standard reports.

**Steps to reproduce:**
- Install the `l10n_co_reports` and `accountant` modules.
- Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet.
- Ensure the `report` smart button is set to `Balance Sheet (CO)`.
- Equity > Previous Years Unallocated Earnings and click the `info icon`.
- Observe the formula of `balance_domain`.

**Observation:**
The formula does not include the `expense_other` account type.

**Root Cause:**
After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated 
Earnings balance domain only in the main `account_reports` module. The 
corresponding localization reports mentioned above were not updated 
accordingly, resulting in incomplete Balance Sheet formulas.

**Fix:**
This commit updates the Balance Sheet report and includes the `expense_other` 
account type in the Previous Years Unallocated Earnings balance domain, 
aligning them with the standard reports.

[1]:
https://github.com/odoo/enterprise/pull/101591

[2]:
https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205

opw-5491639

Forward-Port-Of: odoo/enterprise#105262

What:
Previously, actions like "Create Vendor Bill" were only embedded in the
main "Finance" folder. Now, these actions are also embedded directly into
the specific subfolders for each journal type (e.g., "Purchase", "Sales").
All relevant actions are also kept in the parent "Finance" for general
accessibility. The purchase actions are also added to the "Inbox" folder.

Why:
The previous behavior was inefficient. A user uploading a vendor bill to
the "Purchase" folder would not see the "Create Vendor Bill" action. He
would only see it when he is in the parent "Finance" folder. By embedding
it by default this streamlines the process by ensuring the necessary tools
are available exactly where the user is working.

How:
The logic is implemented within the _documents_configure_sync method of
the account.journal model. This is the ideal location because it
handles the complete setup of a journal for the Documents app. This ensures
that actions are embedded correctly both during module installation and
dynamically whenever a new journal is created by a user.

Notes:
- Tests were rewritten to check these embeddings on install. And were
refactored to be more maintainable and cover bank statements better.
- The test for importing bank statements had to be moved to a separate
testing module, as it needs the `account_bank_statement_extract` module,
which is not in the dependencies of `account_move`.
- The tests for bank statement processing errors was improved to match
the tests in later versions

Task-5410752
Related Task-5075610

Registering for an event while the mail scheduler cron was running could lead to a PostgreSQL serialization failure, leading to a 500 error and the failure of the registration.

### Reproduction Steps

1. Configure an Event with a "Mail Scheduler" set to trigger "After each registration" with an interval of "Immediately".
2. Ensure the "Event: Mail Scheduler" cron job is active and running.
3. As a public user or portal user, attempting to register for this event will intermittently fail with an HTTP 500 error.
4. The server logs will show `psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update`, followed by `psycopg2.errors.InFailedSqlTransaction`.
5. The registration is not created.

### Cause

When a user registers for an event, the system immediately attempts to process any "on-registration" emails. The method used (`_execute_attendee_based`) forces a database `commit()`.

When this `commit()` is executed, the Postgres database attempts to finalize the user's transaction. However, if the concurrent background cron job has modified the same event/mail records while the user's request was processing, Postgres detects a serialization conflict.

Consequently, the commit itself fails and raises `SerializationFailure`. Because the commit failed, the user's transaction is rolled back, and the registration record is never persisted to the database (explaining the missing attendees).

Critically, the exception handling logic in `_update_mail_schedulers` catches this `SerializationFailure` (preventing odoo from retrying the transaction) but then attempts to perform further database operations (to log the error). Since the transaction is already in an aborted state due to the failed commit, this triggers a secondary `InFailedSqlTransaction` error. This secondary error is not recognized as a concurrency error by Odoo's automatic retry mechanism (`odoo.service.model.retrying`), resulting in a hard crash instead of a retry.

### Fix

The logic now checks the execution context using `event_mail_registration_ids`. If triggered by a user registration (indicated by the presence of specific registration IDs in the context), the explicit `commit()` is skipped.

opw-5355116

## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).

## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
    - *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
    - *Wages and salaries*: **649 is not mentioned**
    - *Social security charges*: **649 is not mentioned**

## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.

opw-5724559

Forward-Port-Of: odoo/enterprise#105474

**Behaviour:**
When accessing the Planning by Production/Workcenter views from the menu, a server action checks if the work order dependencies setting is enabled, and if yes, it will change the ref of the default gantt view to another view which handles dependencies. However, when reloading the page, the server action is not accessed anymore which will result in the default view being loaded and the dependencies not being represented.

This behaviour is fixed starting from 18.2 with this commit ( https://github.com/odoo/odoo/commit/b663a6e3dbda6eda84e4a6b051acfc8511476cd3 ) that ensures that if a page is reloaded the current action's state is restored as it was.

Applying this commit to previous versions would not comply with stable policy, the current solution is to override the get_views method to make sure the presence of the setting is checked and the correct view is applied whenever that page is loaded.

**Steps to reproduce:**
- Check Work Orders->Work Order Dependencies in the Manufacturing settings
- Create a Product
- Create a Bill of materials with two components
- Check Operation Dependencies in the Miscellaneous tab
- Create two operations, and make one of them blocked by the other
- Create a Manufacturing order for the product then click confirm then Plan
- In the Planning dropdown menu, select Planning by Production (workcenter works aswell)
- You will see the two operations with an arrow linking them.
- Refresh the page
- The arrow will have disapeared

opw-5477803

## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).

## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
    - *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
    - *Wages and salaries*: **649 is not mentioned**
    - *Social security charges*: **649 is not mentioned**

## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.

opw-5724559

**Issue**
In subcontracting, if a BOM is modified after the creation of a PO, then modifying the move quantity of the associated receipt can lead to inconsistency between move and move line quantities.

**Steps to reproduce**
- Create a subcontracting BOM of a final product using 1 component product
- Create a PO of the final product for a quantity of 10 and confirm it
- Modify the BOM to use 2 component products instead
- Go to the receipt of the PO and modify the quantity to 2 and validate it
- Click on the move line of the receipt -> The displayed quantity is 10 instead of 2

**Cause**
Setting the quantity triggers this line:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L78-L78 
which calls:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L107

Since the BOM has been modified, a `consumption_issues` is detected and `_update_finished_move()` won't be called:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L86-L89

And since the returned action is not used when calling `subcontracting_record_component`, `_update_finished_move()` won't be called later neither, which is the method responsible for updating the move line quantities:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L142-L146

**Solution**
Since the consumption issue actions are ignored in this case, just skipped it and avoid inconsistencies.

opw-5493577

### Issue:
Attendances overlapping on two days are ignored for hourly accrual plans based on attendances.

### Steps to reproduce:
- Install 'hr_holidays_attendance'
- In Time Off > Configuration > Accrual Plan, create a new plan
	- Based on worked time
	- Hourly rule
	- Attendances as Source
- In Management > Allocations, create an allocation for an employee using the new accrual plan
- Create an Attendance for this employee in the period of the Accrual Plan
	- Check-in at 22pm for example
	- Check-out at 7am
- Run the cron "Accrual Time Off: Updates the number of time off"
- The Allocation ignores the worked time from the attendance

### Cause:
`_get_accrual_plan_level_work_entry_prorata()` is called on each day of the accrual period. So `start_dt` is `datetime.datetime(2026, 1, 2, 0, 0)` and `end_dt` is `datetime.datetime(2026, 1, 3, 0, 0)` for example. This means that the search will always excludes attendances overlapping on two days.

https://github.com/odoo/odoo/blob/26f3026ed45cc409cd7f67fa219d44f1adbac9b7/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L79-L83

### Solution:
To count the attendances on several days, we need to split these attendances by day because `_get_accrual_plan_level_work_entry_prorata()` is only called with an interval of one day from midnight to midnight.

First we get all attendances overlapping with the day by changing the domain in the search.

Then we could simply take the difference between `max(attendance.check_in, start_dt)` and `min(attendance.check_out, end_dt)` but we also need to remove the lunch breaks (they were not counted in `attendance.worked_hours`). This would mean duplicating the code present in `_compute_worked_hours()`. To avoid this we create a new method for `hr.attendance` named `_get_worked_hours_in_range()`. That returns the number of hours worked due to this attendance in a given time frame. This new method can be used in both cases to get the needed value.

opw-5172669