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

- 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

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

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