**Steps to reproduce:**
1. Install `l10n_mx` and `l10n_mx_edi`.
2. Create an invoice with:
   * Enable *CFDI to Public*.
   * Confirm, then send to SAT.
3. Create a credit note with:
   * *Usage* = `Returns, discounts or bonuses` (G02).
4. Download the generated XML for the credit note.

**Observed behavior:**
- The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects).

**Expected behavior:**
- The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected.

**Root cause:**
- For regime 616 (`Público en general`), the code always defaults to `S01`.
- The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes.

**Solution:**
- Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616.

**ref:**
http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls

opw-5012917

Currently a traceback occurrs from multiple places when there is no tz for employee and used in the `pytz.timezone` method.

https://github.com/odoo/enterprise/blob/517983ae9deec37795eb11522134a1f5ade31e9b/hr_payroll/wizard/hr_payroll_payslips_by_employees.py#L131

For instance, if there is no tz in resource_calendar_id, it leads to a traceback.

Error: 
```
AttributeError: 'bool' object has no attribute 'upper'
  File "odoo/http.py", line 2364, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1892, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1955, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1922, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2169, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 727, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 517, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 70, in web_save
    self.write(vals)
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_contract.py", line 429, in write
    res = super().write(vals)
  File "addons/hr_work_entry_contract/models/hr_contract.py", line 453, in write
    contract._recompute_work_entries(date_from, date_to)
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_contract.py", line 441, in _recompute_work_entries
    self._recompute_payslips(date_from, date_to)
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_contract.py", line 453, in _recompute_payslips
    all_payslips.action_refresh_from_work_entries()
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_payslip.py", line 601, in action_refresh_from_work_entries
    payslips._compute_worked_days_line_ids()
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_payslip.py", line 1141, in _compute_worked_days_line_ids
    slip_tz = pytz.timezone(slip.contract_id.resource_calendar_id.tz)
  File "odoo/_monkeypatches/pytz.py", line 129, in timezone
    return original_pytz_timezone(name)
  File "__init__.py", line 183, in timezone
    if zone.upper() == 'UTC':
```

To resolve this issue we can give a default value of `UTC` is there is no name. which makes the code more robust.

sentry-6134147853, 6119911834

Currently, an error occurs when computing a display name for stock quant.

Step to produce:

- Install the `stock` module(without demo data).
- Go to inventory settings, enable Packages, Quality, Quality Worksheet, Reception Report, Variants, Units of Measure, Product Packagings, Lots & Serial Numbers, Display Lots & Serial Numbers on Delivery Slips, Expiration Dates, and Dropshipping.
- Disable the Barcode Scanner.
- After that, enable 'Display Lots & Serial Numbers on Invoices' in the Valuation section
- Create a product and enable the 'Track Inventory' option.
- In the product form view, click on On Hand in the breadcrumbs to navigate to the stock quantity list view
- Create a new record to update the quantity.
- Click on the 'View' button, remove the location, and try to come back to update quantity list view.

`TypeError: sequence item 0: expected str instance, bool found`

This error occurs because we compute the display name of stock quant and it is derived from location_id, lot_id, package_id, or owner_id. If none of these values are present in stock quant then the system tries to concate the False (bool) value with a string at [1] and an error occurs.

Link [1]: https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/addons/stock/models/stock_quant.py#L585-L592

To resolve this issue, Assign a default display name of stock quant if none of the values of fields (location_id, lot_id, package_id, owner_id) are available.

Sentry-6165002037


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

Currently, An error occurs when the user print and send invoices  and 'Invoice report' is disabled in reports 'report_invoice_with_payments'.

Step to produce:

- Install the `account` module.
- Go to Settings / Technical / Actions / Reports, Search 'report_invoice_with_payments', and disable the 'Invoice report'.
- Go to Invoicing / Customers / Invoices, Create one invoice add a customer and invoice line, and Confirm it back to the list view of the invoice
- Select this invoice and click on Print & Send.
- After Opening a wizard, click the 'Print & Send' button.

