After commit 3cbaad4,
the theme manifest is now looked up to find addon snippets for the configurator. However, during an upgrade, if a website is configured with a third-party/custom theme whose code is not present in the addons path, `Manifest.for_addon()` returns `None` and `_generate_primary_snippet_templates` raises an `AttributeError`:
```py
2026-06-16 03:27:47,155 24126 INFO db_4367932 odoo.modules.loading: loading website/views/new_page_template_templates.xml
2026-06-16 03:27:47,803 24126 WARNING db_4367932 odoo.modules.module: module theme_prime: manifest not found
2026-06-16 03:27:47,845 24126 WARNING db_4367932 odoo.modules.loading: Transient module states were reset
2026-06-16 03:27:47,846 24126 ERROR db_4367932 odoo.registry: Failed to load registry
2026-06-16 03:27:47,846 24126 CRITICAL db_4367932 odoo.service.server: Failed to initialize database `db_4367932`.
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 605, in _tag_root
    f(rec)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 273, in _tag_function
    _eval_xml(self, rec, env)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 197, in _eval_xml
    result = method(*args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/website/models/ir_module_module.py", line 704, in _generate_primary_snippet_templates
    theme_addons = theme_manifest.get('configurator_snippets_addons', {})
AttributeError: 'NoneType' object has no attribute 'get'
```
We also get the missing manifest logs right before the error.

TBG-2781

[`_generate_primary_snippet_templates`]: https://github.com/odoo/odoo/blob/19.0/addons/website/models/ir_module_module.py#L700





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

Forward-Port-Of: odoo/odoo#270217

Steps to reproduce:
----------------------------------------
- Have the company calendar work from 9 to 17 on weekdays
- In project gantt view, create tasks with dependencies like this:
```
- [Task 1] (June 08, 09:00 AM - 10:00 AM) ──┐
                                            ├─> [Task 3] (June 11, 09:00 AM - 10:00 AM)
- [Task 2] (June 10, 09:00 AM - 10:00 AM) ──┘
```
- Make sure the "Auto-Reschedule (Keep Buffer)" is selected
- Then reschedule task 1 to `(June 09, 09:00 AM - 10:00 AM)`
- Task 3 is rescheduled to `(June 15, 09:00 AM - 10:00 AM)`

**Expected behavior:**
To respect the buffers, task 3 should have been rescheduled to `(June 12, 09:00 AM - 10:00 AM)`:
- The buffer from task 1 is  23 working hours after `June 09, 10:00 AM` is `June 12, 09:00 AM`
- The buffer from task 2 doesn't affect the rescheduling.

Cause:
----------------------------------------
From `_web_gantt_update_next_candidates_dates()` we call `_get_new_dates()` with `seconds_between_tasks` being the duration of working hours between the end of task 1 and the start of task 3. We also call it with `first_possible_start_date_per_candidate` being the end of task 3 also depends on task 2.

Then `_get_new_dates()` counts the working hours from `first_possible_start_date_per_candidate` until it reaches `seconds_between_tasks`. Which means the buffer between task 1 and task 3 is actually applied between task 2 and task 3.

Solution:
----------------------------------------
The value contained in `first_possible_start_date_per_candidate` is irrelevant, the correct value to give to `_get_new_dates()` would be `compute_end_date` as we want to keep the buffer to be calculated from this datetime.
So we create a fake dictionary with only the task and `compute_end_date` and give it to `_get_new_dates()`.

The same logic applies when moving tasks backwards.

opw-5973597

Forward-Port-Of: odoo/enterprise#119161

resource_calendar was not being when calculting virtual leaves, it leads to a singleton error here:
https://github.com/odoo/odoo/blob/11b0195dddad5055fc33fa3e28b2d2ca60f24935/addons/l10n_fr_hr_holidays/models/hr_leave.py#L163

```
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 519, in _table_sql
    table_query = self._table_query
                  ^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/addons/hr_holidays/report/hr_leave_employee_report.py", line 40, in _table_query
    self._compute_leave_duration(report_records)
   File "/home/odoo/src/odoo/saas-19.2/addons/hr_holidays/report/hr_leave_employee_report.py", line 94, in _compute_leave_duration
    leaves_durations = virtual_leaves._get_durations(additional_domain=[('holiday_id', 'not in', leave_ids)])
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/addons/l10n_fr_hr_holidays/models/hr_leave.py", line 160, in _get_durations
    while not leave.resource_calendar_id._works_on_date(date_start):
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/addons/resource/models/resource_calendar.py", line 877, in _works_on_date
    self.ensure_one()
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 5253, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
 ValueError: Expected singleton: resource.calendar()
```

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#266084

