This commit adds a route for Digital Asset Links (`assetlinks.json`)
that link the domain with the Android Mobile App.

Also we adapt some functions authentication/registration so Odoo accept
request origin from the mobile App.
The origin should be `android:apk-key-hash:BASE64(SHA256(APP_SIGNATURE))`

Note: the `/.well-known/assetlinks.json` file should be serve on port
HTTPS (443) without that the Android Digital Asset Links will fail.

Url for debugging Digital Asset Links
https://digitalassetlinks.googleapis.com/v1/assetlinks:check?source.web.site=https://MY-DOMAIN.local&relation=delegate_permission/common.get_login_creds&target.android_app.package_name=com.odoo.mobile&target.android_app.certificate.sha256_fingerprint=D6:73:20:02:CA:2D:01:C9:FD:FC:94:73:5A:D0:73:CF:2C:36:10:29:1F:4B:F7:5D:91:C2:1D:37:B2:18:E8:91

https://developers.google.com/digital-asset-links
https://developer.android.com/identity/passkeys/create-passkeys
https://developer.android.com/identity/credential-manager/prerequisites

opw-6279212

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

Forward-Port-Of: odoo/odoo#270551

**Issue**
Quantity on subcontracted receipts could be overridden after running the
scheduler.

**Steps to reproduce**
- Create a subcontracting product
- Create a PO for 10 units of that product
- Go to receipt and open Subcontracting Productions'
- Change the quantity to 5
- Enable debug mode.
- Run Inventory/Operations/Procurement: run scheduler
- Return to the receipt
-> The receipt quantity is reset to 10 instead of remaining at 5.

**Cause**
Since the refactor introduced in commit: https://github.com/odoo/odoo/commit/fc66e2d4eb638f1486e69cd5920f02c787055da1,
subcontracting receipt moves are no longer automatically picked when the production quantity is modified.
In particular, this test case protects that behavior:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp_subcontracting/tests/test_subcontracting.py#L1629-L1631
When the scheduler runs:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L731
it computes the moves to assign:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L706-L710
However, subcontracting moves are still included in the assignment domain:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L680-L688
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp/models/stock_rule.py#L127-L129
As a result, they are reassigned if they are not already picked:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_move.py#L1931-L1937

opw-6229668

Forward-Port-Of: odoo/odoo#270837

*: website, website_mass_mailing

__Problem__
In some cases, popup snippets can be dropped inside another popup.
This shouldn't be possible. Moreover, it produces the following error:
`TypeError: Cannot read properties of undefined (reading 'after')`.

This can happen in multiple scenarios:
- After saving a custom snippet, the snippets are reloaded but
  `disableUndroppableSnippets` is not called again, although the
  snippets should be filtered again.
- `NewsletterPopupPlugin` registers `.o_newsletter_popup` in the
  `so_snippet_addition_selector` resource, bypassing the more
  restrictive `dropzone_selector` of `PopupOptionPlugin`.
- Popups are not disabled when the cookie bar is open because we don't
  take `excludeAncestor` into account in `DisableSnippetsPlugin`.

__Fix__
- Trigger an event whenever the snippets are loaded and call
  `disableUndroppableSnippets` when it is.
- Remove the redundant `NewsletterPopupPlugin`.
- Filter `dropAreaEls` with `excludeAncestor` in `DisableSnippetsPlugin`.

Forward-Port-Of: odoo/odoo#272273
Forward-Port-Of: odoo/odoo#269864

__To reproduce__
1. Drop a popup on the website.
2. Click twice rapidly on the popup show/hide toggle in the sidebar.
=> The popup visibility will be in an inconsistent state compared
   to the toggle's eye icon.

__Reason__
Bootstrap ignores any call to show/hide if the popup is still
transitioning.

