The field `employee_salary_amount_is_percentage` is computed, but the computation[^1] relies on `hr_employee.salary_distribution`, a field restricted[^2] to members of `hr.group_hr_user`.

If you try to check a bank account without an hr group, you will get an access error:
```
odoo.exceptions.AccessError: You do not have enough rights to access the field "salary_distribution" on Employee (hr.employee). Please contact your system administrator.

Operation: read
User: 21
Groups: allowed for groups 'Employees / Officer: Manage all employees'
```

This also happens during the mock crawl test of upgrades if the admin lacks the group.

To reproduce in standard:
- Install contacts and hr.
- Use a user without hr permissions.
- Try to create a new bank account.

[^1]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/res_partner_bank.py#L26
[^2]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/hr_employee.py#L147
---

I've also added another commit to make the percentage symbol stick to the salary amount.
Before:
<img width="366" height="38" alt="image" src="https://github.com/user-attachments/assets/ef890852-50ca-40b1-8c09-07c4aa2d330d" />
After:
<img width="219" height="35" alt="image" src="https://github.com/user-attachments/assets/88e4a6c4-bc3f-483e-97f9-3080c6aa85c9" />
I know the number is not formated correctly but I don't think I can do more just from the view.

Forward-Port-Of: odoo/odoo#239298

This commit fixes an issue in the Salary Calculator where all fields were displayed as empty when selecting an employee with a resource_calendar_id set.

Steps to Reproduce :
First Change to either the default company (MyCompany) or Demo Belgian company
Payroll -> Employee -> Salary Calculator -> choose an employee.

Bug : All fields in the Salary Calculator view are empty (evaluated as False).

Root Cause :

Inside _compute_salary, the method _generate_salary_simulation_payslip writes on payslip.version_id using:

payslip.version_id.write(new_payslip_vals)

Because the is_simulation_offer key was missing from the context, this write triggered a full payslip computation, generating payslip lines. During this computation, compute_sheet() performs an unlink() on existing payslip lines. Since the Salary Calculator view fields are only cached at that point, the unlink causes the cached values to be lost, resulting in all fields being evaluated as False.

Fix : Ensure that is_simulation_offer is present in the context when writing to payslip.version_id, preventing payslip line generation and avoiding the unintended unlink() during salary simulation.

Task - 5387155

When adding a lot of loyalty programs with discounts to an order the updatePrograms method could be called multiple times in parallel, that would cause an issue where some of the programs were not applied correctly.

Steps to reproduce:
-------------------
* Create 7 loyalty programs that apply on the same product, each with a discount reward of 10%. (Give them different name)
* Create a POS order with 1 unit of that product.
> Observation: Only the 6 first programs are applied.

Why the fix:
------------
The issue is happening because the updatePrograms is called multiple times in parallel, and when coming to this block of code : https://github.com/odoo/odoo/blob/f3e74f9b840efef7c567ba31acd6ac61c79b5d6d/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L182-L188 The last program has 2 coupons in the `couponPointChanges`, so it will proceed to delete all the coupons of the concerned program. To avoid this we use a mutex to ensure that only one call to updatePrograms is happening at a time.

opw-4974788

Forward-Port-Of: odoo/odoo#241023
Forward-Port-Of: odoo/odoo#239662

Steps to reproduce:
-------------------------
- Upgrade from lower version to 19.0 or higher.
- Start a fiskaly registered company's session.
- Close the session after transactions.

Issue:
-------
- Tax mapping used to send data to fiskaly is not set.
- If have `-` in company name or cash move reason and try to do cash move will give a tb.

Cause:
---------
- When the user's database is upgraded, the taxes already exist and the company is already registered. As a result, `l10n_de_vat_export_data` is never set, and since no tax changes occur, `l10n_de_vat_definition_export_identifier` is also not generated. This leads to incorrect values being sent to Fiskaly during the session closing request, causing errors.
- The cash statement name uses - as a separator, the current structure is `{session_name}-{move_type}-{statement_type}-{move_reason}` set from `_prepare_account_bank_statement_line_vals()` If move_reason or company name contains additional `-` splitting the whole name breaks the expected structure.

Fix:
-----
- We have added a check to identify any taxes that are missing their tax mapping If such taxes are found, we filter them and trigger the logic to set their mappings. However, if the main mapping reference value l10n_de_vat_export_data is not set, we first retrieve and update it. Once this reference is available, we update all taxes that were previously unset and then prepare the correct tax data.
As a result, the first session closing after the upgrade will automatically correct all issues both for customers who have already upgraded and for those who upgrade in the future.
- We first remove the `{session_name}-` prefix, then split the rest. Since move_type and statement_type never contain -, we take them directly not user inputs, and then rejoin everything from index 2 onward to reconstruct the correct move_reason.