The issue occurs when the user tries to generate and send invoices and the system checks that 'is_invoice_report' is enabled for invoices at [1].

Link [1]: https://github.com/odoo/odoo/blob/658711aa1e1809b267006149ed6a547e548c1f90/addons/account/models/account_move_send.py#L658

To resolve this, we have to remove this comparison [1] as the user can disable 'is_invoice_report' from 'report_invoice_with_payments'.

Sentry-6185986435

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

Currently, a traceback is occurring when the user tries to send a 
customer invoice with the sending method as `By Post`.

To reproduce this issue:
1) Install Accounting and Unistall `snailmail`
3) Create a posted `Customer Invoice` with a customer having no Invoice Sending
   (Remove the value in customer's accounting page if he has the value)
4) Click the `Send` button and select the sending method as `To Post` 
5) Click the `Send` button in wizard

Error:-
```
ValueError: Wrong value for res.partner.invoice_sending_method: 'snailmail'
```

The selection value  `snailmail` for `invoice_sending_method` is defined in `snailmail_acount`.
But it will be uninstalled when the `snailmail` module installed.
https://github.com/odoo/odoo/blob/636d76d6dcbbe472b9d57cbe403d0758d94ad81d/addons/snailmail_account/models/res_partner.py#L7-L9

But in the `account.move.send.wizard`, the sending_method values 
are getting from the computed method `_compute_sending_method_checkboxes`.

https://github.com/odoo/odoo/blob/636d76d6dcbbe472b9d57cbe403d0758d94ad81d/addons/account/wizard/account_move_send_wizard.py#L130

We get all the selection values(including the inactive) for the field `invoice_sending_method`. 

When the user selects the `snailmail` checkbox (By Post)to send the invoice,
the value of `invoice_sending_method` for res.partner will be assigned from the below line.

https://github.com/odoo/odoo/blob/636d76d6dcbbe472b9d57cbe403d0758d94ad81d/addons/account/wizard/account_move_send_wizard.py#L269

This will lead to the above traceback as the `snailmail` value for the selection field `invoice_sending_method` in the partner is not valid.

We can resolve this issue by accessing only the active selection values for the field `invoice_sending_method`. So only the user can select the valid value for sending_method.

sentry-6091298443

When user edits mail template html and pastes an image tag with invalid encoding it throws an error.

**Steps to reproduce:**
* Install Email marketing and activate developer mode.
* Email marketing>New>Mail Body> Start From Scratch>click `</>` icon
* Paste any improper image element which doesn't have proper base64 encoding, for example: 
`<img src='data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU 5ErkJgg'/>`
* Enter any Subject name and save.

`binascii.Error: Invalid base64-encoded string: number of data characters (113) cannot be 1 more than a multiple of 4`

**Solution:**
* It would be better to let the user know about the error than to let them mass mail corrupted image element.
* This can be done and handled by a try and except statement when the image element  added is not proper.

Sentry-6495526846

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

Foreign key error occurs when a cron job deletes a `withhold (transient model)` 
still linked to a `withhold.line`. The error appears in the terminal, not the UI. 
To reproduce, ensure withhold records in `l10n_ec_wizard_account_withhold` are 
old enough to be removed by `Auto-vacuum`.

Refer to [this](https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7493C1-L7493C87) to understand how transient models are cleaned by the `Auto-vacuum` process.


**Steps to reproduce:**
* Install `l10n_ec_edi` and `accountant`
* Change company to `EC company`
* `Accounting>Customers>Invoices>New`
* Confirm invoice with customer as `EC company` and `Payment method (SRI)` as 
  Credit card
* Add Withhold > Set document number to `001-001-123456789` > Add withhold lines
* `Create and Post`(error will occur when cron tries to delete transient model transient model after
  couple of hours.)

`psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line'`

**Solution:**
* Unlink withhold lines first and then let normal unlink take place.

**Sentry-6253783256**

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code to the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this.

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Enterprise PR:
https://github.com/odoo/enterprise/pull/92310
Ticket:
opw-4755357