__Fix__
- Set `_isTransitioning` to `false` to trick Bootstrap into firing the
event regardless of its current state.
- When hide/show are triggered in quick succession, the modal can enter an
inconsistent state with `.show` class but `display: none` style (hide removes
`.show` immediately, show restores it with `display: block`, then hide applies
`display: none` after animation). Dispatching `transitionend` event before
resetting `_isTransitioning` ensures Bootstrap completes its state transitions.

__Note__
This commit also fixes `custom_popup_snippet`, which fails
non-deterministically with the following error:
`TypeError: Cannot read properties of undefined (reading 'after')`

This error occurs when trying to add a popup inside another popup
that never closes due to this bug.

runbot-939039

Forward-Port-Of: odoo/odoo#269782

### **Issue**

Self-orders created through the mobile QR menu or kiosk were not displaying table information in the Order Info section of the payment screen.

### **Root Cause**

The Order Details dialog relied on `order.getTable()` to retrieve table information. However, self-orders only store the table reference through `table_id`, which was not properly handled when rendering the dialog, resulting in missing table information.

### **Solution**

This PR introduces the following changes:

* Add a dedicated `getTableInfo()` helper in `pos_restaurant` to retrieve table information from the order.
* Use `getTableInfo()` when building the Order Details dialog fields.
* Allow self-order flows to provide table information through `table_id`, ensuring table details are displayed correctly.

### **Steps to Reproduce**

1. Enable the following options in POS Configuration:

   * QR Menu & Ordering
   * Service at Table
   * Online Payment
2. Open a self-order from the mobile QR menu
3. Select a table and complete the payment
4. Open the POS session
5. Open the paid self-order
6. Click the **Details** button on the right side

### **Video Reproduction**

https://drive.google.com/file/d/138AoJCTF1HNlCGFgk9BRTb0UTai-uXX7/view?usp=sharing

### **Before**

Table information was not displayed in the **Order Info** section for self-orders.

### **After**

Table information is now correctly displayed for self-orders.


opw-6179516


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

Forward-Port-Of: odoo/odoo#271248
Forward-Port-Of: odoo/odoo#264046

Description of the issue/feature this PR addresses:

This error occurs when a model has properties and a `computed` field or `onchange` method depends on them.

`record.update()` is asynchronous. When an onchange or computed field is triggered, an additional request is sent to the server, increasing the time required to complete the update. See:

https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/model/relational_model/record.js#L1207-L1211

However, `PropertiesField` is rendered before the `update` is completed. See:

https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/views/fields/properties/properties_field.js#L86

As a result, the property labels are not yet available and the following traceback is raised:

`TypeError: Cannot read properties of undefined (reading 'getRootNode')
`
After this commit, the update is awaited before rendering PropertiesField, ensuring that the property labels are available.

**Steps to reproduce:**

