In Hungary, we are already sending invoices to NAV(hungarian tax authority).
Now this module `l10n_hu_edi_receive` provides functionality of receiving vendor
bills through its API and also adds XML importer for Hungarian localization.

A button `Sync with NAV` is added in vendor bills list view, which opens a
wizard where you can select time period and all bills uploaded between that time
are fetched from NAV's API.

Also directly uploading XML is also supported in the format NAV supports.

Flow:-
- After selection of time range, we call `queryInvoiceDigest` endpoint with that
range and it returns a list of digests(consider each digest as separate invoice)
but this digests contains only meta data not all details.
- Now for each digest we call `queryInvoiceData` endpoint which returns xml
response with `QueryInvoiceDataResponse` as root node. This xml contains some
meta data and `InvoiceData` node which has a base64 string, when we decode that
string we get an xml with `InvoiceData` as root node and this xml contains all
details of the invoice, we parse both these details and create bills and refunds.

Also xml importer supports any of the `InvoiceData` or `QueryInvoiceDataResponse`
xml.

NAV Documentation: https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf

task-5237910

Forward-Port-Of: odoo/odoo#240919

**Steps to reproduce:**
* Install the Croatian e-invoicing module (**l10n_hr_edi**).
* Set up a Croatian company and a Croatian customer partner (with OIB and VAT configured).
* Create a customer invoice and post it.
* Create a credit note from that invoice via **Credit Note** button.
* On the credit note, change **Business Process Type** from `P9` to `P10: Issuing a corrective invoice`.
* Save the credit note.

**Observed behavior:**
* Saving fails with: "Business Process Type P9 can only be used with credit notes and vice versa."
* The error occurs even though P10 is a valid process type for credit notes according to the Croatian tax authority specification.

**Cause:**
* The `_check_l10n_hr_process_type` constraint used an XOR-style boolean check: `(process_type == 'P9') == (move_type != 'out_refund')`.
* This enforced an exclusive P9 ↔ out_refund mapping, making P9 the **only** allowed process type for credit notes and blocking P10 entirely.
* Per the Croatian tax authority specification, P10 (corrective invoice) is explicitly valid for credit notes: full cancellations report negative quantities/amounts, and partial corrections may report either positive or negative values.

**Fix:**
* Replace the XOR constraint with two independent, clearly-scoped rules:
  - P9 may only be used on credit notes (`out_refund`).
  - Credit notes must use either P9 or P10.
* Add P10 UBL type code mapping in `_ubl_add_credit_note_type_code_node()`: P10 credit notes now emit `CreditNoteTypeCode 384` (Corrected Invoice, UNTDID 1001) instead of falling through to the default 381.

opw-6128955

- Official Croatian Information Intermediary: https://portal.moj-eracun.hr/blog/kako-stornirati-eracun/
- Croatian Tax Authority (FAQ on fiscalization and e-invoicing): https://porezna-uprava.gov.hr/UserDocsImages/Fiskalizacija/Fiskalizacija_eRacun/Pitanja%20i%20odgovori%20vezani%20uz%20Zakon%20o%20fiskalizaciji.pdf

Forward-Port-Of: odoo/odoo#266288

Problem
-------------------
When there are multiple companies in the same country, and a employee is created, the default ruleset that is assigned can be from the wrong company. Steps  to repoduce:
1. Create Company A with Ruleset A
2. Create Company B with Ruleset B in the same country as Company A
3. Create an employee in Company B. The default ruleset is Ruleset A.

Cause
---------------------
When assigning the ruleset to the employee, rulesets for the country were searched and the first one that had a matching country was assigned to the employee, and since the companies were in the same country, the ruleset from Company A was assigned.

Solution
--------------------
Change the ruleset filters to search only for rulesets for the company, and use the default ruleset if none are found.

task-6147409

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

Steps to reproduce:
- Install `Accounting` and `l10n_es` module
- Switch to `Spain` company
- Open `Tax Returns`

Traceback:
```py
File "/data/build/enterprise/account_reports/models/account_return.py", line 2699, in _check_suite_common_ec_sales_list
engine_results = custom_handler._report_engine_ec_sales_report(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_sales_report.py", line 396, in _report_engine_ec_sales_report
return {next(iter(formulas_dict.values())): results} 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
StopIteration
```

Cause:
In the method `_check_suite_common_ec_sales_list`, `formulas_dict` is built by taking `line_ids[0].expression_ids.grouped('formula')`. This assumes the first report line always has expressions defined, which holds true for standard EC Sales List reports.

However, Mod 349 has a different report structure where the first line is a "Summary" line with no expressions, resulting in `formulas_dict` being an empty dict. When `_report_engine_ec_sales_report` then calls
`next(iter(formulas_dict.values()))` to retrieve the formula key, it raises a `StopIteration` error, causing a crash whenever a Spanish company opens the tax return report.

Solution:
Override `_check_suite_common_ec_sales_list` for Mod 349 to only run the basic checks, bypassing the engine call that caused the crash. All other return types still go through the generic suite via `super()`.

opw-6222938
sentry-7513259974

Steps-to-Reproduce
- Install hr_recruitment_survey
- Make a user with no Survey rights but Recruitment Admin.
- From that user go to Recruitment > Configurations > Interview.
- Trying to create record will reproduce this error
```
File "/home/odoo/src/odoo/saas-19.3/addons/hr_recruitment_survey/models/
survey_survey.py", line 19, in _compute_allowed_survey_types
    survey.allowed_survey_types = [*survey.allowed_survey_types, 'recruitment']
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 TypeError: Value after * must be an iterable, not bool
```