Forward-Port-Of: odoo/odoo#223517

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
 
    def _can_be_invoiced_alone(self):
        """ Whether a given line is meaningful to invoice alone.

        It is generally meaningless/confusing or even wrong to invoice some specific SOlines
        (delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
        in the SO.
        """
        self.ensure_one()
        return self.product_id.id != self.company_id.sale_discount_product_id.id

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_reward_line

We just have to be careful not to accidentally include delivery fees because of

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_delivery

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357

Forward-Port-Of: odoo/enterprise#92310

**Steps to reproduce:**

- Installed industry_fsm (Field Service) module
- Navigate the menu Field Service -> Configuration -> Project
- Create a new project
- Then Navigate the menu My Tasks -> Tasks
- Create a new task with the new created project
- Then using the keyboard shortcut ctrl + k for command search, an error occurs

**Cause:**
- When the `stage_id` statusbar had no possible values,
`this.getAllItems()` returned an empty array.
- The command `isAvailable` unconditionally accessed
`this.getAllItems().at(-1).isSelected`, which is undefined,
causing a crash.[see](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L147-L148)

**Fix**
- Add safe check in the command action so it does not attempt
to select a non-existent "next" item.

**Result**
- The command palette no longer crashes when the `stage_id` field has no
available items. Instead, the command is simply unavailable.

opw-5084130
upg-3130405


Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#227440

- Create an invoice with some products and post it
- Go to Accounting > Journal items and ser for the ones belonging to the invoice.
- Set the checkbox for the product sales one and set whatever tax grid (you'll have to reveal that column).
- Accept the changes.
- Now go back to the invoice.
- You'll see a new tracking message. Something like

Journal Item #1093 updated

- It contains a link and from that link you can go to the journal item form.
- In that form you can edit the *amount in currency* field.

Issue:

- If a user do so, it leaves inconsistent invoice amounts: totals aren't recomputed, analytic lines aren't recomputed either.

How it should behave:

- Amount in currency shouldn't be editable here. Mainly when the journal entry is already posted!

opw-4951629

A vídeo showing the issue:
📹️ https://www.loom.com/share/f7cd1d8f4138458f9b6c190233b0b9df?sid=eec77c17-a4a6-4698-8604-10aaa7e33f47

MT-10887 cc @moduon

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

Forward-Port-Of: odoo/odoo#225346
Forward-Port-Of: odoo/odoo#223187

## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves

#### Description of the issue/feature this PR addresses:
Editing CZ Company address while having demo data throws Validation Error

#### Current behavior before PR:
When trying to change address of CZ Company while l10n_cz with demo data is present an error popup is displayed and it's not possible to to save the changes. Steps to reproduce:
 - Install l10n_cz with demo data
 - Open CZ Company in form view
 - Change address (e.g. change city Praha -> Brno)
 - Click Save

#### Desired behavior after PR is merged:
The address changes are saved without any error.

#### Solution:
This change adds `taxable_supply_date` date values for CZ demo moves that are compatible with `invoice_date` values to make sure that accounting date values are the same on each recomputatation and do not lead to new sequence numbers that are not aligned with the previous ones which would cause errors being raised by sequence mixin.

Related to: #226152







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

Steps to Reproduce:
------------------
- Open Helpdesk.
- Go to Configuration → Helpdesk Teams.
- Create a new team.
- Enable the Billing feature and assign a project to this team.
- Set the project’s Company field to Null.
- Create an employee for the current user in another company.
- Ensure the user has employees in both companies.
- Create a new ticket (or open an existing one) in the newly created team.
- Try creating a new timesheet → a Validation Error is raised.

Root Cause:
-----------------
When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs.

**This happens because:**

- The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216
).

- Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. 

Issue Faced:
-------------
In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82),
 which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. 

OPW: 5004092

Forward-Port-Of: odoo/enterprise#92507

**Before**
- the active_test context key is part of the main base_automation
  action (base_automation_act), but this context key stays in the
  context further, leading to unwanted filtering in i.e. the
  action_server_ids.resource_ref search view dialog.