1. Install the example module. [project_task_property.zip](https://github.com/user-attachments/files/29138424/project_task_property.zip)
2. Open or create a project task.
3. From the Action menu, click `Add Properties`.

The error is raised.

<img width="1520" height="956" alt="image" src="https://github.com/user-attachments/assets/a3051ddf-5af0-4d3a-8ff7-c3fb4f7a69d2" />


TT63331
@Tecnativa @pedrobaeza

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

Forward-Port-Of: odoo/odoo#272653
Forward-Port-Of: odoo/odoo#271082

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.
UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured.

Community PR: https://github.com/odoo/odoo/pull/256932

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

Forward-Port-Of: odoo/enterprise#121779
Forward-Port-Of: odoo/enterprise#112654

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order. Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.

Enterprise PR: https://github.com/odoo/enterprise/pull/112654

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

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

Forward-Port-Of: odoo/odoo#272112
Forward-Port-Of: odoo/odoo#256932

Issue:
----------------------------------------
Doing a search on skills, the employees with the skill but no slot in the time frame aren't shown.

Steps to reproduce:
----------------------------------------
- Install `planning_hr_skills`
- Make sure an employee has the skill "English" and no slots
- Open Planning and type "English" in the search bar, click to search on Skills
- The employee does not show up

Cause:
----------------------------------------
Using the search view on skills, a filter on `resource_ids` is in the domain with a `OR`:

https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/views/planning_slot_views.xml#L9

Then a new filter on `resource_ids` is added [here](https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/models/planning_slot.py#L14-L43) to do the search on the skill names: `[('resource_ids', 'in', matching_resource_ids)]`.

The domain is then something like this: 
`['&', ('resource_ids', 'in', matching_resource_ids), '|', ('resource_ids', '=', False), ('employee_skill_ids', 'ilike', 'English')]`.

Since fbf8b2ac67c71ca0abfc75df543069696bd2d29b the resulting domain passes through `filter_map_domain()`. `filter_map_domain()` will only keep the leaves on `resource_ids` and the default `AND` will be used between them resulting in: 
`['&', ('resource_ids', 'in', matching_resource_ids), ('resource_ids', '=', False)]` 
which fetches no resources.

So `_group_expand_resource_ids()` doesn't expand.

Solution:
----------------------------------------
Instead of adding the new leaf to retrieve the resources with the right skills, we replace the leaf on `employee_skill_ids`. This ensures the `OR` operations are kept by `filter_map_domain()`.

opw-6296755

Forward-Port-Of: odoo/enterprise#120669

Currently, flexible employees can request a multi-day leave spanning a public holiday when the leave type includes public holidays in duration. However, requesting the public holiday date alone is rejected.

### **Steps to reproduce:**
- Create a public holiday.
- Create a time off type with "Public Holiday Included" enabled.
- Select/create an employee with a flexible work schedule and its time zone must be same as admin.
- Request a time off on the public holiday date only.

### **Observed Behavior:**
The request is rejected because its duration is computed as 0 days.

### **Expected Behavior:**
The request should be allowed and count as 1 day, consistent with the multi-day request behavior.

### **Root Cause:**
At [1], a dedicated duration computation path is used for single-day leaves of flexible employees. This logic always retrieves overlapping public holidays and computes the leave duration based on the remaining intervals. As a result, a leave requested entirely on a public holiday is computed as 0 days, even when `include_public_holidays_in_duration` is enabled.

[1]- https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/hr_holidays/models/hr_leave.py#L436-L444

### **Fix:**
This commit ensures that the `include_public_holidays_in_duration` setting is taken into account when computing single-day leave durations for flexible employees

**opw-6284768**

Forward-Port-Of: odoo/odoo#272217
Forward-Port-Of: odoo/odoo#269743

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#121837
Forward-Port-Of: odoo/enterprise#120967

Currently, an error occurs when a user insert a dynamic product snippet onto website.

**Steps to Reproduce:**

 - Install `website_sale` without demo data.
 - Go to `Website` > `eCommerce` > `Products` > `Ribbons`.
 - Open any ribbon and set `Assign` to `When New`.
 - Go to the `Website` > `Edit` > drag and drop the `Catalog` block, and select a `Dynamic Product` 
   block (`Generic Product Template (customizable)` [ref](https://drive.google.com/file/d/1ZYeQA8DhfYAf_jbPwL-tZXaVi1YAyFbd/view?usp=drive_link)).

`TypeError: unsupported operand type(s) for -: 'datetime.datetime' and 'bool'`

After this [recent commit], when a user drops a dynamic product snippet, the system attempts 
to set the ribbon value [1]. If no product records are available, it falls back to using sample products [2]. 
These sample products are virtual records created with model.new() [3] [4] and are not stored in 
the database, so they do not have a publish date.
When auto-assigned ribbon with the When New option assign, the system compares the ribbon's 
new period with the product's publish date. Since the sample products do not have a publish 
date, this comparison raises an error [5].

This commit ensures that the comparison between new period and publish date is only 
performed when the product has a valid publish date.

[recent commit]: https://github.com/odoo/odoo/commit/f427f795c24ee37ee02302642b77bfc314a9ea43

[1]- https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website_sale/templates/snippets/product_snippet_template_data.xml#L52-L58

[2]: https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website/models/website_snippet_filter.py#L75-L78

[3]- https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website/models/website_snippet_filter.py#L210-L215

[4]: https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website_sale/models/website_snippet_filter.py#L62-L95

[5]: https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website_sale/models/product_ribbon.py#L121-L124

sentry-7528296918

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

Forward-Port-Of: odoo/odoo#268836

Issue:
Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference"

Steps to reproduce on any database with DIAN and Colombian localization:

  1. Create a new "Sales" type journal. Then, check the checkbox “Nota de Debito”.
  2. Find a res.partner with a ref field, or add a ref field to any partner.
  3. Make an invoice using the partner found in step 2. Ensure it uses a tax. Confirm it.
  4. Send that invoice to DIAN.
  5. Create a Debit Note for that invoice. Use the journal created in step 1.
  6. Add a product, price, and tax to the debit note. Confirm it.
  7. Send the debit note to DIAN.
  
Explanation:
The `_add_invoice_header_nodes` method on the AccountEdiXmlUbl_21 model adds a BuyerReference node unconditionally. (See account_edi_xml_ubl_21.py.) But the DebitNote XML template does not include a BuyerReference element (see ubl_21_debit_note.py). This caused a ValueError when assembling the XML for debit note documents.

Solution: The fix overrides this in the Colombian localization by clearing the BuyerReference value when the document type is "debit_note". That way, the node is omitted from the output.

opw-6181039

Forward-Port-Of: odoo/enterprise#121458
Forward-Port-Of: odoo/enterprise#121422

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Put your warehouse in delivery in 2 steps
- On the receipt operation type change the return operation type to be "pick" by default.
- Create and confirm a PO for 1 unit of P
- Validate the receipt > return > Create the return for 1 unit
- Change the operation type of the return from Pick to Delivery to return the product in one step.
- Validate the return
#### > The qty_received is updated from 1 to 2 instead of 0.

### Cause of the issue:

Updating the `picking_type_id` of the return will also update the `location_dest_id` to the default values:
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/stock/models/stock_picking.py#L1138-L1147
However, the default values of the `Delivery` is "Partner/customer". As such, the location dest of the move is also updated to be "Partner/customer". Now the issue is that the `qty_received` only considers moves to be returned if the location dest usage is not 'supplier':
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase/models/purchase_order_line.py#L226-L231 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L55-L67 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L76-L77 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/stock_move.py#L129-L131

opw-6292918

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

Forward-Port-Of: odoo/odoo#270571
Forward-Port-Of: odoo/odoo#269867

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/e359501309 [REL] 19.4.1 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5adffa5ca1 [FIX] config: bump node version in GH action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/feea883b1d [IMP] pivot: give full dimension to pivot normaliser [Task: 6023622](https://www.odoo.com/odoo/2328/tasks/6023622)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Description of the issue/feature this PR addresses:

The actual XML extraction hardcoded the double-zipped case by reading only
   the first entry of the outer zip (`zip_file.infolist()[0]`), assuming it
   was always a nested zip containing the XML.

This made it fail when:
- The XML was directly in the outer zip (single-zipped).
- The zip contained multiple files and the first nested zip didn't hold the XML.

Current behavior before PR:
After sending an Invoice to Viettel S-Invoice, the e-Invoicing platform would return a ZIP containing one XML file.
The XML File being double-unzipped, a traceback is raised.

Desired behavior after PR is merged:

The fix rewrites _recursive_zip_xml_file_data to actually be recursive. Invoices can be sent to Viettel S-Invoice without raising a traceback.

opw-[6249929](https://www.odoo.com/odoo/project.task/6249929?debug=1)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#272121
Forward-Port-Of: odoo/odoo#268482

### Issue:
When printing the Planning report (PDF) and grouping by a field other than Employee (e.g., Role, Project, or a Char/Selection field), the server crashes with a `TypeError` or `AttributeError`.

### Cause:
The `action_print_plannings` method hardcoded the assumption that the `group_by` key would always be a `resource.resource` recordset.
1. When the user grouped by other fields, it returned strings, booleans, or empty recordsets, causing crashes when the code blindly called `.id` and `.display_name`.
2. During the sorting phase, mixing `False` (for unassigned empty recordsets) with strings caused a `TypeError`.
3. For multi-day shifts, the method failed to extract the actual resource to calculate the shift splits if the grouping was not explicitly set to `resource_ids`.

### Fix:
- Implement safe attribute checks (`hasattr`) when extracting group IDs and display names.
- Ensure unassigned empty recordsets properly fall back to the "Undefined" string and empty strings during sorting to prevent TypeErrors.
- Universally fallback to extracting the resource directly from the slot (`slot.resource_ids[:1]`) for multi-day time splitting when grouped by non-resource fields.
- Add a unit test to ensure stability when grouping by `role_id` with multi-day shifts.

Task: 6244057

Forward-Port-Of: odoo/enterprise#118530

In POS Restaurant with Germany Fiskaly enabled, splitting and paying from a table works once, but repeating the same flow from the Orders tab lets the parent order show lines that were already paid in previous splits. Functionally, the cashier can keep splitting and paying the same line again and again because the parent draft order is not updated consistently in that path.

Steps to reproduce:
-------------------
* Enable POS Restaurant with l10n_de Fiskaly
* Create a table order (e.g. 3 meals + 3 drinks)
* Open Split Bill, move 1 meal + 1 drink, and pay
* From Orders tab, open the remaining parent order and repeat split + pay
* Reopen the parent order from Orders tab

> Observation:
The parent order still contains quantities that were already split/paid, so the same items can be paid multiple times from the Orders tab.

Why the fix:
------------
The Fiskaly `syncAllOrders` override diverged from core sync behavior in the split flow: it ignored explicit `options.orders` and did not await transaction creation for inactive transactions. In the split-bill path this could skip or desynchronize parent-order updates, leaving stale quantities on the parent order.
The fix restores expected sync semantics by honoring `options.orders` and awaiting transaction creation before deciding sync eligibility.

opw-6175880

Forward-Port-Of: odoo/enterprise#117206

Currently, an error occurs when a user tries to create a group time off.

**Steps to Reproduce:**
 - Install the `hr_presence` module without demo data.
 - Go to `Employees` > `Configuration` > `Working Times` > `Time Types` and 
   delete all records.
 - Make sure there are at least `two employee` records.
 -  Go to `Employees` and switch to the `list view`.
 - Select `both employees` > click `Presence Control` > click `Create a Time Off`.

**Error1:**
`TypeError: unsupported operand types in: hr.work.entry.type() | None`

**Error2:**
`AttributeError: 'NoneType' object has no attribute 'ids'`

When a user creates a group time off record and the wizard is opened, it computes the valid work 
entry types. If no work entry type exists, accessing the `True` key (`requires_allocation`) from the 
empty dictionary returns None [1]. Later, when performing a union (|) between an empty work entry 
type recordset and None, it raises the first error [2]. Additionally, accessing ids on None raises 
the error [3].

This commit ensures that when no work entry type exists, accessing key(requires_allocation) from 
an empty dictionary returns an empty work entry type record instead of None.

[1]- https://github.com/odoo/odoo/blob/374f48cfba75ff98f53d8c3fcc51847711bd406a/addons/hr_holidays/wizard/hr_leave_generate_multi_wizard.py#L144-L145

[2]- https://github.com/odoo/odoo/blob/374f48cfba75ff98f53d8c3fcc51847711bd406a/addons/hr_holidays/wizard/hr_leave_generate_multi_wizard.py#L146

[3]: https://github.com/odoo/odoo/blob/374f48cfba75ff98f53d8c3fcc51847711bd406a/addons/hr_holidays/wizard/hr_leave_generate_multi_wizard.py#L148

sentry-7552717400

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

Steps to reproduce:
1. Install sale_crm and sale_renting_crm
2. Create an opportunity
3. On this opportunity, create two quotations from the `New quotation` button
4. From the opportunity's form view, click on the `Quotation` smart button

Issue:
- The quotations are not visible in the list view

Why?
- In module `sale_renting_crm`, we override the domain to exclude rental quotations.
https://github.com/odoo/enterprise/blob/fda037c62a6661665611fb061718c01aec39ac1b/sale_renting_crm/models/crm_lead.py#L33-L36 But from the saas-19.3 `is_rental_order` field is no longer stored in the DB, It is computed now and filtered through  `_search_is_rental_order`. 
https://github.com/odoo/enterprise/blob/fda037c62a6661665611fb061718c01aec39ac1b/sale_renting/models/sale_order.py#L223-L227 The search method did not properly handle the Boolean search shape used by the ORM, so the quotations were incorrectly filtered out. In our case, we gave the domain `("is_rental_order", "=", False)` but the operator is translated to `not in` and value to `Orderedset([True])` by the domain optimiser

Solution:
- Update `_search_is_rental_order()` to handle the ORM-normalized boolean search correctly for rental and non-rental quotations.

opw-6304696

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/040ae04f23 [REL] 19.3.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/37a0a7031f [FIX] config: bump node version in GH action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3412fa57da [IMP] pivot: give full dimension to pivot normaliser [Task: 6023622](https://www.odoo.com/odoo/2328/tasks/6023622)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Issue:
---
Not having at least one variant created for a product template with
dynamic attributes can cause issues as it's expected a product template
to have at least one variant.

To reproduce:
1- Create a dynamic attribute with values.
2- Create a product and without saving:
 - Enable track inventory.
 - Add the dynamic attributes and values.

3- Save the product.
4- Click on forecasted quantity smart button:
 - There is a traceback.

5- Click on Replenish:
 - Unexpected behavior.

6- Click on `Product On Hand Quantity`:
 - No product will be shown if you try to add quantity.

Cause:
---
This is caused because there is no variant created. In the steps,
if you save the template once before adding dynamic attributes, a
single variant will be created which allows it to work without issue.

Fix:
---
we can fix the TB by hiding the forecasted qty smart button,
when there is no variant.

However, there will be still issue with `Replenish` flow, which
requires a variant. We could do the prevent the issue by ensuring
there is at least one variant.

opw-6260253

Forward-Port-Of: odoo/odoo#272943
Forward-Port-Of: odoo/odoo#268879

**Steps to Reproduce:**
-  Create a Server Action of type 'Webhook Notification'.
- Select a model containing a field that returns a `frozendict`-based structure (e.g. `account.move` → `needed_terms`).
- Add the field to the webhook fields.
- Open the webhook sample payload preview.

**Issue:**
- During sample payload generation:
   - The selected fields are read from a sample record.
   - A selected field returns a structure containing `frozendict` objects.
   - The payload is serialized using `json.dumps()`.
   - JSON serialization fails with:
```text
TypeError: keys must be str, int, float, bool or None, not frozendict
```
  - The webhook sample payload computation crashes and the preview cannot be displayed.

**Root Cause:**
- The webhook sample payload may contain `frozendict` objects returned by selected fields.
- The serializer used for payload generation does not handle such mapping-like objects, causing  `json.dumps()` to fail.

**Solution:**
- Use a serializer that converts mapping-like objects into JSON-compatible structures before serializing the webhook sample payload.

**OPW-6295777**

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#272324
Forward-Port-Of: odoo/odoo#271864

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/3529978d50 [REL] 19.2.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/156b8921dc [FIX] config: bump node version in GH action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/f3ae8587f9 [IMP] pivot: give full dimension to pivot normaliser [Task: 6023622](https://www.odoo.com/odoo/2328/tasks/6023622)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/44237c04a0 [REL] 19.1.26 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/ac1974039f [FIX] config: bump node version in GH action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9fa87aa588 [IMP] pivot: give full dimension to pivot normaliser [Task: 6023622](https://www.odoo.com/odoo/2328/tasks/6023622)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Create a new vendor bill with:
  - Vendor: GT Company
  - GT Document Type: `FESP`
  - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines.
- `Confirm` the bill and `Send to SAT`.
- From the gear icon, click `Download` > `PDF`.

**Error1:**
`KeyError: 'gran_total'`

**Error2:**
`KeyError: 'retencion_grand_total'`

**Root Cause:**
In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` 
before `_l10n_gt_edi_add_withholding_values()`. However, 
`_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is 
initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`.

Additionally, the report template at [3] references `retencion_grand_total` 
instead of the correct key `retencion_gran_total`, causing another `KeyError`.

**Fix:**
This commit prevents errors and ensures users can successfully download 
the PDF by applying a fix similar to [4],

[1]:
https://github.com/odoo/enterprise/commit/44afd19e4ed0827e343af0e584c81e579935c9e8

[2]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328

[3]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72

[4]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800

opw-6323049

Forward-Port-Of: odoo/enterprise#122030

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Create a new vendor bill with:
  - Vendor: GT Company
  - GT Document Type: `FESP`
  - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines.
- `Confirm` the bill and `Send to SAT`.
- From the gear icon, click `Download` > `PDF`.

**Error1:**
`KeyError: 'gran_total'`

**Error2:**
`KeyError: 'retencion_grand_total'`

**Root Cause:**
In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` 
before `_l10n_gt_edi_add_withholding_values()`. However, 
`_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is 
initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`.

Additionally, the report template at [3] references `retencion_grand_total` 
instead of the correct key `retencion_gran_total`, causing another `KeyError`.

**Fix:**
This commit prevents errors and ensures users can successfully download 
the PDF by applying a fix similar to [4],

[1]:
https://github.com/odoo/enterprise/commit/44afd19e4ed0827e343af0e584c81e579935c9e8

[2]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328

[3]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72

[4]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800

opw-6323049

Forward-Port-Of: odoo/enterprise#122030

### Issue:
When printing the Planning report (PDF) and grouping by a field other than Employee (e.g., Role, Project, or a Char/Selection field), the server crashes with a `TypeError` or `AttributeError`.

### Cause:
The `action_print_plannings` method hardcoded the assumption that the `group_by` key would always be a `resource.resource` recordset.
1. When the user grouped by other fields, it returned strings, booleans, or empty recordsets, causing crashes when the code blindly called `.id` and `.display_name`.
2. During the sorting phase, mixing `False` (for unassigned empty recordsets) with strings caused a `TypeError`.
3. For multi-day shifts, the method failed to extract the actual resource to calculate the shift splits if the grouping was not explicitly set to `resource_ids`.

### Fix:
- Implement safe attribute checks (`hasattr`) when extracting group IDs and display names.
- Ensure unassigned empty recordsets properly fall back to the "Undefined" string and empty strings during sorting to prevent TypeErrors.
- Universally fallback to extracting the resource directly from the slot (`slot.resource_ids[:1]`) for multi-day time splitting when grouped by non-resource fields.
- Add a unit test to ensure stability when grouping by `role_id` with multi-day shifts.

Task: 6244057

Forward-Port-Of: odoo/enterprise#118530

Currently, accounts with the `Other Expenses` account type cannot 
be selected in financial budget lines.

**Steps to reproduce:**
- Install the `accountant` module.
- Go to `Chart of Accounts` and create a new account with `Type: Other Expenses`.
- Go to Accounting > Configuration > Financial Budgets.
- Create a new budget and add a budget line.
- Try to select the newly created account.

**Observation:**
Accounts with the `Other Expenses` type are not
available for selection in budget lines.

**Root Cause:**
At [1], the `expense_other` account type is missing from the `account_id` domain.

**Expected Behavior:**
Financial budgets should allow all Profit & Loss accounts, since the feature relies on P&L reporting.

**Reference**: https://www.odoo.com/odoo/project/49/tasks/4314709

**Fix:**
This commit ensures that users can add `Other Expenses` accounts to budget lines.

[1]:
https://github.com/odoo/enterprise/blob/41b66ba081f3938f7e55da209506c637850ae4ec/account_reports/models/budget.py#L114-L120

opw-6313835

Forward-Port-Of: odoo/enterprise#121735

Issue 1:
======
Numpad Visibility in TicketScreen of draft urban piper orders

Steps to reproduce:
===================
- Ensure `pos_hr` and `pos_urban_piper` is installed.
- Install `l10n_in_pos_urban_piper`.
- Open a draft Urban Piper order and notice that the numpad is visible.

Cause:
======
- The numpad visibility depends on a `t-if` condition in XML.
- Due to the asset loading order, this condition gets overridden by another
module.

Fix:
====
- Move the visibility logic to a getter method.
- Override the getter in other modules instead of using XML to control the
visibility.
- Also fixed the css issue for prep order time input when using it in dark
mode
---
Issue 2:
======
Invoice button visible on Chile Company's TicketScreen

Steps to reproduce:
===============
- Ensure `pos_urban_piper` is installed, open the Chile company's PoS Config
- In the ticket screen, we have an invoice button on paid orders.

Cause:
=====
- Button visibility handled through XML conditions; this condition gets
overridden by another module.

Fix:
===
- Move the visibility logic to the getter method and override it in submodules
to control visibility.

Task-6299415
Related Community PR: https://github.com/odoo/odoo/pull/270088

Forward-Port-Of: odoo/enterprise#120571

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/1a9c76131c [REL] 18.0.73 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9512d92c70 [FIX] config: bump node version in GH action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5edfaee5e4 [IMP] pivot: give full dimension to pivot normaliser [Task: 6023622](https://www.odoo.com/odoo/2328/tasks/6023622)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

When an orderpoint fails during a portal user's transaction (e.g., eCommerce checkout), the system catches the `Procurement Exception` and logs a warning activity on the product template. The exception handler uses `.sudo().activity_schedule()`, which bypasses the write access restriction but leaves `env.uid` as the portal user.

Therefore, the restricted portal user permanently becomes the `create_uid` (Author) of the activity.

System exception activities should always be authored by the system (OdooBot), never by a portal or public user. This context leak corrupts the activity metadata by injecting an external user ID into internal backend logs. Chain `.with_user(SUPERUSER_ID)` to the `.sudo()` call in `stock_orderpoint.py` when scheduling the exception activity.

This ensures the environment context is stable and the activity is authored by OdooBot, which transcends multi-company record rules.

Steps to Reproduce on Runbot/Fresh Database on version 17.0:
1. Enable Multi-Company with Company A and Company B. Set Company B as the active company for the website.
2. Restrict the main Admin (Runbot) user strictly to Company A.
3. Create a Shared Product (Company field left blank).
4. Set a Reordering Rule (Orderpoint) for the product that is guaranteed to fail routing.
5. Navigate to the frontend website and sign up as a new user (this creates a Portal User in Company B).
6. As the newly signed-up Portal User, complete an eCommerce checkout for the shared product.
7. The checkout succeeds, but the backend triggers the orderpoint failure and logs the exception activity on the product template.
8. Check the chatter for this product: the `create_uid` is incorrectly set to the Portal User instead of OdooBot (1).
9. (In 19.0 Upgrade) Log in as the Admin user (set strictly to view Company A), navigate to the product, and the AccessError for reading will appear due to this leaked id.

[opw-6253978](https://www.odoo.com/odoo/my-support-tasks/6253978?debug=assets)


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