Before
---

- When opening the appointment page, the possible capacities that a user can book needs to be calculated to show the capacity dropdown.
- This is currently done by getting all the possible combinations that could arise from each resource along with its linked resources (Linked resources are resources that are used to combine with the main resource to allow a bigger capacity)
- The complexity of this approach blows up with the increase in linked resources. For each resource we end up with O(2^m) where m is the number of linked resources it has. If they have the same number of linked resources, and n is the number of resources, we end up with O(n*2^m)

Solution:
- Flipping the algorithm, we create a structure for possible capacities and only keep the best combination for a found capacity.
- We first store all available capacity for relevant resources.

Algorithm
---

For a resource:
- We initialize the solution S to {0: []}
- Greedy dynamic programming is then used to get all the possible combinations by building the result dict, adding one resource at a time. We add its capacity to all entries of S -> we use the combination if a new capacity is reached OR update the combination if the number of elements of combination is less than the existing one.

Then, for the global solution:
- We go through S of resources (in the order of self), and add entries to G (the general dict of solutions). Again, on collision, we only keep the lower-cardinal combination.

The complexity of this algorithm is O(n*u) where u is the dynamic programming complexity. u would be quadratic O(m^2) if the sub-sums of capacities overlap heavily, for instance when resources have the same capacity, like tables of a restaurant, but could reach (2^m) in the worst case scenario.

Related changes / side effects
---

1. Fixing an issue

2. Cleaning strange logic

3. Cleaning max capacity computation

Benchmark:
- opw-5177932 goes down from 6 mins to less than 2 seconds using the new algorithm.

Also include
---

Fix the max capacity on resources when skipping resource selection. It computed the max capa based on values that were not yet emptied in the website_appointment controller.


Task-6233563

Forward-Port-Of: odoo/enterprise#118981

Steps to reproduce:
1. Install documents and sales
2. Check product document centralization from settings, and no alias should be set
3. Now go to setting>techinical>emial>aliases>remove default filter and  check total count
4. Go to products and add a document from the smart button
5. Now again check the aliases total count (1 increased)
6. Delete the document on the product.
7. Alias is not deleted
8. Try to add an alias from the settings

Issue:
- When `documents_product` is installed and product document centralization is enabled, deleting a `product.document` can leave an orphan `mail.alias` resulting in an error while creating a new alias.

Cause:
- A product document owns an `ir.attachment`, and that attachment is mirrored as a `documents.document` for `product.product` / `product.template`. In 18.0, `documents.document` inherits `mail.alias.mixin`, so the mirrored document also owns a `mail.alias`.

- Deleting `product.document` deletes its `ir.attachment`. The linked
  `documents.document` is then removed by SQL `ondelete='cascade'` on
  `attachment_id`, not through ORM `unlink()`. Because the document unlink logic
  does not run, the alias cleanup from the mail alias mixin is skipped.

Why not reproducible in 19.0:
- In 19.0, `documents.document` uses `mail.alias.mixin.optional` instead of `mail.alias.mixin`. Binary mirrored documents no longer create a `mail.alias` unless an `alias_name` is explicitly set, so product mirrored documents do not create aliases in the first place.

Solution:
- Override `ir.attachment.unlink()` in `documents`. before deleting attachment,
  collect linked document aliases then delete attachment. SQL cascade deletes
  linked documents.document rows and now we delete collected aliases.


opw-6019294

Forward-Port-Of: odoo/enterprise#110486

**Steps to reproduce:**
* Install the **Netherlands - SBR** (`l10n_nl_reports_sbr`) and **Netherlands - SBR OB Nummer** (`l10n_nl_reports_sbr_ob_nummer`) modules.
* Create two companies with Dutch localization.
* Go to **Accounting → Configuration → Tax Units** and create a Tax Unit with its own **Tax ID** (e.g. `NL826317558B01`), adding both companies.
* On the main company form, fill in the **Omzetbelastingnummer** field (e.g. `123456782B90`).
* Go to **Accounting → Reporting → Tax Return**, select the Tax Unit in the filter, and click **XBRL → Download XBRL File**.

**Observed behavior:**
* The `<xbrli:identifier>` in the exported XBRL file contains the company's **Omzetbelastingnummer** (`123456782B90`) instead of the Tax Unit's VAT (`826317558B01`).
* The tax authority rejects the return because the identifier does not match the fiscal unity registration.

