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

Problem:
When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines.

Solution:
We will convert the component cost to the invoice currency when computing price difference.

Steps to reproduce (runbot 18):
- Product with
	- Standard price auto
	- BoM: sbc, one component with nonzero value (e.g. $1)
	- Nonzero value (e.g. $5)
- Another currency
1. Create a PO for the subcontracted product
2. Set the Invoice currency to something other than the company default
3. Confirm the PO and validate the sbc and receipt
4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency)

A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference.

opw-5232917

Forward-Port-Of: odoo/odoo#243801
Forward-Port-Of: odoo/odoo#238428

Steps:
- Install Razorpay and sales app.
- Create a SO and try to pay with UPI pm in IOS mobile.

Issue:
- After payment compilation it is trying to redirect to `callback_url` which should
only trigger when `redirect` is `True`.

Cause:
- In Razorpay documentation it's not clearly mention it will only trigger `callback_url`
when `redirect` is `True`, so in some cases it redirect to `callback_url` even `redirect` is
`False` which is cause issue during signature verification as it try to verify signature
according to `is_redirect` with `razorpay_secret` but in oAuth `razorpay_secret` is not
set.

Razorpay doc link:
https://razorpay.com/docs/payments/payment-gateway/web-integration/standard/integration-steps/#123-checkout-options

<img width="670" height="537" alt="image" src="https://github.com/user-attachments/assets/81c855c0-aaca-4953-bcff-942bc11a32d2" />


Fix:
- Only set `callback_url` for `REDIRECT_PAYMENT_METHOD_CODES` PMs
where we expect it to redirect to `return_url` and not in the oAuth flow, Instead
relying on the `redirect` option of the Razorpay.

opw-5389499

Forward-Port-Of: odoo/odoo#243054

Currently, an error occurs when user tries to run Confirm Entries server action on records with same name/number.

Steps to replicate:
- Install `accountant` without the demo and open Journal Entries.
- Create a new Journal Entry, add a move line, and duplicate the entry.
- From the list view, select both entries and type `test` in the Number field.
- Confirm the prompt to apply the same value to all selected entries.
- Finally, select both entries and click `Confirm Entries` from the cog menu.

Error:
`ValueError: UniqueViolation('duplicate key value violates unique constraint "account_move_unique_name"\nDETAIL:  Key (name, journal_id)=(BILL20250808, 9) already exists.\n') while evaluating 'action = records.action_validate_moves_with_confirmation()'`

Cause:
- The error occurs after a recent addition of a [feature] that allows direct posting of a journal entry if the entry doesnt need to be hashed.
- The normal function call was changed to be a server action that either directly posts the entries or opens a wizard depending on whether the entries need hashing or not.
- Journal Entries with the same number when getting posted leads to the `UniqueViolation` error.

Solution:
- Added a check based on the fields `name` and `journal_id`, which raises a Validation error if a user attempts to post an entry when another entry with the same number already exists or user tries to post two entries with the same number.

[feature]: https://github.com/odoo/odoo/pull/224008

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

The system crashes with an error when a user tries to add a new product to a Sale Order that is already confirmed.

**Steps to produce:**
- Install `Sales and stock` module without demo data.
- Make SO with customer and product and confirm the SO.
- Duplicate the SO and confirm it also.
- Now go to first SO > delivery > Additional info > change the sale order to second one.
- Then go to second SO > delivery > open the delivery where source document as second order > Additional info > change the sale order to first one. (Basically, we manually swap the pickings.)
- Go to the first SO and add new product and click on save.

**Error:**
`ValueError: Wrong value for stock.picking.sale_id: sale.order(3784, 3727)`

**Cause:**
- At [1], The domain used in the search returns two pickings, but because `limit=1` is applied, only the first picking is returned. which is not the one we want.
- The domain conditions match both pickings, which causes the wrong picking to be selected.
- At [2], When updating the `reference_ids`, the new sale order reference is added, but the previous sale order references are not removed.