- Steps to reproduce:
  - have base_automation installed
  - create an automation rule targeting the res.users model
  - add an Update server action targeting the Partner field
  - in the resource_ref autocomplete, click on Search More...
  - the search view dialogs displays archived records

**After**
- we chose to instead have a default filter in the base_automation_act
  action to include archived records by default. As the context key
  to activate the default filter starts with 'search_default_', it
  is already cleared from the context when opening the form view
  (standard behavior).
- when you reproduce the same steps as before, the archived records
  are no longer displayed in the search view dialog.

**Additional Note**
This fix requires to upgrade the base_automation module.

opw-4886487

**Issue**
When both a Purchase Order and a Vendor Bill are created using the same individual contact linked to a company, Bill Matching fails with a traceback.

**Steps to Reproduce**
1. Create an individual contact and link it to a company.
2. Create a Purchase Order with the individual as a vendor.
3. Create a Vendor Bill with the same individual as the vendor.
4. Try to perform Bill Matching.
5. A `ValueError: Expected singleton: res.partner(...)` is raised.

Video for reference:
https://drive.google.com/file/d/1qVnPLpk8jyMTKz-6AVLSaN2nVVeWiF4y/view

**Root Cause**
Purchase Orders store the partner exactly as selected (the individual contact), while Vendor Bills are normalized internally to the parent company (`commercial_partner_id`). This creates a mismatch in the Bill Matching logic, where records reference both the individual and the company, leading to an invalid recordset and the singleton error.

**Fix**
Always normalize vendors to their `commercial_partner_id` during Bill Matching. This ensures that both Purchase Orders and Vendor Bills consistently reference the same partner, avoiding mismatches between individual contacts and their parent company.

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

### Steps to reproduce:

- In the settings enable: "Batch, Wave & Cluster Transfers"
- Create 2 deliveries
- Barcode > operations > Delivery orders > Batches > New
- Add your two deliveries and confirm
- Scan WH-Stock
#### > The scan fails considering you scanned each letter independently.

### Cause of the issue:

When the barcode is scanned a call of the split barcode will be launched to split the barcode in multiple barcodes according to the `barcode_separator_regex` present in the config:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_model.js#L613-L632 The issue lies in the fact that even thought the is `barcode_separator_regex` was conrrectly populated at the onWillStart of the mainComponent:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L97 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_picking_model.js#L36-L38 It was reset by the batch confirmation here:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L123-L135 because this part of the config is not meant to be returned by the private method `_get_barcode_data` but rather by public complete version `get_barcode_data`:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L91-L98 Now, since no `barcode_separator_regex` was provided to our new config, each character will be considered to be considered as an independent barcodes and the `WH-Stock` barcode will not match any location.

opw-5062331

This PR addresses an issue where trashed files in documents would still appear when clicking on 'search more' when searching for documents.document in a scheduled action's action. The issue is that the base_automation_act view sets active_test context to False. This context is propagated to view_base_automation_form and results in the context for the field action_server_ids to be active_test = False. The fix for this issue will just be setting active_test to True for the action_server_ids field. This will make it such that the 'search more' action will no longer display anything archived but archived automation rules will still be displayed which was probably the original intention of setting active_test to False in base_automation_act.

Steps to reproduce bug on empty DB:
1) Install base_automation and documents modules.
2) Create a new automation rule targeting the documents module. Make sure to add a trigger.
3) Click on 'Add an action' in the page 'Actions To Do'.
4) In the wizard under action details, set the targeted field to 'folder' (folder_id). Leave the action as 'Update'.
5) Click on the 'Choose a value' drop down.
6) Click on 'Search more'.
7) Notice the number of documents that show up. The numbers on the top right hand side of the wizard should be 1-y/x where x is the total number of documents.
8) Go to the documents module and select any document.
9) Move the document to the trash with the actions button.
10) Repeat steps 4-7. Notice how the number of documents did not change.

Behavior after bug fix:
Upon completing step 10 of steps to reproduce on empty DB, the number of documents will be one less than what it was originally since we trashed one of the documents.

task-4886487


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