**Cause:**
* `_get_sbr_identifier()` in `l10n_nl_reports_sbr_ob_nummer` unconditionally returns `self.env.company.l10n_nl_reports_sbr_ob_nummer` before consulting the Tax Unit.
* The `super()` call, which correctly routes to `tax_unit.vat` via `report.get_vat_for_export()`, is only reached when the company field is empty — so the Tax Unit's VAT is never used when a company OB-number is set.

**Fix:**
* When a Tax Unit is active in the report options, delegate immediately to `super()._get_sbr_identifier()`, which resolves `tax_unit.vat` through the existing `get_vat_for_export()` logic.
* The company-level `l10n_nl_reports_sbr_ob_nummer` override is preserved as a fallback for the `company_only` (no Tax Unit) case.

opw-6350840

Forward-Port-Of: odoo/enterprise#126876
Forward-Port-Of: odoo/enterprise#125167

**Steps to reproduce:**

- Install l10n_pl_edi and enable Allow KSeF integration from 
  **Accounting** settings. 
- Switch to a Polish company.
- Create an EU customer with a valid VAT number.
- Create a sale order containing a service product taxed 
  with 0% Steel (or any tax that has a tag of K11).
- Confirm the sale order and create a down payment invoice. 
- Send the invoice to KSeF and inspect the generated XML. 

**Observed behavior:**

The generated KSeF XML does not contain the `P_13_8` field. 

**Cause:**

For invoices involving the tax of tag `K11` (mainly these taxes are used for the supplies 
that are outside the territory of Poland), the value corresponding to `P_13_8` was not 
being assigned during XML generation, causing the tag to be omitted from the exported 
KSeF document.

**Fix:**

Populate the value of `P_13_8` during KSeF XML generation for invoices, ensuring the 
field is correctly included in the exported XML. 

This PR updates the computation of tag `P_13_10` with its test case to ensure consistency 
with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

**opw**-6294181

Forward-Port-Of: odoo/odoo#276887

Before this commit, the `empty a many2one field in list view` test sometimes failed, because the many2one value wasn't correctly unset (`first record` was selected). This happened because we cleared the input and automatically validated (typically with tab). However, it could happen that the validation occurred after the dropdown was opened, so the first value of the dropdown was selected. As a matter of fact, adding `await runAllTimers()` after clearing the input is a way to make the test fail deterministically.

This commit avoids the issue by emptying the many2one without validation, so it basically only set the input value to the empty string, but doesn't tab/enter or anything else, hence it never selects an unwanted value.

runbot error-941430

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

This is rather an attempt of fix, as we couldn't reproduce the error locally or in a multi build., so we have no guarantee that this strenghtens the test.

The test sometimes fails as `.o_crop_icon` can't be found within 200ms. Before that, we wait for the video element to be ready (we rely on a patch of the `isVideoReady` method of the component to know that the video is ready). Once it is, the isReady flag in the state is set to true and the CropOverlay component renders its `o_crop_icon` element.

Our guess is that we may sometimes early return in `isVideoReady`, because the component has been destroyed (a new rendering might be on the way). To ensure that we don't take that as the ready signal in the test, we now only consider that we're ready if isVideoReady returned true (i.e. no early return).

runbot error-241798

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

When a product carrying a multi-select (no_variant) attribute is added to an order by scanning its barcode, the extra price of the selected attribute value was dropped and the product was added at its base price.

The order line total is computed from `price_unit` alone. The `price_extra` of a no_variant attribute is never included in the variant price (a "multi" attribute requires create_variant="no_variant"), so it only reaches the total once folded into `price_unit`. `addLineToOrder` did that fold-in only when the product was not scanned (`!isScannedProduct`).

That guard was added to avoid counting the extra price twice when scanning an "always" variant barcode, whose extra is already part of its price. Since then, the extra price reaching this block is filtered to no_variant values only, both in the configurator and in the direct-variant branch, so an "always" extra can no longer reach it and the guard now only drops legitimate no_variant surcharges.

Remove the guard so the no_variant extra price is always applied.

Steps to reproduce:
- Create a product with a multi-checkbox attribute whose value has an extra price, and give the product a barcode.
- Open the PoS and scan the barcode.
- Pick the attribute value in the configurator and validate. => The extra price is not added to the order line.

opw-6413924

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

Forward-Port-Of: odoo/odoo#278389

Steps to reproduce the error: (Python Version: 3.14.X)
- Install ``accounting_firm`` industry with demo data

Code for server action to generate the error:
```py
for i in [1]:
    try:
        pass
    except Exception:
        pass
    if i:
        pass
```