When importing a Peppol/UBL vendor bill containing a line with a 100% discount, the line was created in Odoo with quantity=1 and discount of 100*original_qty, instead of the
expected quantity=qty_original and discount=100%.

This happened because the line-level branching in
`_import_ubl_invoice_line_add_price_unit_quantity_discount` relied on the truthiness of `line_extension_amount` to detect whether the `LineExtensionAmount` node was present in the XML. a line with a genuine `<cbc:LineExtensionAmount>0</...>` was indistinguishable from a line where the node was missing, and fell
through to the fallback branch intended for incomplete XML. That fallback reconstructs the quantity from `<cbc:BaseQuantity>`, ignoring `<cbc:InvoicedQuantity>`, and then computes the discount percentage against the wrong denominator.

a `LineExtensionAmount` of 0 is the only legal way to express a fully discounted line, so this case must be distinguished from the node being absent.

the fix is simply checking if the line exist not if its True

opw-6176349

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

Forward-Port-Of: odoo/odoo#269322
Forward-Port-Of: odoo/odoo#265261

Description of the issue/feature this PR addresses:
  In the combo configurator dialog, a combo item's extra_price and the price_extra of no_variant attributes are stored in the company/product currency but were sent to the
  front-end without conversion. When the order uses a pricelist in a different currency, the popup shows these extras at face value (e.g. an extra of USD 1700 appears as ARS
  1700 instead of being converted). The sale order line itself already converts these extras, so the popup price and the actual line price didn't match.

  Current behavior before PR:
  _get_combo_item_data and _get_selected_ptavs_data return extra_price / price_extra raw, in the company currency. With a foreign-currency pricelist the combo configurator
  popup adds them 1-to-1 to the already-converted base price, displaying an incorrect total that doesn't match the resulting sale order line.

  Desired behavior after PR is merged:
  The controller converts extra_price and price_extra to the configurator's currency (via currency._convert()) before serializing them, so the popup shows the correct amounts
  in the pricelist currency and matches the price computed on the sale order line. A test (test_sale_combo_multicurrency.py) covers combo extra-price conversion with a
  foreign-currency pricelist.

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

Forward-Port-Of: odoo/odoo#269905
Forward-Port-Of: odoo/odoo#269386

### Issue
When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid

If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment
Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added

### Cause
When a new Bank Statement is created, `_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()`
This function creates a balancing line and triggers `move._compute_checked()` to update dependencies

However, `move.checked` requires `_is_user_able_to_review()` to be True
A user with "Invoicing & Banks" rights lacks the `account.group_account_user` group, meaning the move is not marked as checked, preventing dependencies from computing correctly
Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids`

Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)`
Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it

### Steps to reproduce
- Install `accountant`
- Go to Accounting / Configuration / Accounting / Journals
- Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts
- Update the Demo user's accounting rights to Invoicing & Banks
- Log in with the Demo user
- Create and confirm an invoice for Acme Corporation (Amount: $1100)
- Register a payment on the invoice (Amount: $500, Keep open)
- Copy the invoice name
- Open the Bank Reconciliation widget from the Accounting Dashboard
- Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500)
Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid

### Notes
Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation
This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow

A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability

opw-6077137

Forward-Port-Of: odoo/enterprise#120217
Forward-Port-Of: odoo/enterprise#118023

### Issue
When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid

If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment
Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added

### Cause
When a new Bank Statement is created,
`_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()` In 19.0, this function creates a balancing line and triggers `move._compute_checked()` to update dependencies
Especially `_compute_is_reconciled`
But checked as been replaced by `review_state`
This FW port will use an update on the `review_state` instead of the `checked`

A user with "Invoicing & Banks" rights lacks the
`account.group_account_user` group, meaning the move is not marked as `reviewed`, preventing dependencies from computing correctly Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids`

Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)`
Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it

### Steps to reproduce
- Install `accountant`
- Go to Accounting / Configuration / Accounting / Journals
- Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts
- Update the Demo user's accounting rights to Invoicing & Banks
- Log in with the Demo user
- Create and confirm an invoice for Acme Corporation (Amount: $1100)
- Register a payment on the invoice (Amount: $500, Keep open)
- Copy the invoice name
- Open the Bank Reconciliation widget from the Accounting Dashboard
- Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500)
Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid

### Notes
Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation
This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow

A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability

opw-6077137

Forward-Port-Of: odoo/odoo#270080