Steps to reproduce:
- Install `l10n_co_dian` module(demo data) > Switch to `CO Company`
- Settings > Colombian Electronic Invoicing > Change the Operation Mode: `DIAN 2.1: Support Documents`(eg: [Image](https://www.awesomescreenshot.com/image/58874464?key=0cb74e446dcdb0f087df6ed619f785c2))
- Vendors > Create a Bill > Confirm > `Acknowledge Reception`

Traceback:
```py
 File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 293, in l10n_co_dian_send_event_update_status_received
    self._l10n_co_dian_send_event_update_status('received')
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 313, in _l10n_co_dian_send_event_update_status
    document = self.env['l10n_co_dian.document']._send_commercial_event(self, commercial_state_next)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/l10n_co_dian_document.py", line 593, in _send_commercial_event
    xml, errors = self.env['account.edi.xml.ubl_dian']._export_co_send_event_update_status_invoice(locked_move, commercial_state_next)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1208, in _export_co_send_event_update_status_invoice
    return self.with_context(l10n_co_next_commercial_state=next_commercial_state)._dian_sign_xml(xml, invoice)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1524, in _dian_sign_xml
    'software_security_code': self._dian_get_security_code(operation_mode, document_number),
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1443, in _dian_get_security_code
    operation_mode.dian_software_id
TypeError: unsupported operand type(s) for +: 'int' and 'str'
```

We are getting this error because `_dian_get_operation_mode` [returns] an empty `l10n_co_dian.operation_mode()` record. This happens when the `Operation modes` do not match. As a result, [operation_mode] also contains an empty record.

[operation_mode]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1432

[returns]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1394-L1400

sentry-7273771732

Forward-Port-Of: odoo/enterprise#107885

Problems:
-------
1. For a new employee, with a contract starting in the current month but before today:
in the payslip for the current month number of days of attendance and days of out of contract
are not correct

Same for an employee, with a contract ending in the current month (before today)

2. In both cases above worked entries are not generated correctly
(from today to the end of month)

3. Additional bug:
If we create an employee with no contract and create a payslip draft for him
for the current month, work entries with type "Attendance" will be created

Objective:
---------
Problems 1 and 2 :
date_version was equal to today (date of the employee's creation),
so number of attendance days was calculated as
( end_of_payslip_month - today ) or ( today - start_of_payslip_month )

Problem 3 :
Work entries are generated even when there is no active contract

Solution:
---------
Problems 1 and 2: This commit adds an additional part (already exists in v19) in the method
write() of hr.version which sets date_version = contract_date_start

Problem 3: by generating work entries check if contract_date_start is filled

Tests ware added in odoo/hr: test_hr_version.py
and in enterprise/hr_payroll:
test_new_employee_worked_days, test_payslip_empty_contract.py

task-5430759

Forward-Port-Of: odoo/odoo#251264
Forward-Port-Of: odoo/odoo#241978

### Steps to Reproduce:
1. Go to Accounting > Create a journal.
2. Archive the company’s default income/expense or cash diff. accounts.
3. Change the journal type.
3. Observe that an archived account is assigned by the onchange method.

### Issue:
- Prior to saas-18.3, no onchange logic existed for assigning default accounts. With the introduction of the [onchange]
(https://github.com/odoo/odoo/commit/334a8161cd2feb092cafedc35d94645900b40518) , archived income/expense or default cash diff. accounts can be assigned to journals.
- This creates an inconsistency, as the domain [defined] (https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L70-#L82) for `default_account_id` only returns active accounts.

### Solution:
- Since the domain for `default_account_id` returns only active accounts, this commit aims to update the onchange [logic](https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L540-#L551) in order to follow the same restriction, ensuring that only active accounts are assigned thereby preventing inconsistent behavior.

OPW-5501539

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

Currently, editing a posted `miscellaneous` journal entry in Chile 
localization incorrectly raises a validation error.

**Steps to reproduce:**
- Install the `l10n_cl` module and switch to the `CL company`.
- Go to Accounting > Accounting > Journal Entries.
- Create a balanced entry using the `Miscellaneous journal `and `post` it.
- Reset it to draft, modify the `name`, and try to `save` it.

**Observation:**
`Validation error`: `The DTE document number (folio) must contain only digits.`

**Root cause:**
At [1], the constraint validation is applied to all journal entries in 
Chilean companies, including `miscellaneous` journals. However, 
`miscellaneous journals (move_type = 'entry')` are not linked to Chilean 
electronic documents, so the numeric folio validation should not apply to them.

**Fix:**
This commit ensures that the validation is not raised for `miscellaneous` journal 
types by excluding miscellaneous journals from the numeric folio validation constraint.

[1]:
https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30

opw-5926773

Forward-Port-Of: odoo/odoo#248965

When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others

Steps to reproduce:
-------------------
1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B
1. Create a sales order
2. Add two units of the product to the sale order
3. Confirm the sales order
4. Open the transfer, make the transfer retrieve the product from several location with the same lot.
5. Save the transfer
6. Open the sales order in POS
7. Load the SN/lots
-> Two line of qty 1 appear for the product A but only the first one has the lot number

Additional Issue:
8. Change the number of the product for the first line to 2 and erase the second line
9. Confirm and Pay
10. Close POS
11. Open move lines for this product (Inventory>product>In/out)
-> It moves 2 product from one location (when there is only product)

Observation:
-------------
When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten.

Addition Issue :
When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297

opw-5347992

Forward-Port-Of: odoo/odoo#251270
Forward-Port-Of: odoo/odoo#243347

This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug.

Reproduce:
With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field.

After the fix:
The "Custom Url" field must not be displayed when URL does not contain a customisable slug.

Task-5114394

Forward-Port-Of: odoo/odoo#251294
Forward-Port-Of: odoo/odoo#231609

Steps to reproduce:
- Install `l10n_co_dian` module(demo data) > Switch to `CO Company`
- Settings > Colombian Electronic Invoicing > Change the Operation Mode: `DIAN 2.1: Support Documents`(eg: [Image](https://www.awesomescreenshot.com/image/58874464?key=0cb74e446dcdb0f087df6ed619f785c2))
- Vendors > Create a Bill > Confirm > `Acknowledge Reception`

Traceback:
```py
 File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 293, in l10n_co_dian_send_event_update_status_received
    self._l10n_co_dian_send_event_update_status('received')
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 313, in _l10n_co_dian_send_event_update_status
    document = self.env['l10n_co_dian.document']._send_commercial_event(self, commercial_state_next)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/l10n_co_dian_document.py", line 593, in _send_commercial_event
    xml, errors = self.env['account.edi.xml.ubl_dian']._export_co_send_event_update_status_invoice(locked_move, commercial_state_next)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1208, in _export_co_send_event_update_status_invoice
    return self.with_context(l10n_co_next_commercial_state=next_commercial_state)._dian_sign_xml(xml, invoice)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1524, in _dian_sign_xml
    'software_security_code': self._dian_get_security_code(operation_mode, document_number),
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1443, in _dian_get_security_code
    operation_mode.dian_software_id
TypeError: unsupported operand type(s) for +: 'int' and 'str'
```

We are getting this error because `_dian_get_operation_mode` [returns] an empty `l10n_co_dian.operation_mode()` record. This happens when the `Operation modes` do not match. As a result, [operation_mode] also contains an empty record.

[operation_mode]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1432

[returns]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1394-L1400

sentry-7273771732

Forward-Port-Of: odoo/enterprise#107885

This error occurs when clicking the `Reset Selected Work Entries` button while there are no employees in the work entries.

Steps to reproduce:
- Install `hr_payroll` module
- Payroll > Work Entry > Remove `Active` Filter
- Select any cell and click on the reset button

Traceback:
`KeyError: 'employee_id'`

This error occurs when the `Reset Selected Work Entries` button is clicked without an employee, causing `employee_id` to be missing at [1].

Solutions:
- Raise a validation error when no employee is selected and the `Reset Selected Work Entries` button is clicked.
- Fix the error that occurs when clicking the `Set` button to add or replace a work entry.
- Fix the error that occurs when the `Active` filter is enabled and the `Reset` button is clicked.
```
Missing Record
Record does not exist or has been deleted.
(Record: hr.employee(2,), User: 2)
```

[1]: https://github.com/odoo/odoo/blob/4949a6272691c781d5ab5a8b06f88f58d5cea4df/addons/hr_work_entry/wizard/hr_work_entry_regeneration_wizard.py#L116

sentry-7140947833

Forward-Port-Of: odoo/enterprise#103162

Currently, editing a posted `miscellaneous` journal entry in Chile 
localization incorrectly raises a validation error.

**Steps to reproduce:**
- Install the `l10n_cl` module and switch to the `CL company`.
- Go to Accounting > Accounting > Journal Entries.
- Create a balanced entry using the `Miscellaneous journal `and `post` it.
- Reset it to draft, modify the `name`, and try to `save` it.

**Observation:**
`Validation error`: `The DTE document number (folio) must contain only digits.`

**Root cause:**
At [1], the constraint validation is applied to all journal entries in 
Chilean companies, including `miscellaneous` journals. However, 
`miscellaneous journals (move_type = 'entry')` are not linked to Chilean 
electronic documents, so the numeric folio validation should not apply to them.

**Fix:**
This commit ensures that the validation is not raised for `miscellaneous` journal 
types by excluding miscellaneous journals from the numeric folio validation constraint.

[1]:
https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30

opw-5926773

Forward-Port-Of: odoo/odoo#248965

From version 19.1, a new image pop-up functionality was introduced. Now, when an image is added to the website,
and the pop-up image option is enabled,
Clicking the image raises a traceback.

To reproduce the issue:
- Connect to a saas~19.1 runbot,
- open the website module, and enter edit mode.
- Add an image, click it, and enable the pop-up image option.
- Save the changes.
- Clicking the image will display the pop-up, but a traceback will appear behind it.

<img width="1920" height="931" alt="Home-Odoo-02-25-2026_05_43_PM" src="https://github.com/user-attachments/assets/73662dc7-cf0e-4246-b6cd-685c758fb4d7" />

This change reintroduces the check because `this.liEls` can be undefined when only one image is added, which was causing errors when the length check was performed without it.
<img width="240" height="53" alt="2026-02-25_17-45" src="https://github.com/user-attachments/assets/daea05a4-3fc9-4208-aaa6-345bd62c27c6" />

[opw-5973719](https://www.odoo.com/odoo/project/974/tasks/5973719?debug=1)
Customer reported issue [here](https://www.odoo.com/odoo/project/70/tasks/5962120?debug=1)


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

When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others

Steps to reproduce:
-------------------
1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B
1. Create a sales order
2. Add two units of the product to the sale order
3. Confirm the sales order
4. Open the transfer, make the transfer retrieve the product from several location with the same lot.
5. Save the transfer
6. Open the sales order in POS
7. Load the SN/lots
-> Two line of qty 1 appear for the product A but only the first one has the lot number

Additional Issue:
8. Change the number of the product for the first line to 2 and erase the second line
9. Confirm and Pay
10. Close POS
11. Open move lines for this product (Inventory>product>In/out)
-> It moves 2 product from one location (when there is only product)

Observation:
-------------
When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten.

Addition Issue :
When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297

opw-5347992

Forward-Port-Of: odoo/odoo#251270
Forward-Port-Of: odoo/odoo#243347

This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug.

Reproduce:
With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field.

After the fix:
The "Custom Url" field must not be displayed when URL does not contain a customisable slug.

Task-5114394

Forward-Port-Of: odoo/odoo#251294
Forward-Port-Of: odoo/odoo#231609

Have a grouped list view with no aggregate fields. Before this commit, the colspan of the first `th` in group header rows wasn't optimally computed. These `th` can span to the very last cell (excluded), which may contain a cog menu. However, they only spanned to the second to last cell. As a consequence, in a list with only 2 columns, e.g. a handle and a name, the groups' name only got a few px available, and were hence cropped.

The issue came from successive reworks of the group header row, leading to the pager being finally moved from its own column (after the last aggregate column), to the group name cell (with ms-auto).

The logic is easier now, as a group header row looks like this:
- a single `<th colspan="n">` (n >= 1) to display the group name: spans to the first aggregate column excluded or to the last cell excluded if no aggregate (colspan + 1 if rows have selectors)
- one `<th colspan="1">` for each aggregate column
- optionally one `<th colspan="m">` (m >= 1) for all columns after the last aggregate column
- a single `<th colspan="1">` for the potential cog menu (optional dropdown column)

opw~5730396

Before
<img width="1918" height="471" alt="image" src="https://github.com/user-attachments/assets/8f55322b-1603-42cc-a48b-a2010ff12e25" />

After
<img width="1909" height="423" alt="image" src="https://github.com/user-attachments/assets/0bca4865-88a1-424d-a1af-1523dbfa911c" />

Forward-Port-Of: odoo/odoo#251411

Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in progress.

Interestingly, the issue could not be reproduced with the Japanese keyboard, which appeared to behave correctly. See [1].

This commit introduces a short delay before closing the autocomplete. On iOS, the IME temporarily triggers a Backspace event to remove the previously composed character before inserting the updated one. This Backspace incorrectly causes the autocomplete to close. With this change, we wait briefly (10ms) before closing it. If a new input event is received during that delay (corresponding to the newly composed character generated by the IME), the close action is cancelled.

This ensures that the autocomplete remains open while the IME composition process completes.

Steps to reproduce:
- Configure a Korean keyboard on an iPhone
- Open a Sale Order
- Focus the search bar
- Type a character, then type a second one to combine them
- The search input value gets reset

[1] #222151

opw-5448385

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

Version : saas-18.4+e

Steps to reproduce
------------------
Create a product and add a line in the purchase tab with a “Vendor Product Name” and/or a “Vendor Product Code”.

Create a purchase order for this product with the right vendor and confirm it.

Go to the delivery receipt, the vendor code and/or name are added twice in the description.

Why is it happening
------------------
The _compute_description_picking method from stock.move, which is overridden in purchase_stock module, adds the vendor code and name to the description. However, if no description_picking has been set on the product, the description is already defined as the vendor code and name.

Solution
------------------
I propose to remove the code and the name from the vendor_reference variable if the original description already contains them.

opw-5392855

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

Forward-Port-Of: odoo/odoo#251337
Forward-Port-Of: odoo/odoo#242075

Steps to produce:
---
- Install `website_sale` module.
- Go to website > open editor.
- Add an image snippet to the homepage.
- Click on the image and enable `Pop-up on Click`, then save.
- Click on the image.

Traceback:
---
`TypeError: Cannot read properties of undefined (reading 'length')`

Root cause:
---
- In the `setup` method, when the image is not part of a carousel,
  the element `.carousel-indicators` does not exist. As a result,
  `indicatorEl` is null, and the guarded block(at [1]) is skipped.
  Because of this, `this.liEls` is never initialized.
- Later, when the `onSlidCarousel` method is executed,
  its internal condition evaluates and find `liEls` as null and
  then `hide` method is called(see [2]).
- Inside the `hide` method, the code attempts to iterate
  over `this.liEls`(see [3]).

Solution:
---
- Initialized `liEls` in `setup()` to ensure it is always defined.
- Added a length check in `onSlidCarousel()` to execute the logic
  only when `liEls.length > 0`.
- This prevents this.page from being computed using invalid
  values and avoids it being set to `NaN`.
- Additionally, as requested by the boje(po), hide the popup
  on click setting on product images.
  
**Alternative approaches:**

1. We can also call the `onSlideCarousel` method from `setup`
    when multiple images are present.
2. Also, we can add a simple check inside the `onSlideCarousel`
    method to ensure that `liEls` is defined before proceeding.

[1]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L31-L57
[2]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L144-L152
[3]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L119-L120

opw-5921123
---

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

**Steps to reproduce:**
* Install  `stock` module.
* Go to the > Settings*, enable *Packages* and
  *Storage Locations*(warehouse).
* Create a storable product and set *Tracking Inventory* to
  **By Quantity** and set some *barcode*
* Update the on-hand quantity for the product and assign it to one packages.
* Open *Barcode > Operations > Internal Transfer* and create a new
  transfer.
* Click the *gear icon* in the top-right corner to open the barcode
  scanning flow.
* manually enter the created product barcode and apply it.
* Click the **Back** button multiple times in quick succession.
* Go to the backend and open the created internal transfer.

**Observed behavior:**
* The internal transfer is created with *double quantities*
 compared to what was added in the barcode interface.

**Cause:**
* When clicking the *Back* button, the following flow is triggered:
  `exit()` → `beforeQuit()` → `save()`.
https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483
* If the button is clicked multiple times rapidly, `exit()` is called
  again before the previous `save()` RPC completes.
* This results in multiple `save()` calls being executed, causing
  duplicated quantities on the picking.

reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74

**Fix:**

 * Prevent rapidly clicking the Back button multiple times
 does not multiply quantities.

---
opw-5375899

Forward-Port-Of: odoo/enterprise#109013
Forward-Port-Of: odoo/enterprise#103130

In Taiwan e-invoicing, B2C customers can request a paper copy of their invoice. When selected, the "Invoicing Info" step—which collects data like donation codes or carriers—should be skipped as it is not applicable to physical copies.

Previously, this logic failed during guest checkouts because the partner initially associated with the order is an archived public user. The persistent partner is only created/assigned after the address form is submitted.

This commit:
- Overrides `_create_or_update_address` instead of `_handle_extra_form_data` to ensure the paper format preference is saved on the correct, newly generated partner.
- Updates `_prepare_address_form_values` to correctly load existing preferences from the partner for registered users.
- Ensures the `l10n_tw_edi_is_print` flag on the Sales Order stays in sync with the partner's preference.

Task-5912985

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

Forward-Port-Of: odoo/odoo#247961

Steps to Reproduce  
------------------  
1. Open the Planning Gantt view.
2. Click a cell that belongs to a resource with **no** scheduled shifts.  
3. The Plan dialog opens with an empty list.  
  
Issue  
-----  
A previous change  keeps the clicked resource in the dialog context; the Gantt 
model turns it into a default search filter, so only shifts already linked to 
that resource are shown. Unassigned shifts are therefore hidden, preventing 
planners from assigning them by role or availability.  
  
Current Behaviour  
-----------------  
The Plan dialog is always filtered by `resource_id`, which returns no results 
for unscheduled resources, even when they have the right roles.
  
Expected Behaviour  
------------------  
The dialog should list all unscheduled shifts that match the resource’s roles, 
or every unscheduled shift if the resource has no roles, while still preserving
full context for scheduling once a shift is selected.  
  
Fix  
---  
Remove the automatic resource filter from the dialog context in 
`getSelectCreateDialogProps()`. This prevents the unwanted search restriction; 
role defaults remain, so the dialog now displays the correct shifts.  
  
Task-4922525  
Issue – https://github.com/odoo/enterprise/pull/87424/commits/a218a7cedce61f992fbe76284c273be8f937d28d

Forward-Port-Of: odoo/enterprise#92100

## Versions
17.0+

## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.

## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
  - Setup Avatax;
  - Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
  - Go to the shop;
  - Add the product you created to the cart;
  - Enter the cart;
  - Click the "Buy with GPay" button:
    - The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
  - The total amount differs from the amount paid (cf. transaction).

opw-5020793

Forward-Port-Of: odoo/enterprise#108957
Forward-Port-Of: odoo/enterprise#101579

…bcontracted

**Problem:**
Landed cost added on the receipt of a subcontracted product
do not increase the valuation of the product and do not create 
account move lines.

**Steps to reproduce:**
- create a tracked product with avco perpetual category
- create a subcontracted bom for this product with no comp
- create and confirm a PO for 10 unit of this product at a unit price 
of 1$ with the same partner as the subcontractor of the bom
- validate the receipt
- navigate to inventory/operations/adjustments/landed costs
- create a new landed cost
- select the receipt from the PO
- add a landed cost of 10$ and validate
- navigate to inventory/reporting/stock
- search for your product and click on the unit cost

**Current behavior:**
1) the valuation of the product was not increased by the value 
of the landed cost
2) open journal items : no account move lines were created for the 
landed cost

**Expected behavior:**
1) the valuation of the product should have been increased:
in the unit cost view, the SBC move should have gone from a 
value of 10 to 20
2) account move lines should have been created with a value 
of 10

**Cause of the issue:**
both issues come from the fact that when creating the 
stock valuation adjustment line, the move linked is the receipt move
when it should be the move of the subcontracted MO linked to the 
receipt.

**fix:** 
if we create the adjustement line with move_id as the move of the MO
(instead of the move of the receipt as it is the case currently) : 
when button_validate is called on the landed cost : 
- when using the remaining quantity, it will be the correct one 
(in our case 10, instead of 0 for the move of the receipt because it's 
actually an internal move) so the account move line are going to 
be created
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L129-L130
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L372-L373
which solves problem 2) 

-  when calling _set_value on the move (which will be the move of 
the MO thanks to this fix), 
https://github.com/odoo/odoo/blob/064407d32f998ceb08601f9e0a6356c94ad10347/addons/stock_landed_costs/models/stock_landed_cost.py#L152
get_value_data will call _get_value_from_extra,
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_account/models/stock_move.py#L392
which uses _get_landed_cost to fetch the landed cost
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L18
before this fix the landed cost created from the receipt were linked to 
the receipt move so they were not fetched inside _get_landed_cost
which caused problem 1) but now the move_id of the adjustment lines 
is the move of the MO so they are fetched inside _get_landed_cost
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L7-L12
So now the adjustment lines do impact the valuation of the move of 
the MO which solves problem 1)

opw-5723126

Forward-Port-Of: odoo/odoo#248469

Issue
=====

The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors.

Steps to Reproduce
==================

1. Install `industry_fsm_sale` and `l10n_br`.
2. In the US company:
   - Create a Brazilian customer.
   - Set a fiscal position on the customer.
3. Switch to the Brazilian company:
   - Open the same customer.
   - Set a fiscal position on the customer.
4. Still in the Brazilian company:
   - Create a task for that customer in the Field Service app.
   - Add a product to the task.

Result
======

An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company.

Root Cause
==========

When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company.

Solution
========

Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used.

opw-5270522

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

Forward-Port-Of: odoo/odoo#250115
Forward-Port-Of: odoo/odoo#249482

An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change

Steps to reproduce:
1. Install l10n_mx and l10n_mx_hr_payroll modules
2. Switch to INNOVACION VALOR... company
3. Go to Employees and open Cecilia Miranda Sanchez
4. Go to Payroll tab, set the end of the contract to Jan 31 and save
5. Create a new contract from Feb 1
6. Go to Payroll > Payslips > Payslips and create a new pay run
7. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and Period 'Jan 1 -> Jan 15'
8. Click on Continue, select Cecilia and click on Select
9. An error is thrown

Problem:
In `_compute_integration_factor` we try to compute the number of years the employee has worked by accessing the start date on the employee but this date might be earlier than the start date of the employee's current contract if the employee has changed contract. This will throw an error when we try to access the holidays count for 0 year because `payslip._rule_parameter('l10n_mx_holiday_tables')` doesn't have an entry for 0

Solution:
Use the start date of the first contract of the employee, take gaps in between the employee's contracts into consideration to correctly compute the number of years worked

opw-5931355

Forward-Port-Of: odoo/enterprise#108495

Currently, editing a posted `miscellaneous` journal entry in Chile 
localization incorrectly raises a validation error.

**Steps to reproduce:**
- Install the `l10n_cl` module and switch to the `CL company`.
- Go to Accounting > Accounting > Journal Entries.
- Create a balanced entry using the `Miscellaneous journal `and `post` it.
- Reset it to draft, modify the `name`, and try to `save` it.

**Observation:**
`Validation error`: `The DTE document number (folio) must contain only digits.`

**Root cause:**
At [1], the constraint validation is applied to all journal entries in 
Chilean companies, including `miscellaneous` journals. However, 
`miscellaneous journals (move_type = 'entry')` are not linked to Chilean 
electronic documents, so the numeric folio validation should not apply to them.

**Fix:**
This commit ensures that the validation is not raised for `miscellaneous` journal 
types by excluding miscellaneous journals from the numeric folio validation constraint.

[1]:
https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30

opw-5926773

Forward-Port-Of: odoo/odoo#248965

When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others

Steps to reproduce:
-------------------
1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B
1. Create a sales order
2. Add two units of the product to the sale order
3. Confirm the sales order
4. Open the transfer, make the transfer retrieve the product from several location with the same lot.
5. Save the transfer
6. Open the sales order in POS
7. Load the SN/lots
-> Two line of qty 1 appear for the product A but only the first one has the lot number

Additional Issue:
8. Change the number of the product for the first line to 2 and erase the second line
9. Confirm and Pay
10. Close POS
11. Open move lines for this product (Inventory>product>In/out)
-> It moves 2 product from one location (when there is only product)

Observation:
-------------
When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten.

Addition Issue :
When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297

opw-5347992

Forward-Port-Of: odoo/odoo#251270
Forward-Port-Of: odoo/odoo#243347

### Issue:
The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours.

### Steps to reproduce:
- Go to Planning app
- Create a shift for an employee from 3pm to 2am (over two days)
- The hours of the shift are displayed
- Modify the shift end to 3am
- The hours of the shift aren't displayed

### Cause:
Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c).

But as the pills are no longer truncated since 17.0, the computation of pill names is faulty.

### Solution:
We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it.

opw-5881532

Forward-Port-Of: odoo/enterprise#109217
Forward-Port-Of: odoo/enterprise#107233

## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.

<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
    - Any Customer
    - Any Recurring Plan
    - Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**

## Cause
The title shown in the preview is defined here:

https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195

The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201

The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237

The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.

## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:

https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803

<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />

## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.

opw-5489970

Forward-Port-Of: odoo/enterprise#106767

Steps to Reproduce:
1. Generate payslips for a batch of employees (e.g., Employee A and
   Employee B).
2. Ensure the last processed payslip (Employee B) has a negative net
   wage or is uncomputed (net wage 0.0).
3. Ensure Employee A has a valid, positive net wage.
4. Open the payslip for Employee A.

Issue:
Employee A displays the warning "The net pay for this payslip is zero
or negative," even though their net wage is positive.

This occurred because the lambda filter used the `slip` variable from
the outer loop scope instead of the iterator, causing the last
record's net wage to determine the warning for the entire batch.
Additionally, uncomputed payslips (which have no lines) default to a
net wage of 0.0, which triggered the warning condition prematurely.

Expected Behavior:
The warning should only appear if the specific payslip being checked
has a negative or zero net wage. Furthermore, the warning should be
suppressed if the payslip lines have not yet been computed.

Additionally, added a test to check the message is not displayed if
we don't have net salary, and appears if the net is indeed negative.

task-5484107

Forward-Port-Of: odoo/enterprise#108601
Forward-Port-Of: odoo/enterprise#103918

Steps to reproduce:
- Install `l10n_co_dian` module(demo data) > Switch to `CO Company`
- Settings > Colombian Electronic Invoicing > Change the Operation Mode: `DIAN 2.1: Support Documents`(eg: [Image](https://www.awesomescreenshot.com/image/58874464?key=0cb74e446dcdb0f087df6ed619f785c2))
- Vendors > Create a Bill > Confirm > `Acknowledge Reception`

Traceback:
```py
 File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 293, in l10n_co_dian_send_event_update_status_received
    self._l10n_co_dian_send_event_update_status('received')
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 313, in _l10n_co_dian_send_event_update_status
    document = self.env['l10n_co_dian.document']._send_commercial_event(self, commercial_state_next)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/l10n_co_dian_document.py", line 593, in _send_commercial_event
    xml, errors = self.env['account.edi.xml.ubl_dian']._export_co_send_event_update_status_invoice(locked_move, commercial_state_next)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1208, in _export_co_send_event_update_status_invoice
    return self.with_context(l10n_co_next_commercial_state=next_commercial_state)._dian_sign_xml(xml, invoice)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1524, in _dian_sign_xml
    'software_security_code': self._dian_get_security_code(operation_mode, document_number),
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1443, in _dian_get_security_code
    operation_mode.dian_software_id
TypeError: unsupported operand type(s) for +: 'int' and 'str'
```

We are getting this error because `_dian_get_operation_mode` [returns] an empty `l10n_co_dian.operation_mode()` record. This happens when the `Operation modes` do not match. As a result, [operation_mode] also contains an empty record.

[operation_mode]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1432

[returns]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1394-L1400

sentry-7273771732

Forward-Port-Of: odoo/enterprise#107885

Prevent unnecessary ["Too large image (above 50.0Mbpx)" error](https://github.com/odoo/odoo/blob/fee6b32a8a57577bd8229c80dff6f93964f9f556/odoo/tools/image.py#L99) when the image is resized immediately afterward.

Currently, an image larger than 50Mpx triggers an error when inserted into a prompt, even though the image processing pipeline resizes it right after.
This makes the size check inconsistent with the actual behavior of the system.

Current behavior:
- 51Mpx image → prompt → error
- 49Mpx image → prompt → resized → OK

Proposed behavior:
- 51Mpx image → prompt → resized → OK
- 49Mpx image → prompt → resized → OK

In practice, the 50Mpx limit does not protect against memory issues in this flow, since the image is systematically resized (max 1024px width/height) before being stored or used by the AI module. The original full-resolution image is never processed beyond the resizing step.

Moreover, similar image processing logic in base/models/ir_attachment.py already allows larger images, meaning we support them elsewhere in the codebase. This makes the current restriction here inconsistent and redundant.

By removing this premature size validation, we:
- Avoid forcing users to manually resize images that would be resized anyway
- Align the behavior with other ImageProcess() usages
- Keep the same effective resource usage, since resizing still happens immediately

The safeguard against excessive memory usage remains in place through the resizing logic itself, so this change does not introduce additional risk.

**Steps to reproduce:**
* Install  `stock` module.
* Go to the > Settings*, enable *Packages* and
  *Storage Locations*(warehouse).
* Create a storable product and set *Tracking Inventory* to
  **By Quantity** and set some *barcode*
* Update the on-hand quantity for the product and assign it to one packages.
* Open *Barcode > Operations > Internal Transfer* and create a new
  transfer.
* Click the *gear icon* in the top-right corner to open the barcode
  scanning flow.
* manually enter the created product barcode and apply it.
* Click the **Back** button multiple times in quick succession.
* Go to the backend and open the created internal transfer.

**Observed behavior:**
* The internal transfer is created with *double quantities*
 compared to what was added in the barcode interface.

**Cause:**
* When clicking the *Back* button, the following flow is triggered:
  `exit()` → `beforeQuit()` → `save()`.
https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483
* If the button is clicked multiple times rapidly, `exit()` is called
  again before the previous `save()` RPC completes.
* This results in multiple `save()` calls being executed, causing
  duplicated quantities on the picking.

reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74

**Fix:**

 * Prevent rapidly clicking the Back button multiple times
 does not multiply quantities.

---
opw-5375899

Forward-Port-Of: odoo/enterprise#109013
Forward-Port-Of: odoo/enterprise#103130

An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change

Steps to reproduce:
1. Install l10n_mx and l10n_mx_hr_payroll modules
2. Switch to INNOVACION VALOR... company
3. Go to Employees and open Cecilia Miranda Sanchez
4. Go to Payroll tab, set the end of the contract to Jan 31 and save
5. Create a new contract from Feb 1
6. Go to Payroll > Payslips > Payslips and create a new pay run
7. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and Period 'Jan 1 -> Jan 15'
8. Click on Continue, select Cecilia and click on Select
9. An error is thrown

Problem:
In `_compute_integration_factor` we try to compute the number of years the employee has worked by accessing the start date on the employee but this date might be earlier than the start date of the employee's current contract if the employee has changed contract. This will throw an error when we try to access the holidays count for 0 year because `payslip._rule_parameter('l10n_mx_holiday_tables')` doesn't have an entry for 0

Solution:
Use the start date of the first contract of the employee, take gaps in between the employee's contracts into consideration to correctly compute the number of years worked

opw-5931355

Forward-Port-Of: odoo/enterprise#108495

Steps to Reproduce  
------------------  
1. Open the Planning Gantt view.
2. Click a cell that belongs to a resource with **no** scheduled shifts.  
3. The Plan dialog opens with an empty list.  
  
Issue  
-----  
A previous change  keeps the clicked resource in the dialog context; the Gantt 
model turns it into a default search filter, so only shifts already linked to 
that resource are shown. Unassigned shifts are therefore hidden, preventing 
planners from assigning them by role or availability.  
  
Current Behaviour  
-----------------  
The Plan dialog is always filtered by `resource_id`, which returns no results 
for unscheduled resources, even when they have the right roles.
  
Expected Behaviour  
------------------  
The dialog should list all unscheduled shifts that match the resource’s roles, 
or every unscheduled shift if the resource has no roles, while still preserving
full context for scheduling once a shift is selected.  
  
Fix  
---  
Remove the automatic resource filter from the dialog context in 
`getSelectCreateDialogProps()`. This prevents the unwanted search restriction; 
role defaults remain, so the dialog now displays the correct shifts.  
  
Task-4922525  
Issue – https://github.com/odoo/enterprise/pull/87424/commits/a218a7cedce61f992fbe76284c273be8f937d28d

Forward-Port-Of: odoo/enterprise#92100

Have a view (e.g. list) with no real records but sample data. In the control panel, have a button that, when clicked, creates new records which match the current filter, i.e. which are displayed directly in the UI.

Before this commit, the new records were correctly displayed, but the sample data overlay (opacity) was still there.

The problem came from the fact that the sample data are automatically disabled when the view is reloaded **from above** (typically from the WithSearch component, when the user interacts with the search view). However, in the faulty scenario, the `load` function of the model is called directly by the view itself, so we don't go through WithSearch, and the code of model.js that ensures that we leave the sample mode.

We already faced that issue in pivot and graph, and we solved it locally. This commit fixes it globally, by creating a small override of model.load which leaves the sample mode.

task~5980226

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

# How to reproduce
- Use a browser extension to manage your browser's timezone
- Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe)
- Go to the form view of an opportunity
- Click on the smart button for meetings (Should be "No Meeting" if it is a new Opportunity)
- In the calendar view, add a new meeting for very late in the day (Example : 2026-02-10 22:00:00 => 23:00:00)
- Go back to the opportunity for view

# The problem
The date displayed is a day after the meeting that was just set up. Taking back our example, the date displayed would be 2026-02-11

# Why
The calendar view uses the browser's timezone to manage the dates. The smart button does not.

It is not possible to make the smart button use the browser's timezone, atleast in a clean way. That is because the smart button's data is managed by a python template, which does not have access to the browser's data. Trying to change the data displayed by the framework would be clunky as the html would need to be edited directly.

The fix that I implemented follows what the hr_appraisal module does for it's smart button with a date: use the timezone set in the user's preferences.

opw-5898520

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

### Issue:
When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app.

### Steps to reproduce:
- Have a payslip run with payslips
- Go to a payslip, validate and generate the document
- Then cancel and reset to draft
- Reset the Payslip Run to draft
- Delete it
- Open the Documents app

### Cause:
The payslips are linked to the run with a `ondelete='cascade'` relation. 

https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113

This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB.

### Solution:
Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there.

opw-5501061

**Steps to reproduce:**
- Go to mass_mailing app
- Add Columns block with multiple content size
- Increase Round Corners (e.g. 20 px)
- In "Vert. Alignment" field > Select the "Stretch to Equal Height" option
- Add color background for the columns
- Save the record and send test mail
- Round corners are not applied
- Background color doesn't expand to the bottom of the body

**Issue:**
Default table style used for the inline conversion of 
`await toInline($(editableClone), { $iframe: $(iframe), wysiwyg: this.wysiwyg });` in `mass_mailing_html_field`,
has its 'border-collapse' attribute set to 'collapse' by default in `enforceTablesResponsivity`.

This attribute doesn't work with `border-radius` and the resulting display differs from the preview of the editor.

Relevant links:
https://stackoverflow.com/questions/628301/the-border-radius-property-and-border-collapsecollapse-dont-mix-how-can-i-use https://stackoverflow.com/questions/36035461/what-is-the-difference-between-border-collapse-collapse-and-border-spacing-0

**Fix:**
Use `'border-collapse': 'separate'` and `'border-spacing': 0` but this can
introduce border stacking inside the table element where the original collapse
was needed.

Add back the `overflow` inherited by the card attributes to ensure
inside border are visually properly contained inside the border (but not
sure as to why it was removed 4 years ago).

Also set the height of table sub-elements to `100%` to ensure background
property is properly applied on the whole card body.

opw-5218581

SMS reminders are not sent for calendar events synced with Google, even though only email reminders should be delegated to Google.

Reproduction steps:

* Create a calendar event in Odoo with an SMS reminder.
* Sync the calendar with Google.
* Wait for the reminder to trigger.
* Observe that no SMS is sent by Odoo.

Cause:

The event reminder scheduled action groups events by alarm type and calls `_get_events_by_alarm_to_notify`. For Google-synced events, `_get_notify_alert_extra_conditions` blindly excludes any event with a `google_id`, assuming Google will manage all reminders. This exclusion is incorrect for non-email alarms (e.g. SMS), which must still be handled by Odoo.

Fix:

The alarm type is propagated through the context so Google-specific exclusions only apply to email reminders. This restores SMS notifications while preserving the existing behavior for emails. A context key is used for stability; a proper method argument will be introduced in master.

opw-5172958