Traceback:
```py
ValueError: forbidden opcode(s) in'...': JUMP_BACKWARD_NO_INTERRUPT
```

https://github.com/odoo/industry/blob/701f7595453772e42ce72aa75df346a504e5bd82/accounting_firm/demo/ir_actions_server.xml#L105-L108
The server action contains a ``for`` loop with a ``try/except`` block followed by additional statements in the loop body,
this combination generates the ``JUMP_BACKWARD_NO_INTERRUPT`` opcode, which is not included in ``_SAFE_OPCODES`` at [1].
When the server action is evaluated by ``safe_eval``, it calls the ``assert_valid_codeobj`` method, which validates the compiled bytecode against ``_SAFE_OPCODES``. Since ``JUMP_BACKWARD_NO_INTERRUPT`` is not present in the allowed opcodes, ``assert_valid_codeobj()`` raises a ``ValueError`` at [2] before the server action is executed .

Solution:
``JUMP_BACKWARD_NO_INTERRUPT`` opcode is added in the ``_SAFE_OPCODES`` and it is also added in the ``_SAFE_QWEB_OPCODES``.
It was added in Python 3.11: https://docs.python.org/3/whatsnew/3.11.html#new-opcodes

``JUMP_BACKWARD_NO_INTERRUPT`` is a control-flow opcode that only changes
the interpreter's execution flow by jumping back to a previous instruction.
It is the equivalent to ``JUMP_BACKWARD`` opcode. Its only semantic difference is
that the interpreter does not perform an interrupt check at that instruction.
It does not introduce any new capabilities or perform operations such as
attribute access, imports, function calls, or object creation.
Ref: https://docs.python.org/3.12/library/dis.html#opcode-JUMP_BACKWARD_NO_INTERRUPT

Similar commit that adds some necessary opcodes: 
https://github.com/odoo/odoo/commit/86498d24946e510025add5d24ef0d4bcce8ad05f

[1]: https://github.com/odoo/odoo/blob/2ccbc4660077bd48529e9de43d4309fbfafc75ca/odoo/tools/safe_eval.py#L135
[2]: https://github.com/odoo/odoo/blob/2ccbc4660077bd48529e9de43d4309fbfafc75ca/odoo/tools/safe_eval.py#L244-L246

sentry-7614026125

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

Forward-Port-Of: odoo/odoo#277192

## Issue
When logging timesheet from the *Recorded* smart button on a Sale Order containing multiple service items, the recorded hours will be added to the first sale order line, regardless of the task ID set on the timesheet entries.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P:
    - *Product Type*: Service
    - *Create on Order*: Task
    - *Project*: Any
3. Create a SO:
    - *Customer*: Any
    - Add the product P on two different lines and give them two different descriptions D1 and D2
    - Confirm the SO, this will create two tasks with the names D1 and D2
4. On the SO, click the *Recorded* smart button and create two entries:
    1. Task D1, 2 hours spent
    2. Tsk D2, 3 hours spent
5. **Back on the SO, there are 5 hours registered for the first SOL (with the description D1), which does not match the entries we created from the smart button.**

