**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/odoo#235000

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/enterprise#101620

Issue before this commit:
=========================

The high-priority maintenance request count (todo_request_count_high_priority) 
was not calculated correctly.

Steps to Reproduce:
=========================
- Install the maintenance module.
- Create a maintenance request and set the Priority to High (3-starred) in the form view.
- Open the dashboard.
- Observe that the high-priority request count is not displayed.
- The count always remains 0, even when high-priority requests exist.

Cause of the issue:
=========================
In this [PR](https://github.com/odoo/odoo/pull/94866), the logic was mistakenly changed. 
The priority field is defined as a Selection field, but while computing the count, the comparison 
was done against an integer(3, not '3') instead of the actual string value. Since the stored 
value is '3' (string), the condition is always evaluated to False, resulting in a count of 0.

With This Commit:
=========================
Ensure that high-priority maintenance requests are correctly counted and displayed on 
the dashboard when they exist. This provides better visibility of critical requests and
helps users prioritise maintenance work effectively.

Forward-Port-Of: odoo/odoo#244987

**Steps to reproduce:**
- Install Accounting
- Go to Accounting dashboard

1) - On "Bank" journal card, select "Import File" option in dropdown menu
    - Upload a file containing a lot of statements (e.g. more than 170)
    - Test the import with "Test" button
2) - Open "Bank" journal
    - Select "Import records" in the cog menu
    - Upload a file containing a lot of statements (e.g. more than 170)
    - Test the import with "Test" button
3) - Open "Bank" journal
    - Click on "Upload" button
    - Upload a file containing a lot of statements (e.g. more than 170)
    - Test the import with "Test" button

**Issue:**
The issue happens when the test import fails.
Even if it was a test, all the records are created in the database.

**Cause:**
During a test import the records should not be reconciled after creation.
However, by default, "auto_statement_processing" property is True and trigger the reconciliation.
When an error is raised during the test import, a rollback is made on a previous savepoint.
But a commit can be done in "_cron_try_auto_reconcile_statement_lines" method, which results in the records being created for real.

**Solution:**
Set "auto_statement_processing" property to False for Test import.
For use case 1) and 2), we make sure that we follow the same flow than use case 3).

opw-5436937

Forward-Port-Of: odoo/enterprise#104954

### Issue:
When having a template with a company but no department, it's not selected by new appraisal.

### Steps to reproduce:
- Have an employee whose appraisal date is today.
- Have only one template, with the company of the employee but no department
- Run the cron "Appraisal: Run employee appraisal"
- Open the Appraisals app
- Click on the newly created appraisal
- It doesn't have the template

### Cause:
- In `_compute_appraisal_template()`, only the department of the appraisal is used to compute the template.
But `_create_new_appraisal()` doesn't include the department in `appraisal_values` to create the appraisal.
So `appraisal.department_id` is `False` and the template from the department is ignored. 

- Another issue is if the employee has no department, then the appraisal also has no department.
Then no template is selected by the search domain. 

### Solution:
- Include `department_id` in `appraisal_values`
- Modify the search domain to include the case where the appraisal has no department

opw-5477450

Forward-Port-Of: odoo/enterprise#104470

In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation.

Steps to reproduce:
- activate Ukrainian (or Polish) language
- Preview (i.e. the website view) of any appointment
- Change the preview into Ukrainian (or Polish)

Expected result:
Calendar month at top of calendar is shown in the nominative case:
e.g. January 2026 = січень 2026 (in Ukrainian)

Actual result:
Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January):
e.g. January 2026 = січня 2026 (in Ukrainian)

Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month

Note that for most languages this won't make a difference since there is usually only 1 way of writing a month.

opw-5474705

picture diff (for January 2026):

before fix:
<img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" />


after fix:
<img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" />

Forward-Port-Of: odoo/enterprise#104942

### Steps to reproduce:

- In the settings enable Lots and Serial Numbers and Multi-steps routes
- Create a storable product P Tracked by lots with an avco perpetual valuation cateory 
   and enable the valuation by Lot/Serial in its inventory tab
- Inventory > Configuration > Warehouse Management > Warehouses
- Create a new warehouse: WH2
- Create and confirm a PO for 10 units LOT001 for $20 in WH1
- Create and confirm a PO for 5 units LOT002 for $50 in WH2
- Inventory > Reporting > Stock
> The product total value is correctly set to 450 with a unit cost of $30
- Click on Warehouse 2 for the related report
#### > The total Value did not change and the product unit cost is set to $90