**Steps to reproduce:**
1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email).
2. Create an invoice with the child contact as customer and confirm it.
3. Go to the child contact and open the Customer Statement smart button.
4. Download the PDF → data is shown correctly.
5. Send the statement → the attachment in the sent mail is empty.

**Issue:**
- When sending customer statements via email from a child contact, the generated
  PDF attachment contains no data, showing empty amounts and transactions.
- Additionally, the "Customer Statement" button was still visible even when
  the total due was zero.

**Cause:**
- The button visibility condition checks for `total_due == 0.0 and not has_moves`,
  which didn’t properly cover all use cases.

**Solution:**
- Update button visibility condition to: `invisible="not has_moves or total_due == 0"`
  ensuring it is hidden when there are no moves or the total due is zero.

**opw-5009182**

Add _get_protected_fields() method and protection logic to prevent modification of critical fields when sale order is locked, matching the existing protection in sale.order.line.

Problem
Critical vulnerability where multiple users could simultaneously edit the same sale order, causing data corruption when an order was confirmed (and locked) in one window while still being edited in another.

Specific scenario:

Sale order opened in 2 windows/tabs simultaneously
User A confirms the order → automatically locked ([locked=True](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html))
User B can still modify [partner_id](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html) from the other window
Result: Corrupted data in confirmed order


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

Scenario:

- Install website and set a website on an internal user
- Install helpdesk

Result: installation fails with a traceback containing the message
"Remove website on related partner before they become internal user.".

Cause: 479e8d0cae98f7e086e5fb4a0ca4e33ed24bfc12 added a constraint so
when the groups are changed, we raise an error if the user is internal
and as a website_id set.

But if we do it the other way (setting a website_id on an internal
user), no restraint prevent this, but if at any moment the groups of the
user are changed (which helpdesk does by adding implied_ids groups) we
get an unexpected error.

Fix: change the constraint to be triggered by both website_id and
groups_id change so the user is aware sooner than he should not do it.

Note: the current code also prefetched all internal users and would not
work with non-active user, so this code simplifies that by just
prefetching the groups of the current users.

opw-5077601

PR note: putting this in draft since this is breaking some tests that I need to check

**Steps to Reproduce:**
1. Create a new membership product from the Membership module.
2. Open any partner and go to the Membership page.
3. Click on Buy Membership and select the created product.
4. Click on Invoice Membership.
5. Open the newly created draft invoice.
6. From the invoice line, open the product form (via the internal link).
7. Disable the Can be Purchased option and return to the invoice using breadcrumbs.
8. Add a new line in the invoice and search for the same product by its name.



**Observation:**
1. When Can be Purchased is enabled on the product, the product appears in the invoice line search.
2. When Can be Purchased is disabled, the product no longer appears in the search.



**Issue:**

In the product field domain defined in
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029 the `default_move_type` context is `null`.
As a result, only the condition `[('purchase_ok', '=', True)]` is applied in the `name_search` domain.



**Solution:**

Pass the proper context value in the invoice action, ensuring the domain evaluates correctly and the product remains searchable.




**Note:**

The domain used in the following field
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029

is evaluated by a following JavaScript function
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/web/static/src/core/py_js/py_interpreter.js#L483-L489

rather than on the Python backend. Because the domain logic depends on dynamic
context evaluation performed client-side, there is no straightforward way to
retrieve or test the domain arguments dynamically within the `name_search`
method on the server. As a result, it is not feasible to write automated test
cases for this specific domain filtering scenario in the backend.



opw-5028789

Forward-Port-Of: odoo/odoo#225230

**Description of the issue/feature this PR addresses:**
When creating or editing an analytic distribution, the analytic account selection does not respect the company context.
This allows users to see and select analytic accounts from other companies, which violates the multi-company record rules.

<img width="669" height="333" alt="2025-09-08_09-28" src="https://github.com/user-attachments/assets/488eb4b1-fdfa-49ca-a57e-8f46a264107d" />


**Current behavior before PR:**
The analytic account dropdown in the analytic distribution widget shows analytic accounts from all companies, instead of being restricted to the current company.