It is worth noting that when we create the Timesheets entries from the project itself (instead of the SO's smart button), the hours are correctly distributed among the different SOLs.

## Cause
The SOL linked to the timesheet entry (`account.analytic.line`) is computed by `_compute_so_line`:

https://github.com/odoo/odoo/blob/8b102f500f5a122e99b07a08cc43814e7c6f0f75/addons/sale_timesheet/models/hr_timesheet.py#L79-L82

This method sets the correct SOL under the condition that `is_so_line_edited` is False and `_is_no_billed()` returns True.

When opening the *Recorded* smart button from a SO, the `is_so_line_edited` is set to True by default, even if no SOL was modified.

https://github.com/odoo/odoo/blob/8b102f500f5a122e99b07a08cc43814e7c6f0f75/addons/sale_timesheet/models/sale_order.py#L113-L117

As that value is never set to False, when trying to compute the SOL for the timesheet entry, the entry is skipped and the default SOL (which is the first one) is used instead.

opw-6133473

Forward-Port-Of: odoo/odoo#274759

Issue:
---
Fiscal position is wrongly set to `self.env.user.partner_id.country_id`
instead of `partner_shipping` country, if `partner_shipping_id` is not
changed in the checkout process.

Steps:
1- Create two auto detect fiscal positions: France, Germany
2- Set portal user's partner address country to France.
3- Using portal user, shop from website, and create a delivery address.
4- Pay and confirm the order.
5- Using the admin user, you check the SO's FP which is correctly set
   to Germany.
6- Using portal user, again shop from website, and don't change
   address. Keep previous shipping address which is Germany.
7- Confirm and pay the order.
8- Using admin user, check the new SO's FP. It's set to France.

Cause:
---
`_compute_fiscal_position_id` in SO depends on `partner_shipping_id`.
When the `partner_shipping_id` is not changed, the fiscal position
value set in create will remain.
This value is set in `Website._prepare_sale_order_values()`.
The `fiscal_position_id` is set to self.fiscal_position_id, which is
`_get_fiscal_position(self.env.user.partner_id)`.

Fix:
---
If the user has already a SO, we can use last SO's shipping address
and invoice address to calculate FP in `_prepare_sale_order_values`.

opw-6357638

Forward-Port-Of: odoo/odoo#278974
Forward-Port-Of: odoo/odoo#276485

Before this commit, this test sometimes failed because it couldn't find a dialog containing "camera" within 200ms.

In the test scenario, we click to open the BarcodeDialog, which uses the BarcodeVideoScanner. The latter, in its `onMounted`, checks whether it has the necessary permission, which isn't the case as the `getUserMedia` function is mocked in the test to return a rejected promise. As a consequence, the `onError` callback given in props is called, which changes the state of the parent component, which re-renders itself so display "Unable to access camera" instead of the BarcodeVideoScanner.

To make this test more robust, we do 2 things:
1) load the zxing library before running the test, which avoids the BarcodeVideoScanner component to load it in onWillStart. 2) explicitly wait for the 2 animationFrames, as in the scenario, we must wait for the BarcodeDialog to be rendered twice, and those renderings are now synchronous.

runbot error-237933

Forward-Port-Of: odoo/odoo#280613

Steps to reproduce:
- From the website editor, open the Theme tab.
- Upload a custom font.
- Open the media dialog and go to the "Documents" tab.

Issue:
The uploaded font files appeared in the Documents tab. When a zip file was uploaded, every font it contained appeared individually, along with the generated "CSS font face" attachment.

Cause:
Fonts uploaded through `/website/theme_upload_font` are created as public attachments. The Documents tab of the media dialog lists every public attachment that is not an image or an asset, so the font files (mimetype `font/...`), their font face declaration (mimetype `text/css`) and googleFontMetadata (server caches it as public attachment) were listed.

Fix:
Exclude those attachments from the Documents tab domain:
- whose mimetype starts with `font/`,
- whose description matches the font face declarations created in `snippets.options.js`.
- whose name equals "googleFontMetadata".

task-[4771523](https://www.odoo.com/odoo/project/974/tasks/4771523)

Forward-Port-Of: odoo/odoo#275838

Steps:
- Install sale_management
- Make sure you have 100 quotations with 1 activity each
- Open activity view
- Default pager displays `1-100/100`
- Activity count display `To-do 80`

ActivityController uses `useModel` which passes the raw `component.props` to
`model.load()`, including the limit from `ir.actions.act_window` (default 80).
This value ended up in `fetchActivityData` via `params.limit || this.initialLimit`,
overriding `ActivityModel.DEFAULT_LIMIT` (100).

The records list was not affected because `RelationalModel._getNextConfig` never
reads `params.limit` (limit is not a `SEARCH_KEY`), so it always loaded 100
records correctly. But `fetchActivityData` used 80, causing a mismatch between
the records shown and the activity counts in the column headers.

```js
export const SEARCH_KEYS = ["comparison", "context", "domain", "groupBy", "orderBy"];
```

The fix strips `params.limit` in `ActivityModel.load()` before passing params to
`fetchActivityData`, so it falls back to `this.initialLimit (100)`. The pager
`onUpdate` handler calls `fetchActivityData` directly with its own `params.limit`
and is not affected.

However, `ActivityController` never forwards `limit` to the model. This
is why we always have `ActivityModel.DEFAULT_LIMIT (100)` without taking
into account actions's limit. To fix this we have to add the limit via
`this.props.limit`, as `ListController`.

`useModelWithSampleData` already had the correct behavior by calling
`model.load(getSearchParams(props))` which filters out non-search params like
limit. In 19.0 useModel was updated to do the same, so the issue does not
exist there.
Link to 19.0 fix: https://github.com/odoo/odoo/pull/211697

opw-6281125

Forward-Port-Of: odoo/odoo#273929