### Expected behavior:

The unit cost should be $50 and the total value should be 250$ for this warehouse.

#### Cause of the issue:

The total value of the product is computed in the `_compute_value`, which is supposed to rely on the contextual warehouse to determine the unit cost and total value of the product:
https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock_account/models/product.py#L139-L141 https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock_account/models/product.py#L152-L168 While `qty_valued` relies on this context key because of the `qty_available` which is it self context dependent: https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock/models/product.py#L147-L151 and is used in standard, AVCO, and FIFO valuation, it is not used for `lot_valuated` products:
https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock_account/models/product.py#L154-L155 https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock_account/models/product.py#L232-L237 https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock_account/models/stock_lot.py#L21-L40

### Solution:

There are several issues to be addressed here. To begin with, in order for the valuation to be warehouse-dependent, it is necessary for the `total_value` of the `stock.lot` model to be `warehouse_id` context-dependent and to rely on the qty_available of the lot in each warehouse, rather than the global internal lot.product_qty, which is not: https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock/models/stock_lot.py#L210-L215

Additionally, since it is possible for a lot to have a null `lot.product_qty` but have 10 units in WH1 and -10 units in WH2, it is necessary not to exclude lots with a null `product_qty` from the lot valuation (at least when the warehouse_id is in the context): https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock_account/models/product.py#L232-L237

Furthermore, the quantity used in _run_avco here is not correct (both cases are now covered by our tests):
https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock_account/models/product.py#L302-L312 To begin with, both conditions are incorrectly dependent on the contextual `warehouse_id` because of `qty_available`. They should not be, because `_run_avco` is supposed to provide a non-warehouse context-dependent value that is then proportionally re-evaluated via `qty_valued` in the `_compute_value`:
https://github.com/odoo/odoo/blob/944d7c8d5d6bf97cba71644b615e081e4fff6595/addons/stock_account/models/product.py#L165-L166 In addition, the first condition does not rely on the lot at all (and it should for lot-valuated products). And the scond one rely on the lot via the `lot.product_qty` which is incorrect as this qty is not dependent on the date (as it is just the sum of qty on quants. For uniformity, we therefore change both conditions to rely on `qty_available` with the contextual lot. Note that it would be equivalent to rely on the `lot.product_qty` if the lot if to_date is not provided.

Finally, for the `total_value` computation of each lot itself, we change the logic to follow the same behavior as for non-lot valuated products (but where we consider each specific lot similarly to a separate product). That is:
- If the qty_valued is null, its valuation should also be null.
- In AVCO and FIFO computations, we rely on the global value (full available quantity) and then weight it by the percentage present in stock.
- If the total available quantity is null, we return the `standard_price * qty_valued` and avoid unnecessary computations.

opw-5469786

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

Forward-Port-Of: odoo/odoo#244688

When printing many receipts quickly using a USB printer, this error was occasinally occuring:

```
WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status
ERROR   ? root: Could not set configuration: [Errno 16] Resource busy
```

This would cause `python-escpos` to be disabled and fallback to just CUPS printing.

The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways:
- IoT thread with `python-escpos` and CUPS try to access the printer at the same time.
- Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time).

Both of these scenarios should now prevented:
- Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it.
- We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time.

task-5490942

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

Forward-Port-Of: odoo/odoo#244370
Forward-Port-Of: odoo/odoo#244031

Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal

This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields: `(menus|views|reports)_by_module` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.