Additional fixes:
--------------------
- Some places the limit of characters may exceed than what fiskaly is asking than it can give us an error so restricted all places where needed.
- We don't have check if the settlement is present if not getting id directly may cause error.

help ticket: 5362897, 5367425

Forward-Port-Of: odoo/enterprise#101468

### [FIX] html_editor: unwrap blocks when inserting in editable span

When the ancestors of the selection are not elements supposed to contain
blocks when pasting, nothing was done to remove those blocks. This could
lead to `span` elements containing `p` elements for example.

This commit unwraps the blocks in the pasted content if the block
containing the selection is outside of the `contenteditable`
element that contains the selection. It also fixes the function
`makeContentsInline` that was not robust to containing some nodes
structures.

Steps to reproduce:
- Open `example.com`, and copy "Example" from the first block
- Open website builder in translate mode
- Paste
- Bug: The appearance is weird because the pasted title is not styled
  as translation
- Save
- Bug: The span of translation where the text was pasted has been reset

####
- Open `example.com`, and copy the whole content
- Open website builder
- Move cursor to the bottom of the footer, with the company name
- Paste
- Bug: it inserted a `p` element in the `span`

(non deterministic, depends on the mood of the AI)
- Open website builder in translate mode
- Select some text (more likely to trigger the bug if it includes a line
  break, for example the description in the footer)
- Use the "Translate with AI" tool from the toolbar
- Bug: The appearance is weird because the inserted translation is not
  styled as translation
- Save
- Bug: The span of translation where the text was changed has been reset

opw-5053872
opw-5109137
opw-5136337
task-5222402

### [FIX] website: restrict inserted content in translate mode to whitelist

The translate mode of the website builder should only ever insert
nodes with a tag in the `TRANSLATED_ELEMENTS` whitelist or with
`o_translate_inline` class inside a translation span. Doing otherwise
makes the translation span "invalid" according to the server, which
discards the translation.

Blocks are already unwrapped when inserting in translations (by the
previous commit), but some other nodes are not in the whitelist, for
example `img`.

This commit adds the class `o_translate_inline` on `a` elements when
inserted and unwraps nodes that are not in the whitelist and do not have
that class.

Steps to reproduce:
- Open `example.com`, and copy the link "Learn More"
- Open website builder in translate mode
- Paste
- Save
- Bug: The span of translation where the link was pasted has been reset

####
- Copy an image (or a piece of html containing an image)
- Open website builder in translate mode
- Paste
- Save
- Bug: The span of translation where the image was pasted has been reset

opw-5053872
opw-5109137
opw-5136337
task-5222402

Forward-Port-Of: odoo/odoo#240421
Forward-Port-Of: odoo/odoo#237969

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated.

This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation.

The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records.

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **60.00 seconds**
| **After this Commit** | **1.84 seconds**

opw-5150569

Forward-Port-Of: odoo/enterprise#102771
Forward-Port-Of: odoo/enterprise#99096

Issue:
------------------------------------------
When opening deliveries and applying the 'late' filter, the results show:
- All `outgoing pickings`, regardless of whether they are `late` or not, and
- All `late pickings`, regardless of their `picking type`.
In short: `Deliveries OR Late`.
The same issue occurs with other picking types as well.

How to reproduce:
------------------------------------------
1. Install stock.
2. Open deliveries through operations menu.
3. Apply 'late' filter.

Cause of the issue:
------------------------------------------
There is no `seperator` between `picking_type_code` and `date_category` filters,
so OR operator is applied between them.

Solution:
------------------------------------------
Added `seperator` between `picking_type_code` and `date_category`.
which now shows only the outgoing pickings which are late.
In short: `Deliveries AND Late`.
This helps users to apply filters like: Find deliveries that are late.