**Solution:**
- This PR ensures that all previous sale order references are removed from `reference_ids` before adding the new one.
- This prevents multiple sale orders from being linked at once and ensures the correct picking is selected.

[1]https://github.com/odoo/odoo/blob/0313a5e47cfa3f338bd80ac25becd09862f0e11c/addons/stock/models/stock_move.py#L1389-L1390
[2]https://github.com/odoo/odoo/blob/0313a5e47cfa3f338bd80ac25becd09862f0e11c/addons/sale_stock/models/stock.py#L194-L195

**sentry-7013716337**

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

Currently, an error occurs during payslip issue computation when running the cron job `HR Employee: Update Current Version`.

**Steps to replicate:**
* Install `l10n_mx_hr_payroll_account_edi` with demo data and switch to `MX company`
* Employees > Create a new Employee > Payroll > Set `Contract` and save
* Payslips > Create a new Payslip with that Employee
* Run the scheduled action `HR Employee: Update Current Version`

**Error:**
`TypeError: Object of type datetime is not JSON serializable`

**Root cause:**


- The scheduled action `HR Employee: Update Current Version` tries to change
  the employee `current_version_id` at code line [1] from the CRON (the CRON
  will adds  the `cron_end_time` key with the `datetime` object in environment
  context (see [2])).
- Since the field `version_id.contract_type_id.code` (see [3]) is set depending
  on the computation of the compute Json field `issues`, it triggers the
  `compute_issue` method to compute the issue from CRON.
- The method `_get_warnings_by_slip` called from the compute method
  `_compute_issues` which calls `_get_records_action` (see [4]) to get the
  action data, and inside this method we stored the current environment
  context (from cron) as a context of action (see [5])
- Now when the code line [6] tries to save the `issues` record with the action
  and the action contain the context key with an `datetime` object value, it
  will generate an error while `json.dumps` is calledat code line [7] while
  `convert_to_cache` inside Json Field.

Solution:
- This commit will fix the above issues by passing empty context if the
 `_compute_issues` called from the CRON
- This commit also prevents reassigning `employee.current_version_id` if it
  is the same as the version in `_compute_current_version_id`

[1]: https://github.com/odoo/odoo/blob/29dd50d78f413503360de2af52d2f7818b04f2f9/addons/hr/models/hr_employee.py#L522
[2]: https://github.com/odoo/odoo/blob/29dd50d78f413503360de2af52d2f7818b04f2f9/odoo/addons/base/models/ir_cron.py#L440
[3]: https://github.com/odoo/enterprise/blob/1072a10171226c225739b0deedc95f6c0980dfee/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L114
[4]: https://github.com/odoo/enterprise/blob/1072a10171226c225739b0deedc95f6c0980dfee/hr_payroll/models/hr_payslip.py#L1360
[5]: https://github.com/odoo/odoo/blob/29dd50d78f413503360de2af52d2f7818b04f2f9/odoo/addons/base/models/ir_ui_view.py#L3252
[6]: https://github.com/odoo/enterprise/blob/1072a10171226c225739b0deedc95f6c0980dfee/hr_payroll/models/hr_payslip.py#L1380
[7]: https://github.com/odoo/odoo/blob/29dd50d78f413503360de2af52d2f7818b04f2f9/odoo/orm/fields_misc.py#L74


[1]:
https://github.com/odoo/enterprise/blob/9af78f3178aa9c58b09c3b5288029ef12e8ecce6/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L115 
[2]:
https://github.com/odoo/enterprise/blob/3a32b235c9446e21ff158784316dc50ddc6a1c37/hr_payroll/models/hr_payslip.py#L1368
[3]:
https://github.com/odoo/enterprise/blob/769201e22618b6683863f0839d7ad80bea0927cf/hr_payroll/models/hr_payslip.py#L1300 
[4]:
https://drive.google.com/file/d/1WDyyrdnGGvkXj__wbe8gjE_hhcksMmc4/view?usp=sharing
[5]:
https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/odoo/orm/fields_misc.py#L74