One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
  File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
    assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```

This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)

This fix will avoid any additional traceback like this one.

opw-5865316

Steps to reproduce:
===================
1. Enable the Cookies Bar in website settings.
2. Go to the website and enter Edit mode.
3. Select the Cookie Bar and change the button "I agree" style shape to "Default"  (this applies the `.btn-primary` class). & Save
4. Accept the cookies & refresh

-> The cookie bar appears again because the consent was not saved.

Cause:
======
The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup.

By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written.

Solution:
=========
Override the event to avoid side effects on hide.

opw-5484578

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

Forward-Port-Of: odoo/odoo#244875
Forward-Port-Of: odoo/odoo#243562

On the iot box we check the number of printers connected rarely to avoid spamming the network.
This leads to some situations where if a printer is disconnected it becomes unusable for the next 2 minutes or even more if it disconnects again just before the next get_devices call in the interface.
The printers are often not listed by cups for short time which currently leads to them being deleted from our list of connected devices on the iot box.

However in reality the printer reconnects faster than 2 minutes and often becomes available again within a couple of seconds.
Currently if you print something on it you will get an error when checking the job status but the job will still be queud and printed whenever it reconnects.
The user in pos can then press "retry" which will lead to a double printing.


This PR adds a counter for the printer disconnections and only removes the printer from our list if it wasn't detected 3 times in a row by cups.
Now since not deleted from cups the print job is queud and whenever the printer reconnects it's printed.
The user will not get an error anymore which will avoid double printing and the printer will remain available unless it's really disconnected

Forward-Port-Of: odoo/odoo#244759
Forward-Port-Of: odoo/odoo#244076

Currently, an error occurs when uploading `encrypted or incomplete` 
PDF files (missing EOF marker) while creating a quotation document 
header or footer.

**Steps to reproduce:**
- Install the `sale_pdf_quote_builder` module.
- Navigate to: Sales > Configuration > Headers/Footers.
- Upload encrypted file [1], or incomplete file [2].

**Error:**
`PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm`
`PyPDF2.errors.PdfReadError: EOF marker not found`

**Root cause:**
At [3], `_get_form_fields_from_pdf` and `_ensure_document_not_encrypted` directly 
call `pdf.PdfFileReader`, when it fails to read or decrypt the file, Python raises 
an error.

**Fix:**
This commit prevents errors when users upload unreadable or encrypted PDF files.

[1]:
https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing

[2]:
https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing

[3]:
https://github.com/odoo/odoo/blob/694f1d0fb03b56dd41a59eb676e56622634cc91b/addons/sale_pdf_quote_builder/utils.py#L11

sentry-6928220164
opw-5227601

Forward-Port-Of: odoo/odoo#245264
Forward-Port-Of: odoo/odoo#230712

Steps to Reproduce
 1. Create a database in Odoo 19.0 with the stock_account module installed.
 2. Enable Dropshipping from Inventory → Settings.
 3. Create a product with a category whose Cost Method is set to Average Cost (AVCO).
 4. Create a user with Inventory / User access rights only (no Inventory Administrator rights).
 5. Create a dropship order using the product and validate the picking.

```
You are not allowed to access 'Product Value' (product.value) records.

This operation is allowed for the following groups:
	- Inventory/Administrator

Contact your administrator to request access if necessary.
```

Issue:-
During picking validation, moves are getting [done](https://github.com/odoo/odoo/blame/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock/models/stock_picking.py#L1265) if move is is_dropship enable which lead to [update_standard_price](
https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L169)  if product cost_method is [avco.](https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/product.py#L462-L476) So, it call run_avco during that getting [the _get_manual_value](
https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L409) it through access error

Fix:-
To fix this sudo is added during getting _run_avco

opw-5431121
upg-3762999



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

Forward-Port-Of: odoo/odoo#242841

**Description of the issue/feature this PR addresses:**
In the `triggering_answer_ids` searchable dropdown, when no value is entered, the `_search_display_name` method of `chatbot_script_answer` is not called. Instead, the ORM falls back to the field’s default domain and returns all `chatbot.script.answer` records, including those from other scripts. When a value is entered, `_search_display_name` is triggered and the results are filtered correctly.

This behavior changed after PR #201587, where the `operator_optimization` step started executing before `determine_domain`. Since `determine_domain` is the step that triggers `_search_display_name`, it no longer gets called when the domain `('name', 'ilike', '')` is stripped by `operator_optimization`. Therefore, filtering only works when a non-empty filter value is provided.

**Current behavior before PR:**
All `chatbot.script.answer` records are shown in the `triggering_answer_ids` dropdown when no search value is entered, even if they don’t belong to the current chatbot script.

**Desired behavior after PR is merged:**
The `triggering_answer_ids` dropdown only shows answers belonging to the current chatbot script, regardless of whether a search value is entered.

task-[4968490](https://www.odoo.com/odoo/project/1519/tasks/4968490)

Forward-Port-Of: odoo/odoo#245322
Forward-Port-Of: odoo/odoo#228192