Reason
- Because user may not have survey rights return `[]` [here](https://github.com/odoo/odoo/blob/a7f9b44aad071efe401d3caa70d069aaf7e19cc9/addons/survey/models/survey_survey.py#L400) which gets converted to false by orm [here](https://github.com/odoo/odoo/blob/3a4b2a320c1496e97eeb1834862230439da6ea2f/odoo/orm/fields_misc.py#L55-L74).

- upg : [4282172](https://upgrade.odoo.com/odoo/upgrade.request/4282172)
- opw : [6231531](https://www.odoo.com/odoo/project/70/tasks/6231531)

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

Starting version 2.1.4 of markupsafe, they decided to adapt the `striptags` function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex.

A problem has been spotted with qweb templates that used `striptags` with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster. In fact, the PR introducing this change in Markupsafe, made these claims with no benchmarks whatsoever: https://github.com/pallets/markupsafe/pull/413/changes 

The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better for varying input size.

The benchmark cases below are in the form `<case_description>_<number_of_tags>`. We can see that in the cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex. Apart from that, in the case of an unclosed tag, the regex implementation is also slower because it still needs to scan the entire line. However, in that case the time taken is a handful of milliseconds, so it's not really a performance regression there either.

Apart from that, the old implementation is consistently much more performant, for both small and large inputs.

Benchmarks:

| Case                                      | Regex ms | Current ms | Speedup |
|----------------------------------------------|----------|------------|---------|
| plain_text_50k_words                         | 3.020    | 2.627      | 0.9x ← current_implementation |
| unclosed_tag_then_50kb_text                  | 0.367    | 0.032      | 0.1x ← current_implementation |
| unclosed_tag_then_500kb_text                 | 3.787    | 0.273      | 0.1x ← current_implementation |
| multiple_unclosed_open_tags_then_50kb_text   | 18.912   | 0.371      | 0.0x ← current_implementation |
| multiple_unclosed_open_tags_then_500kb_text  | 189.007  | 8.209      | 0.0x ← current_implementation |
| unclosed_comment_then_500kb_text             | 7.276    | 0.412      | 0.1x ← current_implementation |
| 5k_small_tags                                | 0.986    | 22.096     | 22.4x ← regex_old_implementation |
| 20k_small_tags                               | 4.125    | 492.186    | 119.3x ← regex_old_implementation |
| 50k_small_tags                               | 12.658   | 5499.602   | 434.5x ← regex_old_implementation |
| 1k_nested_divs                               | 0.155    | 0.923      | 5.9x ← regex_old_implementation |
| 10k_nested_divs                              | 1.648    | 48.410     | 29.4x ← regex_old_implementation |
| 2k_tags_with_attrs                           | 1.058    | 12.013     | 11.4x ← regex_old_implementation |
| 20k_tags_with_attrs                          | 13.185   | 6068.755   | 460.3x ← regex_old_implementation |
| 2k_multiline_tags                            | 0.815    | 10.819     | 13.3x ← regex_old_implementation |
| 20k_multiline_tags                           | 8.939    | 4231.768   | 473.4x ← regex_old_implementation |
| 1k_comments                                  | 0.222    | 1.292      | 5.8x ← regex_old_implementation |
| 1k_comments_hiding_tags                      | 0.163    | 1.121      | 6.9x ← regex_old_implementation |
| 2k_mixed                                     | 0.278    | 2.392      | 8.6x ← regex_old_implementation |
| 10k_mixed                                    | 1.400    | 50.959     | 36.4x ← regex_old_implementation |
| qweb_shop_200_products                       | 0.907    | 7.880      | 8.7x ← regex_old_implementation |
| qweb_shop_1000_products                      | 4.296    | 194.647    | 45.3x ← regex_old_implementation |


This PR is needed because requirements.txt in Odoo specifies the following dependency:
`MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble)`

This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe.

opw-5999688

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

Forward-Port-Of: odoo/odoo#268580
Forward-Port-Of: odoo/odoo#257889

When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db.

**Steps to reproduce**

* In settings activate:
  - Lots & Serial Numbers
  - Units of Measure & Packagings
  - Storage Locations
  - Barcode Scanner : GS1 nomenclature
* Create a Product tracked by lot with
  - barcode: 00001234567895
* Add on hand quantity:
  - 100 kg in lot : 10002002303-4
  - 100 kg in lot : 11002002303-4
* Go to barcode>Operation>Internal Transfer>New
* Scan 02000012345678951010002002303-4#3100000100 meaning:
  - 02 following 14 characters are the product barcode
  - 10 following characters are the lot number
  - "#" separator
  - 3100: means the units are kilograms, 
  - 00100 means 100 units. 

-> if you check with the edit button the lot was not found (if you click on validate it will trigger an UserError for missing lot)

**Observation**

When scanning the GS1 barcode it will call onBarcodeSubmitted->onBarcodeScanned where we will execute processBarcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/components/main.js#L387 Where we will deconstruct the barcode into his component en retrieve from the db the relevant data: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/models/barcode_model.js#L709-L717

- First the barcode is parsed, identifiers are erased and each section is separated, the variable with our lot number only has the lot number in it, the identifier (10) is not included, BarcodeObject.forBarcode(bc) -> new BarcodeObject -> parser.parse_barcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/barcode_object.js#L14
- Check if the data is in the cache, if not, set it to retrieve after
- Retrieve missing data getMissingRecords : https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/lazy_barcode_cache.js#L349 From here we will get a call to get_specific_barcode_data for each element: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L176 In the case of the stock.lot since it has a symbol and it's not only digit it will skip the gs1 nomenclature domain converter (it will not become 'ilike' and stay with 'in'): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L182-L197 We will do the search:
https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L205 during which we will retrieve specific query from the stock.lot module : https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/odoo/orm/models.py#L1408 Where, since it's a GS1 nomenclature, we will preprocess the agrs: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/models/stock_lot.py#L14 
-> Since our barcode start with a 10, it will erase it, which lead to a miss in the search.


It will also avoid further searches since we avoid multiple search on the same elements (added in missingBarcodeKeyCache in getMissingRecords). https://github.com/odoo/enterprise/blob/c6d18a7a92092ffdf96f4569a70e95bdc276441c/stock_barcode/static/src/lazy_barcode_cache.js#L294-L298

opw-6207120

Forward-Port-Of: odoo/enterprise#118828

**Steps to reproduce:**
- Create a database in version 19.0 and install Point of Sale.
- Create a sequence with a prefix or suffix using placeholders like %(year)s.
- Assign this sequence to a POS configuration.
- Create a new POS order and confirm payment.

**Issue:**
- POS order `sequence_number` must be an integer, but when using dynamic prefixes/suffixes (e.g., %(year)s), `_next()` returns values like `POS/2026/` while the configured prefix remains `%(year)s`.
- Due to this mismatch, [`_update_sequence_number`](https://github.com/odoo/odoo/blob/ab6cfabf0086afced2d035eb2207a0acab655540/addons/point_of_sale/models/pos_order.py#L561) fails to correctly remove the prefix/suffix.
- The root cause is that placeholders such as `%(year)s` are not interpolated before applying prefix/suffix removal logic, causing string mismatch and failure in extracting the numeric part.<img width="1920" height="959" alt="image" src="https://github.com/user-attachments/assets/d331fb7a-3c0f-4e34-a33e-6ec906be77bb" />

**Solution:**
- Interpolate prefix and suffix before removing them from the generated sequence.
- Convert placeholders like %(year)s into actual values (e.g., 2026).
- Then apply prefix/suffix removal logic.

opw-6150204

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

Forward-Port-Of: odoo/odoo#262427

The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities.  `_run_fifo_get_stack()` doesn't include the child companies in the `moves_domain`, so it is unable to create a FIFO stack for moves from a child. This leaves extra quantity unaccounted for, which defaults to the standard_price.

**Video of the bug:**
https://drive.google.com/file/d/11PIfNAIb_Yyo4A-3R0CRF0NV6_HE6EwF/view

**Issue:**
When multiple companies are selected, the displayed quantity on hand for a product is calculated as the sum of all selected companies. However, the moves domain only looks at the main selected company instead of all selected companies, leading to an incorrectly calculated standard price when using FIFO. This is more apparent on lot-valuated products because the lot standard price is recalculated every time the field is accessed.

**Reproduction steps:**
- Have a main company
- Create a branch company
- Create a product, configure it as FIFO on both the main company and branch company 
- Let the product be tracked by lots and set to `Valuation by Lot` (for demonstrative purposes)
- On the main company, set the product cost to $15 (for demonstrative purposes)
- Go to only the branch company, make a purchase for one unit of the FIFO product at $100 (make a warehouse for delivery) , validate the receipt
- Go to the lot -> When logged in to only the branch company, quantity is 1 and cost is $100 (correct). When logged in to both the main and branch company and viewing from the main company, quantity is 1 and cost is $15 (incorrect)

**Fix:** 
Allow `_run_fifo_get_stack()` to see the moves from all companies in the environment instead of just the main company

Related ticket: opw-6064126

Forward-Port-Of: odoo/odoo#270201
Forward-Port-Of: odoo/odoo#258199

In Hungary, we are already sending invoices to NAV(hungarian tax authority).
Now this module `l10n_hu_edi_receive` provides functionality of receiving vendor
bills through its API and also adds XML importer for Hungarian localization.

A button `Sync with NAV` is added in vendor bills list view, which opens a
wizard where you can select time period and all bills uploaded between that time
are fetched from NAV's API.

Also directly uploading XML is also supported in the format NAV supports.

Flow:-
- After selection of time range, we call `queryInvoiceDigest` endpoint with that
range and it returns a list of digests(consider each digest as separate invoice)
but this digests contains only meta data not all details.
- Now for each digest we call `queryInvoiceData` endpoint which returns xml
response with `QueryInvoiceDataResponse` as root node. This xml contains some
meta data and `InvoiceData` node which has a base64 string, when we decode that
string we get an xml with `InvoiceData` as root node and this xml contains all
details of the invoice, we parse both these details and create bills and refunds.

Also xml importer supports any of the `InvoiceData` or `QueryInvoiceDataResponse`
xml.

NAV Documentation: https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf

task-5237910

Forward-Port-Of: odoo/odoo#240919

**Steps to reproduce:**
* Install the Croatian e-invoicing module (**l10n_hr_edi**).
* Set up a Croatian company and a Croatian customer partner (with OIB and VAT configured).
* Create a customer invoice and post it.
* Create a credit note from that invoice via **Credit Note** button.
* On the credit note, change **Business Process Type** from `P9` to `P10: Issuing a corrective invoice`.
* Save the credit note.

**Observed behavior:**
* Saving fails with: "Business Process Type P9 can only be used with credit notes and vice versa."
* The error occurs even though P10 is a valid process type for credit notes according to the Croatian tax authority specification.

**Cause:**
* The `_check_l10n_hr_process_type` constraint used an XOR-style boolean check: `(process_type == 'P9') == (move_type != 'out_refund')`.
* This enforced an exclusive P9 ↔ out_refund mapping, making P9 the **only** allowed process type for credit notes and blocking P10 entirely.
* Per the Croatian tax authority specification, P10 (corrective invoice) is explicitly valid for credit notes: full cancellations report negative quantities/amounts, and partial corrections may report either positive or negative values.

**Fix:**
* Replace the XOR constraint with two independent, clearly-scoped rules:
  - P9 may only be used on credit notes (`out_refund`).
  - Credit notes must use either P9 or P10.
* Add P10 UBL type code mapping in `_ubl_add_credit_note_type_code_node()`: P10 credit notes now emit `CreditNoteTypeCode 384` (Corrected Invoice, UNTDID 1001) instead of falling through to the default 381.

opw-6128955

- Official Croatian Information Intermediary: https://portal.moj-eracun.hr/blog/kako-stornirati-eracun/
- Croatian Tax Authority (FAQ on fiscalization and e-invoicing): https://porezna-uprava.gov.hr/UserDocsImages/Fiskalizacija/Fiskalizacija_eRacun/Pitanja%20i%20odgovori%20vezani%20uz%20Zakon%20o%20fiskalizaciji.pdf

Forward-Port-Of: odoo/odoo#266288

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/f29ad892a2 [REL] 19.2.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5f301282cd [FIX] viewport: fix viewport jump with frozen pane [Task: 6292764](https://www.odoo.com/odoo/2328/tasks/6292764)
https://github.com/odoo/o-spreadsheet/commit/55308a5492 [FIX] composer_tokenizer: fix argument separator in formulas [Task: 6303210](https://www.odoo.com/odoo/2328/tasks/6303210)
https://github.com/odoo/o-spreadsheet/commit/683ed8df8b [FIX] Find and replace : selection after an UPDATE_CELL [Task: 4818132](https://www.odoo.com/odoo/2328/tasks/4818132)
https://github.com/odoo/o-spreadsheet/commit/5c1c720879 [FIX] rolldown: Fix cjs file extension [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/ec12e30dfd [IMP] node: add script to run the model in node [Task: 6088515](https://www.odoo.com/odoo/2328/tasks/6088515)
https://github.com/odoo/o-spreadsheet/commit/95c32d163e [FIX] package.json: Update Node.js and npm engine requirements [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/85381e6ae8 [FIX] carousel: custom color don't use carousels [Task: 6263128](https://www.odoo.com/odoo/2328/tasks/6263128)
https://github.com/odoo/o-spreadsheet/commit/20bfea982c [FIX] table: correctly insert table on static pivots [Task: 6204984](https://www.odoo.com/odoo/2328/tasks/6204984)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

`*` = `ewaybill_Stock, sale_stock, purchase_stock`

**Steps to reproduce:**
* Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`.
* Set the Default Tax Price Setting to "Tax Included".
* Create a Sales Order (e.g. unit price 300, qty 600, 18% GST) and confirm the Delivery Challan/Delivery Order.
* Generate an E-Way Bill from the Delivery Challan.

**Observed behavior:**
* The Taxable Amount and Total Invoice Amount are displayed incorrectly in the generated E-Way Bill, including both the printed document and the JSON.
* The `ewaybill_price_unit` shows the tax-excluded price (e.g. 254.24) instead of the original tax-included price (300), leading to a double tax exclusion when `compute_all` processes it.

**Cause:**
* `_l10n_in_get_product_price_unit` in both `l10n_in_sale_stock` and `l10n_in_purchase_stock` unconditionally used `price_subtotal / qty` to compute the E-Way Bill price unit. `price_subtotal` is always tax-excluded, so for tax-included prices, the tax was already stripped.
* `_l10n_in_tax_details_by_stock_move` then passed this already tax-excluded price to `compute_all` with taxes that have `price_include=True`, causing `compute_all` to strip the tax a second time (e.g. 254.24 / 1.18 = 215.46 instead of the correct 254.24).

**Fix:**
* Check whether any of the line's taxes have `price_include` set. If so, use `price_total / qty` (which preserves the tax-included price) so that `compute_all` can correctly extract the tax. Otherwise, continue using `price_subtotal / qty` as before.

opw-6273101

Forward-Port-Of: odoo/odoo#271492
Forward-Port-Of: odoo/odoo#268504

Starting version 2.1.4 of markupsafe, they decided to adapt the `striptags` function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex.

A problem has been spotted with qweb templates that used `striptags` with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster. In fact, the PR introducing this change in Markupsafe, made these claims with no benchmarks whatsoever: https://github.com/pallets/markupsafe/pull/413/changes 

The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better for varying input size.

The benchmark cases below are in the form `<case_description>_<number_of_tags>`. We can see that in the cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex. Apart from that, in the case of an unclosed tag, the regex implementation is also slower because it still needs to scan the entire line. However, in that case the time taken is a handful of milliseconds, so it's not really a performance regression there either.

Apart from that, the old implementation is consistently much more performant, for both small and large inputs.

Benchmarks:

| Case                                      | Regex ms | Current ms | Speedup |
|----------------------------------------------|----------|------------|---------|
| plain_text_50k_words                         | 3.020    | 2.627      | 0.9x ← current_implementation |
| unclosed_tag_then_50kb_text                  | 0.367    | 0.032      | 0.1x ← current_implementation |
| unclosed_tag_then_500kb_text                 | 3.787    | 0.273      | 0.1x ← current_implementation |
| multiple_unclosed_open_tags_then_50kb_text   | 18.912   | 0.371      | 0.0x ← current_implementation |
| multiple_unclosed_open_tags_then_500kb_text  | 189.007  | 8.209      | 0.0x ← current_implementation |
| unclosed_comment_then_500kb_text             | 7.276    | 0.412      | 0.1x ← current_implementation |
| 5k_small_tags                                | 0.986    | 22.096     | 22.4x ← regex_old_implementation |
| 20k_small_tags                               | 4.125    | 492.186    | 119.3x ← regex_old_implementation |
| 50k_small_tags                               | 12.658   | 5499.602   | 434.5x ← regex_old_implementation |
| 1k_nested_divs                               | 0.155    | 0.923      | 5.9x ← regex_old_implementation |
| 10k_nested_divs                              | 1.648    | 48.410     | 29.4x ← regex_old_implementation |
| 2k_tags_with_attrs                           | 1.058    | 12.013     | 11.4x ← regex_old_implementation |
| 20k_tags_with_attrs                          | 13.185   | 6068.755   | 460.3x ← regex_old_implementation |
| 2k_multiline_tags                            | 0.815    | 10.819     | 13.3x ← regex_old_implementation |
| 20k_multiline_tags                           | 8.939    | 4231.768   | 473.4x ← regex_old_implementation |
| 1k_comments                                  | 0.222    | 1.292      | 5.8x ← regex_old_implementation |
| 1k_comments_hiding_tags                      | 0.163    | 1.121      | 6.9x ← regex_old_implementation |
| 2k_mixed                                     | 0.278    | 2.392      | 8.6x ← regex_old_implementation |
| 10k_mixed                                    | 1.400    | 50.959     | 36.4x ← regex_old_implementation |
| qweb_shop_200_products                       | 0.907    | 7.880      | 8.7x ← regex_old_implementation |
| qweb_shop_1000_products                      | 4.296    | 194.647    | 45.3x ← regex_old_implementation |


This PR is needed because requirements.txt in Odoo specifies the following dependency:
`MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble)`

This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe.

opw-5999688

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

Forward-Port-Of: odoo/odoo#268580
Forward-Port-Of: odoo/odoo#257889

When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db.

**Steps to reproduce**

* In settings activate:
  - Lots & Serial Numbers
  - Units of Measure & Packagings
  - Storage Locations
  - Barcode Scanner : GS1 nomenclature
* Create a Product tracked by lot with
  - barcode: 00001234567895
* Add on hand quantity:
  - 100 kg in lot : 10002002303-4
  - 100 kg in lot : 11002002303-4
* Go to barcode>Operation>Internal Transfer>New
* Scan 02000012345678951010002002303-4#3100000100 meaning:
  - 02 following 14 characters are the product barcode
  - 10 following characters are the lot number
  - "#" separator
  - 3100: means the units are kilograms, 
  - 00100 means 100 units. 

-> if you check with the edit button the lot was not found (if you click on validate it will trigger an UserError for missing lot)

**Observation**

When scanning the GS1 barcode it will call onBarcodeSubmitted->onBarcodeScanned where we will execute processBarcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/components/main.js#L387 Where we will deconstruct the barcode into his component en retrieve from the db the relevant data: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/models/barcode_model.js#L709-L717

- First the barcode is parsed, identifiers are erased and each section is separated, the variable with our lot number only has the lot number in it, the identifier (10) is not included, BarcodeObject.forBarcode(bc) -> new BarcodeObject -> parser.parse_barcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/barcode_object.js#L14
- Check if the data is in the cache, if not, set it to retrieve after
- Retrieve missing data getMissingRecords : https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/lazy_barcode_cache.js#L349 From here we will get a call to get_specific_barcode_data for each element: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L176 In the case of the stock.lot since it has a symbol and it's not only digit it will skip the gs1 nomenclature domain converter (it will not become 'ilike' and stay with 'in'): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L182-L197 We will do the search:
https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L205 during which we will retrieve specific query from the stock.lot module : https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/odoo/orm/models.py#L1408 Where, since it's a GS1 nomenclature, we will preprocess the agrs: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/models/stock_lot.py#L14 
-> Since our barcode start with a 10, it will erase it, which lead to a miss in the search.


It will also avoid further searches since we avoid multiple search on the same elements (added in missingBarcodeKeyCache in getMissingRecords). https://github.com/odoo/enterprise/blob/c6d18a7a92092ffdf96f4569a70e95bdc276441c/stock_barcode/static/src/lazy_barcode_cache.js#L294-L298

opw-6207120

Forward-Port-Of: odoo/enterprise#118828

**Steps to reproduce:**
- Create a database in version 19.0 and install Point of Sale.
- Create a sequence with a prefix or suffix using placeholders like %(year)s.
- Assign this sequence to a POS configuration.
- Create a new POS order and confirm payment.

**Issue:**
- POS order `sequence_number` must be an integer, but when using dynamic prefixes/suffixes (e.g., %(year)s), `_next()` returns values like `POS/2026/` while the configured prefix remains `%(year)s`.
- Due to this mismatch, [`_update_sequence_number`](https://github.com/odoo/odoo/blob/ab6cfabf0086afced2d035eb2207a0acab655540/addons/point_of_sale/models/pos_order.py#L561) fails to correctly remove the prefix/suffix.
- The root cause is that placeholders such as `%(year)s` are not interpolated before applying prefix/suffix removal logic, causing string mismatch and failure in extracting the numeric part.<img width="1920" height="959" alt="image" src="https://github.com/user-attachments/assets/d331fb7a-3c0f-4e34-a33e-6ec906be77bb" />

**Solution:**
- Interpolate prefix and suffix before removing them from the generated sequence.
- Convert placeholders like %(year)s into actual values (e.g., 2026).
- Then apply prefix/suffix removal logic.

opw-6150204

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

Forward-Port-Of: odoo/odoo#262427

Steps to reproduce:

- Create a storable product with a BoM, routes MTO + Manufacturing,
  costing method FIFO + Perpetual (at invoicing)
- Confirm a sale order for 1 unit → a manufacturing order is created
- Set a Delivery Date on the SO (Other Info tab)
- Increase the SO line qty to 2
- Validate the MO → traceback on finished_move.ensure_one()

Problem:
When a delivery date is set on the SO, it propagates to the MO's
finished move via date_deadline. However, `production.date_deadline\
was not updated (guarded by `if not production.date_deadline`) because
the MO already had a deadline set at planning time:
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L476

When the SO qty then increases, change_production_qty copies the
finished move to create a delta move. That delta move receives
production.date_deadline (the stale planning date) instead of the
delivery date, so the two finished moves end up with different
deadlines and cannot be merged:

https://github.com/odoo/odoo/blob/19.0/addons/mrp/wizard/change_production_qty.py#L43

Solution
- always update production.date_deadline from its finished moves
- link the new delivery move to the finished move after the qty
  wizard runs so it gets reserved after MO validation

opw-6273076

Forward-Port-Of: odoo/odoo#269405

Currently, an error occurs when a user sorts tasks by Planned Date.

**Steps to reproduce:**
 - Install the `project_enterprise` module with demo data.
 - Go to Projects in the portal (`/my/projects`), open any `project`, and sort the 
   tasks by `Planned Date`.

KeyError: 'order'

After a [recent change], the sort order is retrieved from searchbar sortings. When sorting by 
Planned Date, it attempts to access the order key from the corresponding sorting configuration [1]. 
However, the planned_date_begin entry does not define an order key [2], which raises 
error when it tries to access order.

This commit ensures that the order key is added with its value for planned_date_begin in 
searchbar sorting.

[recent change]: https://github.com/odoo/odoo/commit/8be5dacf9fbfe8c23b04c876994bea2ce7cbb89a

[1]: https://github.com/odoo/odoo/blob/2ae9b57b86cd0bc4816ff8ec207564631baa8ad6/addons/project/controllers/portal.py#L424

[2]- https://github.com/odoo/enterprise/blob/9dd3a9b2c09a6d23a3f71d3e531edd6d78b30277/project_enterprise/controllers/portal.py#L8-L11

sentry-7556050938

Forward-Port-Of: odoo/enterprise#121141

In Hungary, we are already sending invoices to NAV(hungarian tax authority).
Now this module `l10n_hu_edi_receive` provides functionality of receiving vendor
bills through its API and also adds XML importer for Hungarian localization.

A button `Sync with NAV` is added in vendor bills list view, which opens a
wizard where you can select time period and all bills uploaded between that time
are fetched from NAV's API.

Also directly uploading XML is also supported in the format NAV supports.

Flow:-
- After selection of time range, we call `queryInvoiceDigest` endpoint with that
range and it returns a list of digests(consider each digest as separate invoice)
but this digests contains only meta data not all details.
- Now for each digest we call `queryInvoiceData` endpoint which returns xml
response with `QueryInvoiceDataResponse` as root node. This xml contains some
meta data and `InvoiceData` node which has a base64 string, when we decode that
string we get an xml with `InvoiceData` as root node and this xml contains all
details of the invoice, we parse both these details and create bills and refunds.

Also xml importer supports any of the `InvoiceData` or `QueryInvoiceDataResponse`
xml.

NAV Documentation: https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf

task-5237910

Forward-Port-Of: odoo/odoo#240919

**Steps to reproduce:**
* Install the Croatian e-invoicing module (**l10n_hr_edi**).
* Set up a Croatian company and a Croatian customer partner (with OIB and VAT configured).
* Create a customer invoice and post it.
* Create a credit note from that invoice via **Credit Note** button.
* On the credit note, change **Business Process Type** from `P9` to `P10: Issuing a corrective invoice`.
* Save the credit note.

**Observed behavior:**
* Saving fails with: "Business Process Type P9 can only be used with credit notes and vice versa."
* The error occurs even though P10 is a valid process type for credit notes according to the Croatian tax authority specification.

**Cause:**
* The `_check_l10n_hr_process_type` constraint used an XOR-style boolean check: `(process_type == 'P9') == (move_type != 'out_refund')`.
* This enforced an exclusive P9 ↔ out_refund mapping, making P9 the **only** allowed process type for credit notes and blocking P10 entirely.
* Per the Croatian tax authority specification, P10 (corrective invoice) is explicitly valid for credit notes: full cancellations report negative quantities/amounts, and partial corrections may report either positive or negative values.

**Fix:**
* Replace the XOR constraint with two independent, clearly-scoped rules:
  - P9 may only be used on credit notes (`out_refund`).
  - Credit notes must use either P9 or P10.
* Add P10 UBL type code mapping in `_ubl_add_credit_note_type_code_node()`: P10 credit notes now emit `CreditNoteTypeCode 384` (Corrected Invoice, UNTDID 1001) instead of falling through to the default 381.

opw-6128955

- Official Croatian Information Intermediary: https://portal.moj-eracun.hr/blog/kako-stornirati-eracun/
- Croatian Tax Authority (FAQ on fiscalization and e-invoicing): https://porezna-uprava.gov.hr/UserDocsImages/Fiskalizacija/Fiskalizacija_eRacun/Pitanja%20i%20odgovori%20vezani%20uz%20Zakon%20o%20fiskalizaciji.pdf

Forward-Port-Of: odoo/odoo#266288

**Problem:**
When creating a new employee, the future timesheets due to public holidays are computed. If the number of public holidays is large (i.e. if the user creates them for each year, several years in the future), then it takes excessively long and the action may not complete.

**Cause:**
The pytz method `localize` and comparing times with non-static timezones is done repeatedly and unnecessarily which becomes costly with more records.

**Solution:**
Only localize the time when absolutely necessary (determining the date of the leave in the calendar timezone).

**Performance Stats:**
|Record count|Time before|Queries before|Time after|Queries after|
|------------|-----------|--------------|----------|-------------|
|100         |3.1s       |393           |0.8s      |117          |
|1,000       |22.3s      |2,090         |1.5s      |183          |
|10,000      |Timeout    |N/A           |6.7s      |541          |

opw-6087422

Forward-Port-Of: odoo/odoo#269876
Forward-Port-Of: odoo/odoo#263953

`*` = `ewaybill_Stock, sale_stock, purchase_stock`

**Steps to reproduce:**
* Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`.
* Set the Default Tax Price Setting to "Tax Included".
* Create a Sales Order (e.g. unit price 300, qty 600, 18% GST) and confirm the Delivery Challan/Delivery Order.
* Generate an E-Way Bill from the Delivery Challan.

**Observed behavior:**
* The Taxable Amount and Total Invoice Amount are displayed incorrectly in the generated E-Way Bill, including both the printed document and the JSON.
* The `ewaybill_price_unit` shows the tax-excluded price (e.g. 254.24) instead of the original tax-included price (300), leading to a double tax exclusion when `compute_all` processes it.

**Cause:**
* `_l10n_in_get_product_price_unit` in both `l10n_in_sale_stock` and `l10n_in_purchase_stock` unconditionally used `price_subtotal / qty` to compute the E-Way Bill price unit. `price_subtotal` is always tax-excluded, so for tax-included prices, the tax was already stripped.
* `_l10n_in_tax_details_by_stock_move` then passed this already tax-excluded price to `compute_all` with taxes that have `price_include=True`, causing `compute_all` to strip the tax a second time (e.g. 254.24 / 1.18 = 215.46 instead of the correct 254.24).

**Fix:**
* Check whether any of the line's taxes have `price_include` set. If so, use `price_total / qty` (which preserves the tax-included price) so that `compute_all` can correctly extract the tax. Otherwise, continue using `price_subtotal / qty` as before.

opw-6273101

Forward-Port-Of: odoo/odoo#271492
Forward-Port-Of: odoo/odoo#268504

**Steps to reproduce:**
- Create a database in version 19.0 and install Point of Sale.
- Create a sequence with a prefix or suffix using placeholders like %(year)s.
- Assign this sequence to a POS configuration.
- Create a new POS order and confirm payment.

**Issue:**
- POS order `sequence_number` must be an integer, but when using dynamic prefixes/suffixes (e.g., %(year)s), `_next()` returns values like `POS/2026/` while the configured prefix remains `%(year)s`.
- Due to this mismatch, [`_update_sequence_number`](https://github.com/odoo/odoo/blob/ab6cfabf0086afced2d035eb2207a0acab655540/addons/point_of_sale/models/pos_order.py#L561) fails to correctly remove the prefix/suffix.
- The root cause is that placeholders such as `%(year)s` are not interpolated before applying prefix/suffix removal logic, causing string mismatch and failure in extracting the numeric part.<img width="1920" height="959" alt="image" src="https://github.com/user-attachments/assets/d331fb7a-3c0f-4e34-a33e-6ec906be77bb" />

**Solution:**
- Interpolate prefix and suffix before removing them from the generated sequence.
- Convert placeholders like %(year)s into actual values (e.g., 2026).
- Then apply prefix/suffix removal logic.

opw-6150204

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

Forward-Port-Of: odoo/odoo#262427

Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

Steps to produce:
---
- Install the `Rental and eCommerce `modules.
- Create a rental product and configure a rental price for it.
- Add an optional product from the Sales tab.
- Publish the product on the website.
- Open the product page on the website and click` Add to Cart`.

Issue:
---
- In the product configurator, the rental price is displayed without the `/` separator between the price and the rental duration period.

Cause:
---
- The string used to generate the rental duration label does not include the `/` separator.

Fix:
---
- Add the missing `/` separator to the rental duration label so that rental prices are displayed correctly.

Before:
---
<img width="974" height="185" alt="image" src="https://github.com/user-attachments/assets/64a88a60-bcc0-4657-97fd-584da57d0aff" />

After:
---
<img width="967" height="188" alt="image" src="https://github.com/user-attachments/assets/b4d50019-1db4-4817-a8ce-446cc3c55df4" />


opw-6293015

Forward-Port-Of: odoo/enterprise#120223

Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

In Hungary, we are already sending invoices to NAV(hungarian tax authority).
Now this module `l10n_hu_edi_receive` provides functionality of receiving vendor
bills through its API and also adds XML importer for Hungarian localization.

A button `Sync with NAV` is added in vendor bills list view, which opens a
wizard where you can select time period and all bills uploaded between that time
are fetched from NAV's API.

Also directly uploading XML is also supported in the format NAV supports.

Flow:-
- After selection of time range, we call `queryInvoiceDigest` endpoint with that
range and it returns a list of digests(consider each digest as separate invoice)
but this digests contains only meta data not all details.
- Now for each digest we call `queryInvoiceData` endpoint which returns xml
response with `QueryInvoiceDataResponse` as root node. This xml contains some
meta data and `InvoiceData` node which has a base64 string, when we decode that
string we get an xml with `InvoiceData` as root node and this xml contains all
details of the invoice, we parse both these details and create bills and refunds.

Also xml importer supports any of the `InvoiceData` or `QueryInvoiceDataResponse`
xml.

NAV Documentation: https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf

task-5237910

Forward-Port-Of: odoo/odoo#240919

Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf)
and deduplicating overlaps

* Current Situation: Currently real duration is total duration of each
time tracking which
is not consistent with the time that use to calculate the cost for
valuation , see https://github.com/odoo/odoo/pull/205154 .The real
duration of a work order was incorrectly summing all time tracking
entries regardless of their loss type, and using simple addition which
double-counts overlapping intervals.

* Solution:
- Filter time entries to only 'productive' and 'performance' loss types,
  excluding 'availability' and 'quality' as they represent
downtime/blocking
  time, not actual work duration.
- Pool all productive and performance entries into a single Intervals
call
  so that overlaps across both types are merged in one pass.

Note: the enterprise17 implementation groups time entries by loss_type
into
separate buckets before calling Intervals, which means overlaps between
'productive' and 'performance' entries are not merged and get
double-counted.
Pooling both types together before the Intervals call avoids this.

* This also fix:
- Fix _set_duration to ensure newly created time entries start after the
  latest existing entry's end date. Without this, calling _set_duration
  twice in quick succession (e.g. in tests) produces two entries with
  overlapping timestamps, which Intervals correctly merges into one,
  causing the computed duration to be half the expected value.




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

Forward-Port-Of: odoo/odoo#248381

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#121468
Forward-Port-Of: odoo/enterprise#120967

## [IMP] databases: SSO smooth connection and setup

The aim of this commit is to allow databases_user to be directly connected to
any remote SaaS database to which they have access.
When they click the "connect" button, they will bypass the login screen and be
authenticated automatically.

To achieve this, when a user tries to connect to an accessible SaaS database, we
quickly write their `oauth_uid` to that remote database right before the
connection is initiated.

Before this commit:
A user that was created in the remote db using the create user feature from the
databases module wouldn't get automatically authenticated through the Odoo
OAuth SSO feature.

After this commit:
Users attempting to connect to a SaaS database will be directly connected if the
settings was activated.

task-id: 6071808

## TODO:
- [x] check if we always have oauth_uid for saas db
- [x] think about making the oauth module autoinstall (make a bridge module? or overkill?)
    - We can avoid that and have everything work in place directly, avoiding an inheritance nightmare at installation time. 
- [x] handle cases where it isn't there on both the remote db and the managing one
- [x] write some tests to ensure the code is free from traceback
- [x] add a feature allowing to:
    - [x] add it to all server on which the user has access
    - [x] add it to a specific server (may require the db list view on `res.users`
    - [x] remove the previous and do everything when the user click on "connect"
- [x] would be better to put the code in a new module with auto install => people get auto-install + no "hacky" code.
    - The "hacky" code is not so hacky and with that we can directly advertise the installation of `auth_oauth` in an action
    - [x] add a config in the settings

Forward-Port-Of: odoo/enterprise#112369

In POS, the Preparation Time report groups average preparation durations by hour. Those hour buckets were always computed with the timezone of the user who ran the module upgrade (OdooBot / superuser), not the timezone of the user viewing the report. Changing the user, company, or browser timezone had no effect on the graph until the module was upgraded again.

Steps to reproduce:
-------------------
* Configure a Preparation Display and create POS orders with measured preparation times.
* Open Point of Sale → Reporting → Preparation Time.
* Note the hour bucket used for the orders.
* Change your user timezone in Preferences and reload the report.

> Observation:
The hour buckets stay the same. Before the fix, they only changed after upgrading `pos_enterprise`, because the timezone was embedded in the SQL view created during `init()` as superuser.

Why the fix:
------------
Replace the static PostgreSQL view with a dynamic `_table_query` so `order_hour` is computed with the current user's timezone on each report read. `init()` now only drops the legacy view instead of recreating it with a frozen timezone.

opw-6220248

Forward-Port-Of: odoo/enterprise#118365

Replaced `useLayoutEffect` with `useEffect` (from `@odoo/owl`) because `useLayoutEffect` is deprecated in OWL3.

`useEffect` in OWL3 has no dependency array — it auto-subscribes to any reactive values accessed inside the callback. The effect reads `this.props.threadId` and `this.state.thread` access-right fields directly, so OWL3 tracks those dependencies automatically. This restores the original logic: detecting thread changes, resolving the `chatterThreadReady` promise, and updating toolbar visibility without requiring an explicit dep list.

The `useLayoutEffect` refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- TestHelpdeskKnowledgeCrossModuleFeatures.test_helpdesk_pick_file_as_attachment_from_knowledge
- TestHelpdeskKnowledgeCrossModuleFeatures.test_helpdesk_pick_file_as_message_attachment_from_knowledge
- TestHelpdeskKnowledgeCrossModuleFeatures.test_helpdesk_pick_template_as_message_from_knowledge
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2596754/build/114855772

Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

In Hungary, we are already sending invoices to NAV(hungarian tax authority).
Now this module `l10n_hu_edi_receive` provides functionality of receiving vendor
bills through its API and also adds XML importer for Hungarian localization.

A button `Sync with NAV` is added in vendor bills list view, which opens a
wizard where you can select time period and all bills uploaded between that time
are fetched from NAV's API.

Also directly uploading XML is also supported in the format NAV supports.

Flow:-
- After selection of time range, we call `queryInvoiceDigest` endpoint with that
range and it returns a list of digests(consider each digest as separate invoice)
but this digests contains only meta data not all details.
- Now for each digest we call `queryInvoiceData` endpoint which returns xml
response with `QueryInvoiceDataResponse` as root node. This xml contains some
meta data and `InvoiceData` node which has a base64 string, when we decode that
string we get an xml with `InvoiceData` as root node and this xml contains all
details of the invoice, we parse both these details and create bills and refunds.

Also xml importer supports any of the `InvoiceData` or `QueryInvoiceDataResponse`
xml.

NAV Documentation: https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf

task-5237910