**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

**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

Steps to reproduce:
-------------------------------------------------
1. Install `planning_field_service_worksheet` module with demo data
2. Go to Worksheet Templates
3. Open First Worksheet > Observe `+ Add Property` button at bottom
4. From the Navigation button, move to the next Worksheet Template
5. Come back to First Template using the same navigation button

Observation:
-------------------------------------------------
The '+ Add Property' button and property edit buttons disappear after navigating away from and back to the first worksheet template.

Issue:
-------------------------------------------------
`PropertiesDefinitionField.setup()` sets
`this.state.isInEditMode = this.definitionRecordId` only once during component initialization.
https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/fields/properties/properties_definition_field.js#L9-L12

When the user navigates via the pager, `FormController.onWillLoadRoot` resets `propertiesState.editable` to `false` and fires a `PROPERTY_FIELD:EDIT` bus event with `{ editable: false }`, which calls `setEditMode(false)` https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/form/form_controller.js#L407

After the new record loads, the parent's `useEffect` (which watches the definition record field) should restore edit mode, but it short-circuits when both `isInEditMode` and `editMode` are `false`
https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/fields/properties/properties_field.js#L115-L117

Since `setup()` doesn't re-run on record navigation and nothing else restores `isInEditMode`, it stays `false` permanently. This hides the parent template's 'Add Property' button
https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/fields/properties/properties_field.xml#L86-L90

Solution:
-------------------------------------------------
* Replace the one-time assignment in `setup()` with a `useRecordObserver` that sets `this.state.isInEditMode` whenever the record changes. This hook fires both on initial setup (via `onWillStart`) and on every record change (via `onWillUpdateProps`) ensuring `isInEditMode` is correctly restored after pager navigation

* Using `record.data.id` rather than `true` preserves the existing behavior of disabling edit mode for unsaved records (where `id` is `false/falsy`)

opw-6264361

**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

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

When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5 account.bank.statement.lines and use them to define the reconciliation model config. A matching is done on the payment_ref of the account.bank.statement.lines by finding the longest common substring in the reference.

### Current Implementation
The current algorithm does so by first generating all the possible substrings for all the payment_ref before doing the intersection between these sets and returning the max if `len(substring) >=10`. This is reasonable when the payment_ref follows either a SEPA communication national standard like the Belgian one or the Creditor Reference standard (ISO 11649). For transactions with large, unstructured communication with more than 100 chars, the method `_get_common_substrings` quickly overfill the memory, sometimes raising a MemoryErorr, and takes a significant amount of time. That's because the nested function `_generate_all_substrings` generates n*(n+1)/2 substrings, with n being the lenght of a payment_ref, called `label` in `generate_all_substrings`.

### Proposed Fix
This commit introduces another algorithm to find the largest common substring. It starts by taking the two smallest labels to find their substrings intersection. We know that for an arbitrary collection of labels, the intersection of their substrings sets A ∩ B ∩...∩ Z is included in the intersection of any two substrings sets. The underlying assumption of the first step is that for an arbitrary collection of labels the intersection of the substrings sets of the two smallest labels will be the smallest intersection of any given pair of substrings sets. This won't hold true everytime and using a metric such as label similarity instead of shortest string might be better. But on average this should be good enough and it's easier to implement + it removes the need of preprocessing the labels to compute the similarity.

The point of the new nested function `common_substrings` is to discard common substrings as we build them. Using the current `generate_all_substsrings` on either the smallest label or both smallest
labels would still generate and store a lot of substrings, especially for large labels. By yielding the common substrings as we find them, the memory footprint is vastly reduced.

Lastly, the next substring in the common_substrings iterable is only checked against the remaining labels if it's longer than the current match. This speeds up the whole process

### speedup

In a customer database with some account.bank.statement.line with payment_ref > 500 chars, setting a specific account (code 4970) on transactions goes from MemoryError to < 1Mb memory consumption.

Because of the memory consumption it was not possible to gather timing value on the current version. 
Testing the new algorithm in a shell and using as labels the 5 longest payment_ref in the customer database
(831, 831, 1117, 1178, 1300 chars), averaging to 2000 chars once normalised, the average time to execute `_get_common_substrings` is 900 ms ± 10.3 ms.

Forward-Port-Of: odoo/enterprise#118824

[[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

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

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

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

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

1. The `m160` and `m161` mutations for `sign_copy_sale` test didn't set the `l10n_be_short_signature` field on the order, so the `TicketScreen.print` override would fail the check and the `blackbox.signCopy` would not be called, causing the test to fail.
2. The `l10n_be_pos_blackbox_urban_piper` tests would crash on `undefined id` on the prep display path of `pos_enterprise`, where the data service will try to load up the prep display data, but it's not loaded in the test bundle. So I created a special setupEnv method for blackbox with urban piper which unpatches the prep display (same mechanism as pos_enterprise)
3. After removing the path for the tests, they would fail for the `expectGeneralProperties` step. By default it expects the `ticketMedium` to be `PAPER`, but there is no printer configured on the tests, so the actual medium is `DIGITAL`.
4. The tests expect the cost center to be `PLATFORM`. There was a patch on `InputGenerator`, which would return platform if the order has a `delivery_provider_id` set. But the patch never fired. I moved the patch directly on the order model, which is where the cost center value is computed.
5. The `test_l10n_be_pos_blackbox_sign_sale_backend_offline` test would endTour prematurely before the orders finished syncing, then check that all the orders are synced. I added an extra isSynced() step to ensure the orders are synced before ending the tour

Task-[6320705](https://www.odoo.com/odoo/1737/tasks/6320705)

### Steps to reproduce:
- Install "l10n_dk" and switch to Danish company
- Create an empty sale order
- Create a new expense
   - Category "Communication" for example
   - Total of 100 for example
   - Select "K-EU-V-DelvisFradrag" as a tax
   - Paid by company
   - Select the customer to reinvoice
- Click "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries"
- Go to the Journal Entry and see the Journal Items
- The tax is a 25% tax but the value in the journal entries is 20 (so 20%)

### Cause:
When called from the Expense app `_get_tax_details` is called with `special_mode == total_included` ([see](https://github.com/odoo/odoo/blob/467ab37703a44ca6cf57552715b75b087dc77d0d/addons/hr_expense/models/hr_expense.py#L549)). The special mode makes all taxes computed as if they were included taxes.

But taxes with negative lines should not be computed as included (as in 17.0). The code already handles that the base amount is not changed for these taxes ([see](https://github.com/odoo/odoo/blob/467ab37703a44ca6cf57552715b75b087dc77d0d/addons/account/models/account_tax.py#L1088-L1092)). But not the amount of the tax in question.

### Solution:
In `_eval_tax_amount_price_included`, if the tax has `has_negative_factor` to `True` then compute the tax as excluded.

opw-4532391