sentry-6953498212

Currently, an error occurs when a user changes the quantity of a combo product.

Steps to Reproduce:

 - Install the `sale_management` module.
 - Go to `Combo Choices` and create `two combo choices`, each with at least one product.
 - Go to `Products` and create a product with type `Combo`, then add both `combo choices` to it.
 - Go to `Quotations` and create a new `quotation`. Add the newly created `combo product` in the order line.
 - Now, go back to the `combo product` and remove one of the combo choices from it.
 - Return to the `quotation` and change the `quantity` of the combo product in the sale order line.

`KeyError: product.combo(6,)`

After [this commit], when a user adds a combo product in a sale order line, the dialog for selecting single-choice options in the combo no longer opens. Starting from version 19.0, if a user wants to increase the quantity, they can do it directly from the order line.
However, if a user deletes one of the combo choices from the combo product and then tries to increase the quantity of the combo product order line, the compute method runs to update the sale order line price — including the removed combo choice product. In the combo_prices[1], it contains a record of the current combo choices, and when it tries to access the removed combo choice from it, it raises an error[2].

This commit ensures that if a user removes a combo choice from a combo product and then updates the quantity of the combo product line, the removed combo choice product order line is also deleted as like in the previous version.

[this commit]: https://github.com/odoo/odoo/pull/194496/commits/4a96d35655edd2ea94833dad0a335d26fa8e7c89

[1]- https://github.com/odoo/odoo/blob/257537584bedc1ab7db1bdc700f89145a3bb6095/addons/sale/models/sale_order_line.py#L736

[2]- https://github.com/odoo/odoo/blob/257537584bedc1ab7db1bdc700f89145a3bb6095/addons/sale/models/sale_order_line.py#L757

sentry-6952615636

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

## Issue:
When purchasing a product using AVCO (Average Cost) of FIFO, the product's cost is computed incorrectly after importing a vendor bill if the purchase is in a different Unit of Measure than the product's default
Specifically, quantities from the bill are not properly converted to the product's UoM, which leads to incorrect cost assignment

## Cause:
When you use AVCO or FIFO on a product and you buy it in another UoM, the quantity get from the bill isn't converted in `_get_value_from_account_move()`
The method `_get_value_data()` first checks the Invoices/Bills and then the SO/PO lines for any remaining quantities
Because the bill quantity isn't converted, part of the cost is incorrectly attributed to the Purchase Order as well: https://github.com/odoo/odoo/blob/6a901395b9bb7e037bd4dfa71d298ae5a9fbf7d0/addons/stock_account/models/stock_move.py#L276-L290
This leads to quantity and cost being partially assigned incorrectly

## Steps to reproduce:
- Enable Unit of Measure in Settings
- Create an AVCO (or FIFO) product with tracked quantities
- On the product form, go to Purchase Tab and add a vendor line (Vendor: Vendor, Unit: Pack of 6, Unit Price: 10)
- Create a Purchase Order and receive the product
- On the product page, the cost changed accordingly
- Upload a Bill for the PO and confirm
- The cost of the product is wrong and the move analysis too

opw-5091629

*: crm_livechat, im_livechat

Before this commit, auto-open of member panel and livechat info panel did not combine from [1].

This means that when livechat info was auto-open in livechat, this necessarily meant the auto-open of member list was disabled, and vice-versa.

This is a problem because when navigating between livechat and non-livechat would necessarily imply the dismiss of either panel, which is not good because the best default is having livechat panel open by default, and for non-livechat conversations it should auto-open the member list panel.

This commit fixes the issue as follow:
- auto-close of panel are aware of whether action are active, as removal of auto-open from auto-close makes sense only when another panel is made active when the older panel was visible
- closing of member panel by opening the livechat info panel should preserve auto-open of member list for other conversations

Task-5496830

