## Summary

Minimal alternative: make the "Inventory at Date" wizard open the same rich stock report view instead of the basic one.

### Problem
The wizard opens `stock.view_stock_product_tree` (basic product list) instead of `stock.product_product_stock_tree` (full stock report with action buttons and search panel).

### Solution
Change the wizard's `open_at_date()` to use the stock report view and its associated search view. The wizard flow is preserved — this is purely a view swap.

### Changes
- `stock_quantity_history.py`: Changed `tree_view_id` from `view_stock_product_tree` to `product_product_stock_tree`, added `search_view_id` for the stock report search view

### Alternative
See #263507 for a more integrated approach that replaces the wizard entirely with a date picker in the search panel.

[Task #6152466](https://www.odoo.com/odoo/rd-fun-logistics-966/6152466)

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

Forward-Port-Of: odoo/odoo#263509

### Description of the issue/feature this PR addresses:

The stock move value was inline-editable in the moves list, which is
misleading. Editing it directly behaves inconsistently across cost
methods: for FIFO products the edit updates the remaining value, but
for AVCO products there is no mechanism to propagate it, so the change
has no effect. The direct edit also bypasses the audited revaluation
channel, the Adjust Valuation wizard (product.value), which records the
user, date and justification.

Disable direct modification by marking the field read-only by default,
so manual revaluation always goes through Adjust Valuation. Internal
valuation writes are unaffected.

### Current behavior before PR:

The value field is editable in the stock move list view.

<img width="1890" height="460" alt="image" src="https://github.com/user-attachments/assets/8ddc6495-4beb-4481-bdbf-2a44b70f3784" />

### Desired behavior after PR is merged:

The value field should not be editable. Users should use the Adjust Valuation wizard to ensure the operation is auditable.

@qrtl QT6826

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

Forward-Port-Of: odoo/odoo#267360

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

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>

A tax created without a fiscal position (empty fiscal_position_ids) is conceptually an "All" tax: it should apply across every fiscal position, including the empty ones used for tax units.

Problem

map_tax drops every tax when the FP has no mapping, including the "All" ones that should pass through.
action_open_related_taxes only lists the FP's tax_ids, so "All" taxes are invisible from the FP form.
The Taxes stat button is hidden whenever the FP has no tax_ids.
action_update_fpos_values invokes the field computes directly, so tax and balance lines fall out of sync after an FP change.

Fix

map_tax: when the FP has no tax_ids, return the input taxes whose fiscal_position_ids is empty (the "All" ones) instead of an empty recordset.
action_open_related_taxes: extend the domain to also include taxes bound to no fiscal position.
partner_view: drop the invisible="not tax_ids" guard on the Taxes stat button.
action_update_fpos_values: route the deferred computes through _check_balanced and _sync_dynamic_lines so tax lines stay in sync after the update.

task-id [6231514](https://www.odoo.com/odoo/project/967/tasks/6231514)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#272350
Forward-Port-Of: odoo/odoo#268273

### Steps to reproduce:
- Download Calendar and Contacts app
- Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies
- Go to the Setting -> Users -> Manage users; make sure the current logged-in user has access to both companies
- Create a another user who also have access to both companies
- Search for the new user in contacts -> Assign the current company to the contact -> Through the internal link of the company, go to sales and purchase tab -> assign the same company in the company field
- Switch the company of the logged in user to the other company
- Open the test contact form, use the meeting smart button and create a new meeting
- Open the kanban contact view

 **> Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.**
### Cause of Issue:
When trying to view the search results in kanban view, the `meeting_count` is calculated for each contact. Hence,`_compute_meeting_count()` is called which calls `_compute_meeting()`. https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/calendar/models/res_partner.py#L49-L54 Since the above section tries to access `partner.parent_id` each loop, it reaches a `parent_id` that's not accessible for the current user.

### Fix:
Since we need to access `parent_id` to be able to calculate meeting count for the full tree of partners, `sudo()` is used to get all partners, but meetings are computed for ancestors who are in `self_ids` only so that we still remain within scope.
Same old logic is used to propagate meetings for every ancestor, but dictionary lookups are used to enhance performance.

opw-5874204

Forward-Port-Of: odoo/odoo#272832
Forward-Port-Of: odoo/odoo#248985

Steps to reproduce
------------------
1. Set a default tax on the "Cash Difference Gain" account (e.g. a 25%
   sales tax) -- required in some countries like Denmark (cf 5972690).
2. Open a PoS session, count more cash than expected at closing.
3. Try to close the session.

-> Error message shows up "The journal entry reached an invalid
state..." ... "The journal entry must always have exactly one journal
item involving the bank/cash account"

What's happening
----------------
PoS creates a bank statement line with the gain account as counterpart,
resulting in 2 lines: cash +10, gain -10. Since the gain account has a
default tax, `_sync_tax_lines` adds a tax line of -2.5 on top, which
makes the move unbalanced by 2.5. Then `_sync_unbalanced_lines` adds a
4th line to fix it, on the line returned by
`_get_automatic_balancing_account`, which is `journal.default_account_id`,
i.e. the cash account itself for a cash journal.

So we end up with 2 lines on that same cash account, which a bank
statement line move doesn't allow -> Error.

The fix
-------
In `_post_statement_difference`, precompute the base and tax split
ourselves and build the statement line's `line_ids` directly (e.g. for
+10 and a 25% tax: cash +10, gain -8, tax -2). The move is balanced
from creation, so `_sync_tax_lines` and `_sync_unbalanced_lines` don't
have to touch it.

Note that we force the tax computation to be in 'force_price_include'
mode, as the counted cash difference is a gross amount (physical money
in the drawer). This way the tax is always extracted from the cash
amount, regardless of how the tax is configured (included or excluded
in price). Same pattern is already used by `hr_expense` (cf
`hr_expense.models.account_move_line._compute_totals`).

opw-5972690

Forward-Port-Of: odoo/odoo#271921
Forward-Port-Of: odoo/odoo#257892

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

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>

#### Description of the issue this PR addresses:
- When an emoji shortcut ending with `/` (e.g. `:/` for 😕) is typed, the emoji plugin replaces the characters before the powerbox `on_input_handler` runs. Since `ev.data` still reflects the original typed `/`, the powerbox was incorrectly opening.
- Emoji shortcuts works only when it is used at the end of a text node, because the matching logic checked the whole remaining substring from the current position.
- Sometimes, pressing Backspace splits one text node into two, and then an emoji shortcut works at the end of the first text node even when the paragraph is visible as a single line.

#### Desired behavior after PR is merged:
- Check the DOM character at cursor position instead of `ev.data` to determine whether `/` is actually present before opening the powerbox.
- Emoji shortcuts now works when used with a preceding space anywhere in the paragraph.

Enterprise PR-https://github.com/odoo/enterprise/pull/118310
task-6243724

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

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d00e4b62c5 [REL] 18.3.54 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/722416eaf1 [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/5c888b116c [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 rating module does not correctly extend the mail modules onClick for NotificationItem

Current behavior before PR:
* mail NotificationItem onClick calls `this.onClickThread(isMarkAsRead, thread, message)`
* rating NotificationItem onClick calls `this.onClickThread(isMarkAsRead, thread)`
  * causing the [if in onClickThread](https://github.com/odoo/odoo/blob/18.0/addons/mail/static/src/core/public_web/messaging_menu.js#L39C17-L39C24) to be missed and falling backup to opening the thread
     ```javascript
            if (message?.needaction && message.message_type === "user_notification") {
                this.store.inbox.highlightMessage = message;
                this.openDiscussion(this.store.inbox);
                return;
            }
            this.openDiscussion(thread);
            return;
     ```

Desired behavior after PR is merged:
* rating should not change the fallback behaviour for messages without a rating_id and still allow opening the user_notification in inbox instead of switching to the thread

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

Info @wt-io-it

Forward-Port-Of: odoo/odoo#244521

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and `path@test.com`)
3) Generate offer and sign with all the required signer(applicant and Marc Demo). 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as `john@example.com`).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as `path@test.com`)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

opw-6280170

Forward-Port-Of: odoo/enterprise#120566

Currently, an error occurs on an invoice when user selects a payment term and removes the currency.

Steps to replicate:
- Install account
- Turn on multiple currencies
- Open invoices.
- Create a new invoice 
- Add a line
- Add a customer
- Save
- Select payment term as `30% Now, Balance 60 Days`
- Remove the currency.

Error:
```
ValueError: Expected singleton: res.currency()
```

Cause:
- This error only occurs when the selected payment term contains at least two due term lines [1].

- When the selected payment term has atleast two lines the check [1] assigns `on_balance_line` as  false and the `else` block is evaluated where currency being an empty recordset (as the user removed it) causes the error from [line] when trying to perform `round()` on an empty res.currency recordset.

Solution:
- As the currency is a required field, user will not be able to save the record until a currency is assigned.

- Used journal's currency or company's currency as a fallback when computing payment terms if the current currency is empty.


[1]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L229

[line]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L240

sentry-7569922293

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

Forward-Port-Of: odoo/odoo#272073

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

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

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

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