Task ID: [4614363](https://www.odoo.com/odoo/project/966/tasks/4614363)

Forward-Port-Of: odoo/odoo#201344

Step to reproduce: (try this in 19.0)
- open pos and settle a order
- refund the same order, from payment screen, go back to product screen
- cancel this order
- again try to refund the same order

Observation:
- Blank screen with traceback in console
```
Caused by: TypeError: Cannot read properties of undefined (reading 'state')
at Proxy.reduce (<anonymous>)
at get refundedQty
```

Cause:
- refundedQty() reads refund_orderline_ids.order_id.
- On the first refund cancellation, the refund was deleted but its related order_line was not.
- Order deletion relies on localDeleteCascade, which uses Object.entries() to find related records to delete.
- With lazy getters, this fails because Object.entries() does not expose or execute getter-based properties.

Fix:
- as we already have keys `relationsToDelete`, we pull the value, which execute the getter and we will have the needed data.
- Fixed the test, as for new order, we expect the newer orderline, older ones
    should be deleted.

opw-5379747


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

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated.

This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation.

The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records.

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **60.00 seconds**
| **After this Commit** | **1.84 seconds**

opw-5150569

Forward-Port-Of: odoo/enterprise#102771
Forward-Port-Of: odoo/enterprise#99096

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated.

This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation.

The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records.

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **60.00 seconds**
| **After this Commit** | **1.84 seconds**

opw-5150569

Forward-Port-Of: odoo/enterprise#99096

How to Reproduce : 
1. Remove 'Create' access on the 'Knowledge Article' model for Portal and 
   Internal users.
2. Now log in as a Portal.
3. Try to create a new private article.
4. Log in as an Internal user.
5. Try to create a new private article.

Both Internal and Portal users can still create private articles even after
'Create access' is removed.

Article creation logic in `knowledge.article` was bypassing the usual access
rights because of `sudo` (mainly to add the creator as a member, since creation
rights on the member model are not granted). This allowed users to create
private articles even without create access.

This commit introduces:
1. Model-level access check in `create`. Sudo the creation of articles only when
   the user has create rights.

2. UI imp to hide the '+' button in the sidebar and the `New` button in
   the topbar when the user doesn't have create access.

3. New test cases to verify that model-level access rights are respected when creating an article.

4. Removed 'create=1' from article embedded list view as it was always displaying 'New' button
    irrespective of create rights.
    Now it displayed based on create rights.

task-4916280

Forward-Port-Of: odoo/enterprise#102299
Forward-Port-Of: odoo/enterprise#93034

Steps to reproduce:
-------------------------
- Upgrade from lower version to 19.0 or higher.
- Start a fiskaly registered company's session.
- Close the session after transactions.

Issue:
-------
- Tax mapping used to send data to fiskaly is not set.
- If have `-` in company name or cash move reason and try to do cash move will give a tb.

Cause:
---------
- When the user's database is upgraded, the taxes already exist and the company is already registered. As a result, `l10n_de_vat_export_data` is never set, and since no tax changes occur, `l10n_de_vat_definition_export_identifier` is also not generated. This leads to incorrect values being sent to Fiskaly during the session closing request, causing errors.
- The cash statement name uses - as a separator, the current structure is `{session_name}-{move_type}-{statement_type}-{move_reason}` set from `_prepare_account_bank_statement_line_vals()` If move_reason or company name contains additional `-` splitting the whole name breaks the expected structure.

Fix:
-----
- We have added a check to identify any taxes that are missing their tax mapping If such taxes are found, we filter them and trigger the logic to set their mappings. However, if the main mapping reference value l10n_de_vat_export_data is not set, we first retrieve and update it. Once this reference is available, we update all taxes that were previously unset and then prepare the correct tax data.
As a result, the first session closing after the upgrade will automatically correct all issues both for customers who have already upgraded and for those who upgrade in the future.
- We first remove the `{session_name}-` prefix, then split the rest. Since move_type and statement_type never contain -, we take them directly not user inputs, and then rejoin everything from index 2 onward to reconstruct the correct move_reason.

Additional fixes:
--------------------
- Some places the limit of characters may exceed than what fiskaly is asking than it can give us an error so restricted all places where needed.
- We don't have check if the settlement is present if not getting id directly may cause error.

help ticket: 5362897, 5367425

Steps to Reproduce
===================
1. Upload more than 40+ files in a folder. (One page displays upto 40 docs)
2. Use the checkbox to select all files on the page (this selects only 40 files)
3. Click the 'Select All' button in the control panel to select all 40+ files.
4. Now, try duplicating or moving them to the trash.
=> Only the first 40 selected files (on the single page) are considered for
   action, not all the selected files.

Technical
==========
For documents control panel action we have custom handling for selecting records
and executing action. We use `model.root.selection` which only consider records
in current page, case of select all records from other pages is missed here.

After this PR
==================
- All selected records are considered for the actions
- Added custom `getResIds` method to get filtered `resIds` as per domain.

Note: `getResIds` in DynamicList doesn't have custom domain feature so create
our own as per use case

Task-4700841

Forward-Port-Of: odoo/enterprise#100791
Forward-Port-Of: odoo/enterprise#87634

`point_of_sale`, `pos_restaurant`, `pos_loyalty`, `pos_online_payment`

## Issue 1 - sync issue on shared tables across multiple devices
### Steps to Reproduce:
- Open POS Restaurant in `two devices` (or `two different browsers`).
- On Device 1:
  - Open any table &  click on `Book Table`.
  - Add products & click the `Payment` button. (Do not validate the order)
- On Device 2, open the same table and click on `Release Table`.
- Back on Device 1 & try to add a payment line, partner, or enable Invoice.

### Issue:
 - `TB` will occures `Finalized order can't be modified`

### Fix:
- Properly tracked and synced order, ensured relevant user notifications are shown.
- Fixed TB if customer note not set (it's false value causing TB)

## Issue 2  - prevent traceback when cancelling empty order
### Steps to Reproduce:
- Open Restaurant POS.
- Click on any table.
- Click the Book Table button.
- Reopen the same table.
- Click the Action button.
- Click Cancel Order.
### Issue:
- A traceback occurs because the order is undefined.

### Fix:
- Added a condition to safely handle cases where no order exists.


## Issue 3 - always sync order before online payments in restaurant
### Steps to reproduce:
- Open POS in Restaurant mode.
- Open any table and add a product.
- Return to the floor screen.
- Reopen the same table and add another product.
- Proceed to payment and select an online payment method.
- Click "Validate".

### Issue:
- The "Invalid online payments" dialog appears because the order is partially synced. Due to the current condition, it is not synced again before adding the online payment line, causing the dialog to appear, which is confusing.

### Fix:
- Updated the condition to ensure that in Restaurant mode, the order is always fully synced before allowing online payment lines to be added.

Task: 4788430

When buying a gift card from a POS, the gift card is created without a partner. This is an issue for users who want to see who bought a specific gift card.

In [`pos_loyalty/models/pos_order.py`](https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/pos_loyalty/models/pos_order.py), the `coupon_data` passed to the `confirm_coupon_programs` method does not contain the `partner_id`. This happens because the *Gift Card* program is not considered "nominative", failing the following condition from `pos_loyalty/static/src/overrides/models/pos_store.js`:

https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L795-L801

In fact, the conditions for nominative programs are defined in the `loyalty` module:

https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/loyalty/models/loyalty_program.py#L196-L200

This fix uses the customer's id when there's no `partner_id` in the `coupon_data` coming from the Javascript side. If there's no customer selected when buying the gift card from the POS, `self.partner_id.id` evaluates to `False`, leading to the original behavior: a gift card with no partner.

### Steps to reproduce:
1. Install Point of Sale (`point_of_sale`)
2. In Settings > Point of Sale, toggle *Promotions, Coupons, Gift Card & Loyalty Program*
3. In the POS, open a register
4. On the product screen, select the *"Gift Card"* product and click *Payment*
5. On the payment screen, set the Customer to any customer, pay, and click *Validate*
6. In the POS backend, go to Products > Gift cards & eWallet, click the *Gift Cards* program, and click the *Gift Cards (1)* smart button
7. The gift card we just sold in the POS appears in the list, but there's no Partner assigned to it.

opw-5261991

Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company.

This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket.

Steps to reproduce the issue:
----------------------------
1. Install helpdesk module
2. Create a new company B
3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user
4. Select that new company created in step and go to helpdesk app.
5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team
6. log in as the user created in step 3
7. make usre the company selected is the one created in step 2
8. create a ticket in the helpdesk team created in step 5

Expected behavior:
-----------------
The ticket should be created without any issue.

Actual behavior:
---------------
An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one.

opw-5223717

**Steps to reproduce:**
1. Install l10n_din5008 and purchase modules.
2. Switch the Document Layout template to DIN 5008.
3. Create or open an existing Purchase Order.
4. Print the Purchase Order report.

**Issue:**
The Expected Arrival Date does not appear on the DIN 5008 Purchase Order report. Both functional experts and PO (CHKL) confirmed that the Expected Arrival Date should appear by default on the Purchase Order report in DIN 5008.

**Cause:**
The date_planned (Expected Arrival) field was introduced in standard Purchase
 Order report in v18.0, but DIN 5008 report template was not updated accordingly

**Fix:**
Add the Expected Arrival information to the DIN 5008 Purchase Order template.

Before:
<img width="606" height="162" alt="image" src="https://github.com/user-attachments/assets/e11f5b1f-5898-4ec9-a4f2-087db5dfeced" />

After:
<img width="605" height="147" alt="image" src="https://github.com/user-attachments/assets/57419d00-50c9-4508-9bfc-307c0a54dc67" />


**opw-5376176**