**Desired behavior after PR is merged:**
The analytic account selection in the analytic distribution widget is filtered by company.
Only analytic accounts belonging to the document company will be displayed, ensuring compliance with multi-company record rules.




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

## Issue:
For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible schedule

## Cause:
When creating `resource.calendar.leaves`, timesheets call `_work_time_per_day()`
This method uses `work_hours_data` containing half-day intervals (tmp_start/tmp_end)
These data come from `_attendance_intervals_batch()`, but we were passing an empty resource, so the check for `flexible_hours` failed:
https://github.com/odoo/odoo/blob/bd7d5fdf8df3a4d544de3e2493cd4b3966fa7d0b/addons/resource/models/resource_calendar.py#L382-L393
We want to use the calendar itself as the calendar resource to get the `work_hours_data`

## Steps to reproduce:
- On an employee, in Work Information, set the Working Hours to Flexible 40 hours/week
- Modify Flexible 40 hours/week (Hours per Week: 30, Average Hour per Day: 6)
- In Time Off > Configuration > Public Holidays, add a New holiday (You can leave default values)
- Go in Timesheets > All Timesheets, before the fix, the flexible employee have 8h in internal for Time Off

opw-4881758

**Issue**
When creating an invoice with two price-included taxes, one that affects the base of subsequent taxes (`include_base_amount=True`) and another that does not, the tax computation is incorrect. This leads to inconsistent base amounts and triggers a warning in the tax report, particularly visible in the Tax Return Report.

**Steps to Reproduce**
1. Create two taxes with `price_include=True`: Tax1 with "Affect Base of Subsequent Taxes" disabled Tax2 with it enabled
2. Add both taxes to the same invoice line and confirm the invoice
3. Open the Tax Report and filter by the invoice date
4. The report shows an inconsistency because the computed base is wrong

**Root Cause**
The batching logic separates taxes into groups when their properties differ. In this case, because the two taxes have different `include_base_amount` values, they are split into different batches. Since batching drives how price-included taxes are reversed to compute the base, splitting the batch leads to misinterpreted base amounts and incorrect tax calculations.

**Fix**
Adjusting batching conditions to allow taxes to be grouped together even if their `include_base_amount` flags differ. This ensures that price-included taxes are handled consistently and the base is computed correctly across all taxes in the group.

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

**Steps to reproduce:**

1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.

**NOTE**
-  You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
    invoice = env['account.move'].create({
        'move_type': 'out_invoice',
        'partner_id': 10,
        'company_id': env.company.id,
        'invoice_line_ids': [(0, 0, {
            'product_id': 16,
            'quantity': 1,
            'price_unit': 100.0,
        })],
    })
    invoice.action_post()
```

 **Issue:** 

`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.

 **Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73

- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />

- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />


**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.

**opw - 5083894**

**Steps to reproduce:**

- Go to PoS
- Buy a gift card, click on the sell physical gift card
- Set a custom code and price
- Reload the page
- Go through with the payment and check the downloaded pdf
- The coupon code is an automatically generated one

**Problem:**
When reloading the coupons after reloading the order, the gift cards lose their custom codes if it was set before.
This means that the coupon will have an automatically generated name in the backend as well as in the pdf that is downloaded once the payment is done.

**Why the fix:**
This happens because we are trying to access the order.get_selected_orderline()?.gift_code to get the coupon code.
https://github.com/odoo/odoo/blob/f13ee41a4a62f7fedbddc4245e52ee8e9dce9e0e/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L230
But when we leave the order to go back in afterwards, there is no selected line anymore, so the gift_code is undefined. We then fallback to the default code, which is to generate one for the user.

The gift_code is still on the orderline, so all we need to do is to link the newly created coupon with the gift_code in the orderline.

Another problem that arises her is that when purchasing a custom gift card AND a default gift card in the same order,
then reloading, the gift codes will be mixed up in the pdf and in the backend as well.
This happens because the custom code's name in the backend is 'code' and we use gift_code in the frontend, so we assign the gift_code to the code in the backend.

opw-4964509