[1]: https://github.com/odoo/odoo/pull/238472

https://github.com/odoo/enterprise/pull/104435

Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed.

**Steps to reproduce:**
1. Install `website_event` module with demo data.
2. Open any event page and activate the website editor.
3. Click on My Company under **Organizers** (also works with **Location**).
4. On the right sidebar click on "**Contact**" drop-down.

**Error:**
`ValueError: Domain() invalid item in domain: ')'`

**Cause:**
The fields `event.event.address_id` and `event.event.organizer_id` have `check_company=True`, which generates in a domain expression like this at [1]: 
```
(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of', [company_id])] or ['|', 
('company_id', '=', False), ('company_id', 'parent_of', '')]) + []
```

This domain is not evaluated on the back-end; instead serialized as JSON string. When the website editor opens the many2one dropdown, the JS code (ref 2) incorrectly splits this string into a list of individual characters, for example: 
```
['(', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ' ', 'a', 'n', 'd', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', 
"'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 
'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', '[', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ']', ')', ']', ' ', 'o', 'r', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 
'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 
'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', "'", "'", ')', ']', ')', ' ', '+', ' ', '(', '[', ']', ')', ['id', 'not in', [1]]]
```

Such a malformed domain passed directly to `name_search()` method, where **Domain()** fails to validate it, raising the error.

**Fix:**
This commit checks for unevaluated domains (returned as strings) and ignores them when rendering many2one fields in the website editor.

[1] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_editor/models/ir_qweb_fields.py#L255
[2] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_builder/static/src/core/building_blocks/select_many2x.js#L102-L109

sentry-6916986959

In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback.

### Steps to reproduce:

1. Enable packagings on inventory configuration.
2. Create a product, that as a least 2 variants.
3. Add a packaging to one of the variants.
4. Create a BoM for created product (kit type).
5. Create a picking order for the variant with packaging.
6. Print the picking operation to scan the code through barcode.
7. Go to barcode and try to scan it, this will trigger the traceback.

### Cause of the issue:
Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data:
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91
_get_stock_barcode_data will obtain the packaging methode for the products.
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16
since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information.

### Fix:
We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids:
https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441
our fix will allow for packaging in the variant to be considered when there is more than only one variant.

opw-4852875

Forward-Port-Of: odoo/enterprise#103256
Forward-Port-Of: odoo/enterprise#87867

During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records.

```py
  /home/odoo/src/odoo/19.0/addons/l10n_br/migrations/1.1/end-migrate-update_taxes.py(8)migrate()
-> env['account.chart.template'].try_loading('br', company)
  /home/odoo/src/odoo/19.0/addons/account/models/chart_template.py(170)try_loading()
-> return self._load(template_code, company, install_demo, force_create)
  /home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(12)_load()
-> self._l10n_br_init_avatax_code(company)
  /home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(324)_l10n_br_init_avatax_code()
-> tax.l10n_br_avatax_code = tax_data['l10n_br_avatax_code']
```

Because tracking was not disabled, this write triggered `mail.thread` tracking computation during module loading, leading to failures while finalizing tracking messages.

```py
  File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 576, in _track_finalize
    tracking = records.with_context(context)._message_track(fnames, initial_values)
  File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 697, in _message_track
    record._message_log(
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
    self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
    diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
    diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Porcentagem fatorial'
```

This occurs due to the interaction between:
- the `_load` override introduced in odoo/enterprise@eeaea338c1c6b9540a89be8003dadbe651de881e
- the new `try_loading` flow added in odoo/odoo@9d965abb992d558ea4235ef5f87a7654c6f1ceae

The resulting tracking computation crashes with a KeyError when processing repartition line diffs.

Fix: ensure `_load` runs with `tracking_disable=True`, as expected by the standard `_load` execution context, preventing tracking logic from running during module loading.

opw-5467986
upg-3753990
tbg-2380

Forward-Port-Of: odoo/enterprise#103931