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

### 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#105542
Forward-Port-Of: odoo/enterprise#103835

## Issue
When printing the barcode for a product, only a blank page would be printed.

## Steps to reproduce
1. Install Barcode (`stock_barcode`)
2. Create a product and set a barcode
3. On the product page, click Actions (cog wheel) > Print Labels
4. Print with any of the following format:
    - Dymo
    - 2 x 7 with price
    - 4 x 7 with price
    - 4 x 12
    - 4 x 12 with price
5. **For the Dymo format, the barcode is not displayed properly. For the four other formats, a blank page is printed**

## Cause
[This commit](https://github.com/odoo/odoo/commit/b7ec60d68c6ee23f7684960e33e5bd6290c9d829) made the `t-call` tag parametric, replacing the `t-set` and `t-value` pairs in various contexts. In this case, the parameters were not added to the correct `t-call`. Without `columns` and `rows` defined, the `report_productlabel` template would not produce anything:

https://github.com/odoo/odoo/blob/b6598c11a3580cfc6ff1ffeb67b0d388c55383d1/addons/product/report/product_product_templates.xml#L129-L131

opw-5877421

**Steps to reproduce:**
* Install the **Accounting** and **partner_commission** modules.
* Create a contact and set a **commission plan (e.g. 50%)** in the *Partner Assignment* tab.
* Create and confirm a customer invoice with multiple lines (e.g. 750, 750).
* Then go to **Dashboard → Transactions**, create a new transaction (e.g. 750) and reconcile it with the created invoice.
* Create a **credit note** from the invoice and confirm it.
* Open the contact and access **Purchase Orders** from the stat button.

**Observed behavior:**
* Only the commission line from the original invoice appears in the partner purchase order.
* No **negative commission line** is created for the credit note.

**Cause:**
* Credit notes reused the original commission linkage instead of generating a dedicated commission entry.
* This prevented commission reversal from being recorded for refunds.

**Fix:**
* Generate a **separate commission line** with a negative amount for each credit note.
* Assign a dedicated `commission_po_line_id` to credit notes.
* Copy only the `referrer_id` to credit notes, not the original commission line reference.

opw-5357773

Forward-Port-Of: odoo/enterprise#103328

Message access is notably based on related document, given their
(model, res_id) pair. Model may customize the required access on
it in order to access their message. For example, you generally
need write access to create a message (post) but on some models
you can post when you can read. Calendar events message access depends
on calendar privacy settings.

This is controlled via '_get_mail_message_access'. However currently
it is "globally called", for all documents. It should be done on a
per-document basis, as each document could define different access
check.

Keep code somewhat optimized by doing access checks in batch for a
given operation.

Make _search and read symmetric. Reading documents should be allowed
on search results, and search results should match what is available
for reading.

Portal users have some specific domains applied when accessing
messages, see notably odoo/odoo@9cd9aaaa174ae1f2a0af12143a34eb4682ea6f59 (but also check for
'website_message_ids' domain, mail controllers, ...). However there
are still some cases where search and read are not coherent with
portal users. This is not really annoying as most messages are accessed
using sudo and correctly tailored domains via controllers but let
us try to have a more correct code.

Fix discuss display of chatter-related buttons
* not taking into account '_get_mail_message_access' to check if
  user has right to post (generally used to indicate users can
  post on readonly records, but not limited to that);
* not adding the same check on Activities button as on Send message
  and Log note. We consider generally that rights should be aligned
  and UX should match that behavior;
* not adding the same check on attachments buttons, currently limited
  to write access (or always accessible). This is a preliminary work
  for attachments, further fixes are probably incoming;

Mainly a backport of master improvement done at https://github.com/odoo/odoo/pull/214705 .

Task-5138368
opw-4785878

Forward-Port-Of: odoo/odoo#245736
Forward-Port-Of: odoo/odoo#233725