Before this commit:
Using the CLI, there is no practical way to update any modules with an updated version.

Running:
`$ odoo-bin module upgrade base --outdated`
would not work as intended as it would check version change only on the `base` module. Even if it worked, this would update every module. This is not the point here as it could cause side effects if not used properly

After this commit:
Enhanced module update logic to support updating all installed modules when `all` is passed in the argument. Running:
`$ odoo-bin module upgrade all --outdated`
will update all modules for which the version has been updated

Note: `all` keyword as been used to be coherent with `--update all` CLI command, see: https://www.odoo.com/documentation/19.0/developer/reference/cli.html#cmdoption-odoo-bin-u

Documentation PR: odoo/documentation#15513

Extension from:
https://github.com/odoo/odoo/pull/202571
Feature proposed on:
https://github.com/odoo/odoo/pull/202571#discussion_r2128993414

Task [link](https://www.odoo.com/odoo/project.task/4585261)
task-4585261

Forward-Port-Of: odoo/odoo#237780

Currently when a user creates a new template from a marketing campaign, they can’t edit the `email_from` and `reply_to` fields, even though these should be editable in the template.

**Steps to replicate:**
* Install `marketing_automation`
* marketing automation > Create a New campaign > Add a new activity
* Mail template > Create a new template > Settings

**Observed Behavior:**
The fields `Send From` and `Reply To` are not editable which should be editable.

**Root cause:**
* After commit [1], the form view `mailing_mailing_view_form_marketing_activity` [2] was removed, so `email_from` and `reply_to` now come from the view [3]. Because that view inherits the `mass-mailing form`, its `readonly` rules apply (see [4]), and with `default_state` set to “done” (see [5]), those fields become `readonly` when creating a new mail template.

**Solution:**
Modify the readonly conditions to match how they were handled in earlier versions (see [6]).


**Before:**
<img width="1182" height="591" alt="image" src="https://github.com/user-attachments/assets/72006a7f-1ee5-40dd-8899-4eb932f503b7" />
**After:**
<img width="1182" height="591" alt="image" src="https://github.com/user-attachments/assets/d5d6bdf2-1fb6-4e7b-9527-412c44986050" />

[1]:
https://github.com/odoo/enterprise/commit/a469218b32943ddaa83271565e73311cfd188f84 
[2]:
https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/mailing_mailing_views.xml#L75-L143 
[3]:
https://github.com/odoo/enterprise/blob/307b23b0f6b377c43463a04aabf0b2f03c256072/marketing_automation/views/mailing_mailing_views.xml#L107 
[4]:
https://github.com/odoo/odoo/blob/9e04aadb83d482d05fc2fa66fa3c3bebb6ac1528/addons/mass_mailing/views/mailing_mailing_views.xml#L328-L337 
[5]:
https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/marketing_activity_views.xml#L23 
[6]:
https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/mailing_mailing_views.xml#L96

opw-5401422,5449345,5369836

Forward-Port-Of: odoo/enterprise#101807

This happens only on Chrome, when switching between two identical t-if/else
structures.

In Odoo's t-if/t-else structures, Chromium may fail to properly update
the selection when switching between two structurally identical elements
via the group switcher.

This happens because Chrome's implementation of the [Selection API](https://www.w3.org/TR/selection-api/#selectionchange-event)
contains an optimization that suppresses the 'selectionchange' event if the
new Range has the same logical coordinates (Node type and Offset) as the
previous one, even if the underlying DOM node reference has changed.

This can break editor commands such as `/table` or `/field` like in the
following steps:

Steps:
- Install `sale_management` and `web_studio`
- Open report editor on PDF Quote
- Add a new column to the left in the table
- Click on the table body
- Select `t-else` in the group switcher
- Click again at the same place
- (Here the selection is not correctly set by chromium)
- Try to use `/field` to add a field
- It will not work as field selector doesn't have the right selection
You can use this [video](https://drive.google.com/file/d/1ua7nlla7km1_l-wqgL8zeHaM-tFLA9jJ/view) to reproduce it easily 
or you reproduce it [here](https://stackblitz.com/edit/javascript-v65edaq5?file=index.html,index.js)
If you click after the “1” and then after the “2,” you will see that
Chromium does not fire the selectionchange event, whereas Firefox does.

This commit fixes this by adding a "removeAllRanges()" to force Chrome to
"forget" the old range. This ensures that the next selection is correctly
treated.

opw-5219989

Forward-Port-Of: odoo/odoo#244743

## Short functional explanation of the error
When creating a variant, we can click on it and it will show the field "packagings" on the product view, which is editable. However, packagings are managed on the product template view, where the field is also editable. This creates confusion for the users, as it doesn't align with the sentence on the view
"All general settings about this product are managed on the
product template".

## Reproduction Steps
1. Create a product. In the Attributes & Variants tab, create
a variant.
2. The smart button Variants should appear. Click on it.
3. In the list view, click on the variant you just created.
4. Under Sales, modify the Packagings field.
5. Click on 'the product template' blue text. The product
template popup appears.
6. Go to Sales tab and modify the Packagings Field.

### Expected behavior
The packagings should be editable only on the product template
view.

### Unexpected behavior
The packagings is also editable on the product.product view.

## Origin of the issue
Missing a readonly="1" in the xml of product.product view
__
opw-5065419

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

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

Forward-Port-Of: odoo/enterprise#103316

When trying to compute the document count
during the upgrade, we encountered a ValueError
because multiple records were found for a partner. The system expected a singleton

```
File "/home/odoo/src/enterprise/19.0/documents_hr/models/hr_employee.py", line 34, in _compute_document_count
    ('partner_id', '=', self.work_contact_id.id)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields_misc.py", line 112, in __get__
    raise ValueError("Expected singleton: %s" % record)
 ValueError: Expected singleton: res.partner(11393, 11612, 13026, 13085, 13066, 11674, 13007, 11240, 11420, 13086, 2687, 8998, 10309, 8195, 8468, 6439, 8151, 6580, 7928, 10301, 11058, 10515, 5274, 9243, 8141, 8435, 8889, 7761, 7733, 8443, 8545, 9252, 8457, 9980, 5495, 11424, 6458, 10558, 11070, 8924, 11731, 11528, 11615, 11766, 13021, 13080, 11758, 11742, 9306, 8826, 11004, 9393, 8879, 9317, 11652, 13075, 11744, 11160, 11644, 11763, 11416, 11618, 11732, 7931, 3846, 8442, 10299, 7916, 8429, 8057, 11061, 9342, 6435, 6553, 6512)
```

Forward-Port-Of: odoo/enterprise#101902

_
## Short functional explanation of the error
When generating a payslip from a payrun for an employee on the swiss localization, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - <name of employee> - <time period of the slip>"

## Reproduction Steps
1. Install the app l10n_ch_hr_payroll.
2. Make sure you use a Swiss company.
3. Go to Payroll and click on the Payslips tab > payslips.
4. Click on Pay Run. Select Switzerland: ELM salaries and click Continue.
5. Select an employee for which you'd like to generate the payslip.
6. Click on the employee row in the list view.
7. Click Compute sheet > Print.

## Expected behavior
A PDF with name "Salary Slip - <employee name> - <time period>" is generated.

## Unexpected Behavior
A PDF with name "new Payslip" is generated.

## Origin of the issue
When printing the slip with this flow, we don't call the method
```_compute_name()``` used to compute the name of the current slip.
Therefore, it stays at 'New Slip', which is the default name.
Henceforth, we have to call this method manually when printing the
slip.
_
opw-5253811

Forward-Port-Of: odoo/enterprise#103471

To reproduce:
=============
1. Create an new Overtime Ruleset using these options:
- The rule is based on: Timing
- With tolerance in favor of the employer of: 00:00
- If the employer works: Outside of a specific schedule
- Schedule: 40/hour work week
- Pay extra hours: with rate of 100%
- Work entry type to use: Overtime Hours
- Give back as time off
2. Create an employee or edit an existing employee to use the overtime ruleset in the settings of the form view of the employee.
3. Navigate to attendance and create a new entry for that employee.
4. Make clock in time and clock out time run through a Friday. For example:
Clock in: 12/22/2025 12:00:00 AM
Clock out: 12/26/2025 6:30:00 AM
5. Then edit the entry to run through the Saturday or Sunday. For example:
Clock out: 12/27/2025 6:30:00 AM
6. Navigate to Work Entries and navigate to the month or week that that entry was made at.
7. There should be a traceback error for more than one overtime line related to that specific entry.

Problem:
========
When allocating multiple overtime lines to consecutive time periods, the
`_set_real_overtime_intervals` method was merging them into single intervals
with recordsets of overtime lines (e.g., hr.attendance.overtime.line(102, 106, 103, 104))
instead of keeping each overtime line in its own separate interval. This happened
because the allocation logic incorrectly calculated the position within intervals
and subtracted the wrong duration from remaining overtime, causing the `|=` merge
operator to combine adjacent allocations into recordsets.

Solution:
=========
Refactored the overtime allocation loop to maintain singletons

opw-[5468598](https://www.odoo.com/web#id=5468598&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#105555

When pos_event was added, a difference in behavior with the existing registration flow in website_event was missed. When answering an 'identification question' (name, email, phone, company_type) with the 'once per order' enabled, the values should be used and propagated directly on the created event.registration records, with precedence over other answers given to individual questions (not once per order)

STEPS
=====

1. Create a new event with name, email questions, once per order ticked.
2. Go to POS (reload data if needed)
3. Register and answer both questions
4. Continue the pos flow until both registrations are created
5. Go to backend > your event > registrations
6. You can see that even if the answers are propagated in the o2m field registration_answer_ids, which is expected, the attendee's name and attendee's email fields are empty. They should contain the values of step 3.

FIX
===

Align the website_event flow and precedence of OPO questions over
individual answers in pos_event. Now, the first non-null answer of an OPO
question will be used for each of the question_type values listed above,
if any, over answers to individual questions.

Also align the fact that after OPO answers, precedence should be given
to the first non-null answer to a given question type for identification
questions, and not the last as it is currently.

Task-4919080

Forward-Port-Of: odoo/odoo#231502

Issue Before This Commit:
================================
Previously, the delivery carrier was only propagated between pickings when it
was set from the sale order. If the carrier was manually set on a picking
(e.g., during the packing step in a multi-step delivery flow), it was not
propagated to the consequent pickings, even when the stock rules had
`Propagation of carrier` enabled.

Steps to reproduce:
================================
1. Activate Multi-Step Routes and Delivery Methods.
2. Configure a 3-step delivery route in the warehouse and enable Propagate
   Carrier on all rules.
3. Create a sale order with a product but without setting a delivery carrier.
4. Confirm the sale order to generate picking.
5. On the first picking (i.e., pick), manually set a delivery carrier
   (e.g., Local Delivery) and validate.
6. On the next transfer (i.e., pack), observe that the delivery carrier is not
   propagated.

After this commit:
================================
The delivery carrier set on any picking is propagated to subsequent transfers
when the corresponding stock rule has `Propagation of carrier` enabled and no
carrier is already configured on the next picking.

This ensures consistent carrier propagation across all routing configurations
(all pull rules, all push rules, and mixed push/pull flows), even when the
carrier is configured at the picking level rather than on the sale order.
This behavior is required because, in many business scenarios, carrier selection
is managed by the logistics team rather than the sales team.

task-4454313

Forward-Port-Of: odoo/odoo#243597
Forward-Port-Of: odoo/odoo#202700

__Steps to reproduce on runbot:__

1. Login with Mitchell Admin
2. Remove Marc Demo from the `sales_team.group_sale_salesman` access
group (User: Own Documents Only)
3. Login with Marc Demo
4. Open the Website app and go to Reporting > eCommerce
=> You are redirected to the website in frontend mode

__Reason:__

Clicking on the eCommerce reporting menu calls
`action_dashboard_redirect`, which redirects to the website if the user
is not in `base.group_system`, `website.group_website_designer`, or
`sales_team.group_sale_salesman`. Since Marc Demo is not in any of these
groups, he is redirected to the website without any message, which is
not very user friendly.

__Fix:__

- Add the groups to the menu to prevent showing it if the user does not
have access to it anyway.
- Raise an access error instead of redirecting to the website to make it
clear to the user that they cannot open the dashboard even if they could
see it.

This also fixes [`TestMenusDemo`] by preventing this menu from being
tested with the demo user in case he doesn't have access to it.

[`TestMenusDemo`]: https://github.com/odoo/odoo/blob/736b71202db840ba6a7ed7e7f014b5b7c493d589/addons/web/tests/test_click_everywhere.py#L41C9-L41C41

runbot-234747

Forward-Port-Of: odoo/odoo#244963

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

Forward-Port-Of: odoo/enterprise#103316

Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input.

**Steps to Reproduce:**
1. Install the `hr_payroll_sale_commission` module.
2. Create a user and link to an employee. Set a contract for the employee.
3. Create two commission plans for the same user:
   - Use the same Payslip Input in both plans.
   - Set the Target Frequency to "Monthly" for both.
4. Generate a payslip for the employee.

Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing)

**Error:**
`ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)`

**Cause:**
When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion.

**Fix:**
This commit ensures the currency conversion is applied per commission and prevents the singleton error.

sentry-7187854690

Forward-Port-Of: odoo/enterprise#104464

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

Forward-Port-Of: odoo/enterprise#103316

When pos_event was added, a difference in behavior with the existing registration flow in website_event was missed. When answering an 'identification question' (name, email, phone, company_type) with the 'once per order' enabled, the values should be used and propagated directly on the created event.registration records, with precedence over other answers given to individual questions (not once per order)

STEPS
=====

1. Create a new event with name, email questions, once per order ticked.
2. Go to POS (reload data if needed)
3. Register and answer both questions
4. Continue the pos flow until both registrations are created
5. Go to backend > your event > registrations
6. You can see that even if the answers are propagated in the o2m field registration_answer_ids, which is expected, the attendee's name and attendee's email fields are empty. They should contain the values of step 3.

FIX
===

Align the website_event flow and precedence of OPO questions over
individual answers in pos_event. Now, the first non-null answer of an OPO
question will be used for each of the question_type values listed above,
if any, over answers to individual questions.

Also align the fact that after OPO answers, precedence should be given
to the first non-null answer to a given question type for identification
questions, and not the last as it is currently.

Task-4919080

Forward-Port-Of: odoo/odoo#231502

Link to Avalara (Avatax) documentation:
https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/

Expected Behaviour:
The itemCode sent to the AvaTax API should be 50 characters or fewer
to comply with Avalara's field length constraints.

Actual Behaviour before the Fix:
When an itemCode exceeded 50 characters, the system attempted to send
the request as-is. This resulted in the AvaTax API returning an error,
causing the transaction or tax calculation to fail.

Behaviour with the Fix:
The system now ensures that the itemCode adheres to the 50-character
limit before the API call is made, by trancating the code to the
first 50 characters if it exceeds 50 characters. This prevents API
rejection and ensures successful tax processing for items with
long identifiers.

Steps to reproduce:
1. Create or select a product/item with a reference (or barcode if
   using UPC) longer than 50 characters.
2. Trigger an action that calculates tax via the AvaTax
   integration (e.g., creating an invoice or updating a line item).
3. Observe the API response.

- Before fix: API returns a validation error regarding the
  itemCode length.
- After fix: Request is successful as the itemCode is
  properly handled/validated.

opw-5406451

Forward-Port-Of: odoo/enterprise#105017

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

Forward-Port-Of: odoo/enterprise#103316

Link to Avalara (Avatax) documentation:
https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/

Expected Behaviour:
The itemCode sent to the AvaTax API should be 50 characters or fewer
to comply with Avalara's field length constraints.

Actual Behaviour before the Fix:
When an itemCode exceeded 50 characters, the system attempted to send
the request as-is. This resulted in the AvaTax API returning an error,
causing the transaction or tax calculation to fail.

Behaviour with the Fix:
The system now ensures that the itemCode adheres to the 50-character
limit before the API call is made, by trancating the code to the
first 50 characters if it exceeds 50 characters. This prevents API
rejection and ensures successful tax processing for items with
long identifiers.

Steps to reproduce:
1. Create or select a product/item with a reference (or barcode if
   using UPC) longer than 50 characters.
2. Trigger an action that calculates tax via the AvaTax
   integration (e.g., creating an invoice or updating a line item).
3. Observe the API response.

- Before fix: API returns a validation error regarding the
  itemCode length.
- After fix: Request is successful as the itemCode is
  properly handled/validated.

opw-5406451

Forward-Port-Of: odoo/enterprise#105017

Currently when a user creates a new template from a marketing campaign, they can’t edit the `email_from` and `reply_to` fields, even though these should be editable in the template.

**Steps to replicate:**
* Install `marketing_automation`
* marketing automation > Create a New campaign > Add a new activity
* Mail template > Create a new template > Settings

**Observed Behavior:**
The fields `Send From` and `Reply To` are not editable which should be editable.

**Root cause:**
* After commit [1], the form view `mailing_mailing_view_form_marketing_activity` [2] was removed, so `email_from` and `reply_to` now come from the view [3]. Because that view inherits the `mass-mailing form`, its `readonly` rules apply (see [4]), and with `default_state` set to “done” (see [5]), those fields become `readonly` when creating a new mail template.

**Solution:**
Modify the readonly conditions to match how they were handled in earlier versions (see [6]).


**Before:**
<img width="1182" height="591" alt="image" src="https://github.com/user-attachments/assets/72006a7f-1ee5-40dd-8899-4eb932f503b7" />
**After:**
<img width="1182" height="591" alt="image" src="https://github.com/user-attachments/assets/d5d6bdf2-1fb6-4e7b-9527-412c44986050" />

[1]:
https://github.com/odoo/enterprise/commit/a469218b32943ddaa83271565e73311cfd188f84 
[2]:
https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/mailing_mailing_views.xml#L75-L143 
[3]:
https://github.com/odoo/enterprise/blob/307b23b0f6b377c43463a04aabf0b2f03c256072/marketing_automation/views/mailing_mailing_views.xml#L107 
[4]:
https://github.com/odoo/odoo/blob/9e04aadb83d482d05fc2fa66fa3c3bebb6ac1528/addons/mass_mailing/views/mailing_mailing_views.xml#L328-L337 
[5]:
https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/marketing_activity_views.xml#L23 
[6]:
https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/mailing_mailing_views.xml#L96

opw-5401422,5449345,5369836

Forward-Port-Of: odoo/enterprise#101807

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

Forward-Port-Of: odoo/enterprise#103316

### Steps to reproduce:

- In the settings enable: Multi-Steps route
- Create a product tracked by SN
- In the barcode app > Operations > Internal transfers > New
- Scan you tracked product
- Click on Validate > Invalid operation
- Scan a Serial number
#### > You can not click on validate anymore

### Cause of the issue:

The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since  orm call returns an error the the call the validate method is interupted at this orm call and the line
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133

### Fix:

We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 :
https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135
we have the guarantee that the records will not be validated twice.

opw-5388297

Forward-Port-Of: odoo/enterprise#104963
Forward-Port-Of: odoo/enterprise#103835

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

Forward-Port-Of: odoo/enterprise#103316

**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Journal Entry** in mobile view.
* Add a **Journal Item**, opening it in a form dialog.
* Select a tax in the **Taxes Applied** field.
* Click on the **Save and close** button.

**Observed behavior:**
* The web client crashes with `TypeError: Cannot read properties of undefined (reading 'resId')`.

**Cause:**
* The `autosave_many2many_tags` widget triggers `model.root.save()` immediately when a tag is selected.
* When executing this save from within a transient dialog (common in mobile views), the client fails to correctly handle the record reload/synchronization leading to a crash when accessing `resId`.

**Fix:**
* Replace the autosave widget with the standard `many2many_tags` widget for **Journal Items** for form.
* Tax changes are now kept locally in the dialog and saved only when the user explicitly saves and closes it.

**Note:**
* The crash happens when `autosave_many2many_tags` calls
  `model.root.save()` on a **new** `account.move` from within a dialog.
* In QUnit tests, the mock server (`mockWebSave`) [1](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L627). which creates records [2.](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L1936)
  in-memory and does not trigger form reloads or component destruction.
* As a result, the crash cannot be reproduced in tests.




opw-5497342

Forward-Port-Of: odoo/odoo#246084

_
## Short functional explanation of the error
Let's say a customer has made 2 sales order of 2 different serives: one service is prepaid, the other one is billed based on timesheets. When we create a ticket related to this customer in the helpdesk app, the ticket automatically fills the Sales Order Item field with the prepaid service. If we remove this Sales Order Item, create a timesheet in which we set the Sales Order Item to be the timesheeted service, and press save, the Sales Order Item of the timesheet will disappear.

## Reproduction Steps
1. Create 2 products: one service based on timesheets and one service prepaid. Make sure that they create an empty project on order.
2. Create 2 quotations for the same partner: one that contains the first product you created and a second one containing the second product. Click on confirm.
3. Go to Helpdesk > Configuration > Helpdesk teams. Click on one team and under Track and Bill time, enable both Timesheets and Time Billing.
4. Create a Helpdesk ticket for the team you setup. Under customer, enter the name of the partner in the quotations.
5. Click on the ticket. The quotation related to the prepaid service should appear as the field Sales Order item on the ticket. Remove it, click on the Timesheet tab, and add a line in which, for the Sales Order Item field of the timesheet, you'd enter the quotation for the timesheeted service.
6. Hit save.

## Expected behavior
The quotation entered as Sales Order Item field in the timesheet persists, while the Sales Order Item field of the ticket stays empty.

## Unexpected Behavior
the Sales Order Item field in the timesheet tab disappears.

## Origin of the issue
The field is_so_line_edited was kept at false as the widget used to
update its value wasn't used in the view.

_
opw-5384256

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

When applying a downpayment in POS with tax-included prices, a rounding error of 0.01 cent could occur, preventing invoice creation.

For example, with an 8% tax and a downpayment of exactly 2,117.00:
- Calculation: 2117 ÷ 1.08 = 1960.185 → rounds to 1960.19
- Recalculation: 1960.19 × 1.08 = 2117.005 → rounds to 2117.01
- Result: 0.01 cent discrepancy

Root Cause:
-----------
The issue stems from cascading rounding errors when using 'round_per_line' method with standard product price precision (typically 2 decimals). Each intermediate calculation introduces a small rounding error that accumulates.

Solution:
---------
Apply two specific fixes for downpayment products only:

1. Use higher precision (6 decimals) instead of standard product price precision to maintain accuracy through the calculation chain

2. Force 'round_globally' rounding method instead of 'round_per_line' to ensure rounding happens only once at the final step, not at each intermediate calculation

3. Use raw (unrounded) amounts in tax calculations to preserve full precision until final rounding

opw-5040722

When a user is viewing a page, clicks on the Knowledge Book icon, opens an article, and selects the "Send As Message" button in a Knowledge Clipboard block, the macro system performs several actions: it restores the initial view, opens the full mail composer, and inserts the clipboard block's text at the very end of the editor.

Recent updates introduced automatic inclusion of the user's signature in the email body when the full mail composer is opened. As a result, the clipboard text is inserted after the user signature, which is undesirable because users must manually adjust the message to position the signature correctly.

To insert text before the user signature but after the user text, the clipboard macro will now trigger a "click" event on the button opening the full mail composer and set on that event the text to insert. The chatter will then read that value and insert the text at the right place.

Task-4428445

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

l10n_mx_edi* = l10n_mx_edi, l10n_mx_edi_pos, l10n_mx_edi_extended

**STEP TO REPRODUCE**
1. Create a invoice with:
    - product price = 72.89
    - discount = 10%
    - tax = 16%
2. Duplicate the invoice until you have 5 of them.
3. Create a global invoice with the 5 invoices, and send it.
4. The invoice will be refused by the EDI due to rounding issue.

This PR is a backport of multiples fixes done in 18.3 in which all rounding errors are fixed.
Each of them iterate upon the previous one, so they are all needed. The most important changes in thoses fixes are:
    - for global invoices, deduce the discount on the base line instead of creating a 'descuento' (to avoid any problem with rounding when combining multiples invoices).
    - changes in how the negative lines are dispatched.
    - using raw values for 'conceptos' and 'impuestos' (5 digit precision) and changing how we compute things to solve rounding issue.

Tests files are modified accordingly, you can launch the tests with the external flag (need to be set in tests/common.py).

Backported PR (non-exhaustive):
https://github.com/odoo/enterprise/pull/92727
https://github.com/odoo/enterprise/pull/99395
https://github.com/odoo/enterprise/pull/90434

opw-5382423

Steps to reproduce:
===================
1- Drop the block tab snippet
2- Inside one of the tab panes, drop a Columns snippet.
3- Select background_color for one of the columns
4- Change tab style to tab

-> The background color of the inner column is overridden.

Cause:
======
When the "Tabs" snippet style is set, a `.card` class is added to its container (See [1])
A generic CSS rule, intended to style these tabs, was targeting any `.card` element with a `.card-body` child. (See [2])

However, the Columns snippet also uses a `.card > .card-body` structure (distinguished by a `data-vxml` attribute). This caused the overly broad tab-styling rule to incorrectly cascade and override the background color of the nested column.

Solution
========
The SCSS selector has been made more specific so that works if `card-body` class doesn't have any parent class with class `card` and has attribute `data-vxml`

[1]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/website/static/src/snippets/s_tabs/options.js#L149
[2]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/web/static/src/scss/bootstrap_review_frontend.scss#L55

opw-5394480

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

The runbot builds are currently failing after the recent merge of commit [1]
due to a triggered documents logger warning.

In commit [1], `cls.attachment_txt` is created with invalid `datas` in
`setUpClass`, which triggers an error and raises a log warning at code
line [2]. We already added `mute_logger` to suppress this log, but it does
not work due to caching behavior in setUpClass.

The `setUp` method of the `TransactionCase` test class attempts to flush all
pending data (see code reference [3]). During this flush, it recomputes the
values of `cls.attachment_txt`, which triggers the same logger warning again.
Since this occurs outside the mute_logger context, the log is not suppressed,
resulting in the runbot failure.

This commit fixes the issue by introducing a helper method to create and
return `attachment_txt` for use in the test methods.

[1]: https://github.com/odoo/enterprise/commit/d4ecf6c75bff3fc29a95c40f86528c6b10870e12
[2]: https://github.com/odoo/enterprise/blob/f3e2de6bae7573ad61429a55ff3769ba7fab58ea/documents/models/documents_document.py#L1355-L1356
[3]: https://github.com/odoo/odoo/blob/8e60084924d390632934b5a9bd82a6954d6484de/odoo/tests/common.py#L1038

runbot-238369

This PR is essentially a backport of
https://github.com/odoo/odoo/pull/242810.

Original comment:
Whenever an error occurs during the ZATCA onboarding steps—such as providing a company name that exceeds 127 bytes in binary representation (for example, 64 Arabic characters without whitespace result in exactly 127 bytes; see refs [1] and [2])—the system returns a traceback to the user instead of a clear and user-friendly error message.

Error:
`TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType'

This is due to the check-in `_l10n_sa_get_production_CSID` for an 'error' key, not present in the response when an OTP is invalid because in these cases, the `_l10n_sa_call_api` returns the response_data directly.

This fix improves the behaviour by displaying a user-friendly alert message with the error returned by ZATCA, instead of a traceback.

This ensures a better experience and compliance with CCSID onboarding flows.

[1]: https://zatca1.discourse.group/t/organization-name-is-too-long-issue-csr/7571
[2]: https://zatca1.discourse.group/t/organisation-name-with-restriction-of-64-characters/960

opw-5228665