Since this change: https://github.com/odoo/odoo/pull/185674/commits/b663a6e3dbda6eda84e4a6b051acfc8511476cd3#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR503 It introduces two bugs:
- Create a project A and project B, activate the top bar in both projects
    - Create a new custom embedded action in project A
    - Switch to project B (by changing the URL), the custom action of project A is present in project B
- In a project, create a new custom embedded action, refresh the page, the action is not visible nor available in the top bar.

It enters the if condition, and get the "lastAction", which may not contain the same "embedded_action_ids" than the current action (targeting another project or the same project if we just refreshed the page). It enters the condition because the path of the action is the same ("tasks") and no "active_id" is specified in the context of the action.

We then force the load of the action if the "lastAction" stored in the browser session had embedded actions, to be sure to get the latest embedded actions linked to the current action in case of any, and not keep the ones linked to "lastAction".

task-5269261

Forward-Port-Of: odoo/odoo#240558
Forward-Port-Of: odoo/odoo#237695

When the user copies a range of the html in the page, they may copy
nodes with attributes that mark them to be saved. This happens if they
select around a savable node, or if they select inside a savable node
and the format plugin include clones of the ancestors (to keep matching
style).

This commit prevents that by not copying clones at the ancestor which
sets `contenteditable` to true (if any), and by treating copy with a
selection outside of `contenteditable` the same as a foreign copy (for
which any non-whitelisted attributes are removed).

Steps to reproduce:
- Open website builder
- Select a link of the menu in the header
- Copy
- Move the selection to "normal" text (like in the footer)
- Paste
- Save
- Bug: the website cannot render

### 
- Open website builder in translate mode, on a blog post
- Select a word in the middle of a paragraph
- Copy
- Paste
- Bug: The paragraph gets replicated inside itself

### 
- Open website builder in translate mode, on a blog post
- Select from the author name to the first paragraph
- Copy
- Paste inside the paragraph
- Bug: The paragraph gets replicated inside itself

opw-5053872
task-5222402

Forward-Port-Of: odoo/odoo#236974

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#240639
Forward-Port-Of: odoo/odoo#239662

Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos.

Steps to reproduce:
-------------------
* Set max closing difference as 0
* Have 1 admin user and 1 pos user
* Have 2 employees
* Set admin user and employee 1 as advanced employees of the pos
* Set pos user and employee 2 as basic employees

Steps with admin:
* Make sure you are logged as the admin in the database
* Open pos (could be a session opened by other user)
* Log in with Admin user
* Try to close the pos with a difference of 10 -> You can, ok
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You ca but shouldn't

Steps with pos user
* Now log in the database as pos user
* Open pos (could be a session opened by other user
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You cannot, ok
* Log in with Admin user
* Try to close the pos with a difference of 10 -> you cannot but should

Why the fix:
------------
Employees that have no linked user should not ba able to override the max difference.

Employees who have a connected user should only be able to override the max difference if their user is admin of the pos.

opw-5184041

Forward-Port-Of: odoo/odoo#240133
Forward-Port-Of: odoo/odoo#235356

**Current behavior before PR:**

- When dragging and dropping elements with attributes and classes, any non-whitelisted attributes and classes were removed during the `cleanForPaste` process. This caused structural issues and loss of formatting after the drop.

- When an image had a caption and only the image was selected and cut, the image was removed but the caption incorrectly remained

- When dragging and dropping an image without an active selection on the image, the image was not removed during the drop. This resulted in the image being duplicated, one at the original position and another at the drop location.

- When selecting an image with a caption and performing copy-paste, only the image was copied and pasted.

**Desired behavior after PR is merged:**

- An `application/vnd.odoo.odoo-editor` dataTransfer type is now set during `dragstart` for editor elements. As a result, we no longer need to clean the `dataTransfer` content during drop, preserving the original structure and preventing the loss of attributes and classes.

- Cutting an image that contains a caption now correctly removes both the image and its associated caption.

- The image is now selected on pointerdown event . As a result, when the image is dropped, deleteSelection correctly removes the original image before inserting the new one, preventing duplication.

-  Now, when an image with a caption is selected and copy-pasted, the entire image along with its caption is correctly copied and pasted.


task: 4914451

Forward-Port-Of: odoo/odoo#217125

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.

**Steps to reproduce:**
- enable "packages" and "batch transfers" settings
- open wharehouse management/operation type
- select internal transfer
- check "automatic batch" and group by "contact"
- create two storable product with an on hand quantity of 10
- create a an internal transfer for the first product for a qty of 10
- mark it as to do
- do the same for the second product and make sure that it's the same 
contact
- open barcode and select batches
- select the last batch created
- scan WH-STOCK
- enter and confirm a quantity of 4 for each line
- click on put in pack
(at this step we can already see that the two new lines created are 
associated wit the second picking, even though it should be one line 
per picking)
- click on the +6 on each line and click on put in pack
- validate

**Current behavior:**
- a back order has been created for the first picking
- the first internal transfer has only delivered 4 units of the first 
product
- the second internal transfer has delivered 10 of the second product 
and 5 of the first product

**Expected behavior:**
both pickings should have delivered 10 of their product

**Cause of the issue:**
The lines created when clicking on "put in pack" for the first time
are both associated with the second picking because the line split:
https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514
and the picking_id of the new line is set to the values provided by the
`_getNewLineDefaultValues` as the picking_id of the last selected `line`:
https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281
rather than from the values of the initial line it is split from.

opw-4952964

Forward-Port-Of: odoo/enterprise#102575
Forward-Port-Of: odoo/enterprise#91378

Before this commit, when the user starts another timer from another company, the existing timer should be stopped before starting a new one. However, if industry_fsm module is installed and the previous timer is running from another company, the user could have an Access Error because he cannot read the task/ticket linked to the timesheet with the timer to stop.

This commit makes sure the timer is correctly stopped without any issue even if the record linked is inside another company.

Steps to reproduce the issue:
============================
1. Install industry_fsm module
2. Create a task from a timesheetable project and start a timer from that new task.
3. Create a new company and go inside that company
4. Create a new timesheetable project and a new task inside it
5. Start a new timer from that new task.

Expected Behavior:
-----------------
The timer form the first task created should be stopped and a timer for the newest task should be running.

Actual Behavior:
---------------
An access error is raised because the user cannot access to the task linked to the timer to stop.

task-5076633

> [!NOTE]
> While all the following explanations remain true for this forward-ported commit, the fix will only work with the following extra commit (which itself requires this one). They were kept separated as they fundamentally fix different things even though they need each other.

Steps to reproduce:
- Open the VoIP softphone on a mobile device
- Enter a number
- Place the cursor in the middle of the number
- Tap on the *odoo* backspace button
=> The character before the cursor is removed but then the cursor jumps
   to the end of the input.

Note: this also happens when trying to add a number in the middle of
the typed number, using the softphone buttons, but this message focuses
the explanation on the backspace button.

Commit [1] introduced the bug while revamping VoIP and its keypad.
Before that commit, there was a simple `t-on-click` defined on that
backspace button. After the update, that `t-on-click` is still there but
alongside a weird `t-on-touchend.prevent="(ev) => ev.target.click()"`,
which is actually there to prevent zoom-in behavior on double-tap,
although, retesting it does not seem necessary (at least on Android).
In any case, this is the original cause of the bug.
Since [2], the keypad input is using the mail's `useSelection` hook,
which, among other things, manages what happens on click outside of the
input. Before [1], this happened when clicking on the backspace button:

1. The click is handled during its *capture* phase by the `useSelection`
   hook. It checks if clicked location should be considered, the answer
   is yes.

2. The next part of the handler is done in the next microtask (as the
   check is done asynchronously (?? that looks like a bad idea, but
   that's another issue)).

3. That "in the next microtask" part occurs before the event starts
   bubbling: the capture handler saves the cursor position as being at
   the end of the input (?? not sure why, but that's another issue).

4. The click is handled during its *bubbling* phase by the backspace
   button's `t-on-click`, which removes the character before the cursor,
   and sets the cursor position accordingly for the `useSelection` hook.
   The actual cursor position is untouched since [3] on mobile "because
   otherwise it would open the mobile keyboard", but there are other
   ways that would have prevented that I think... to confirm later for
   master via task-5366961 (this actually causes issues in HOOT tests
   but that's another issue).

5. The dialer/numpad component handles the input's focus/cursor. For
   that, it forces a focus and ask the `useSelection` hook to "restore
   the selection", which "restores" it to what step (4) asked.

After [1], this changed to:

1'. Same as step (1)

2'. Same as step (2)

3'. As the click was simulated instead of being the "natural" one
    triggered by the browser touchend handling, the `t-on-click` handler
    is called now, before the "in the next microtask" part of the
    capture handler is done. That means what step (4) did happens now.

4'. Now what step (3) did happens now.

5'. Same as step (5)... but since step (3) and (4) were basically
    swapped, the cursor is now restored as the way it was last saved:
    at the end of the input (again don't know why step the
    `useSelection` hook would want to save it like that though).

There are multiple solutions to fix this:
A. Remove the `t-on-touchend` handler, letting the browser do what it
   naturally does. Although, it might be needed to prevent the mentioned
   zoom behaviors on some phones?
B. Review why the `useSelection` hook wants to save the cursor at the
   end of the input on external click, the point is valid but I am not
   sure that should be this hook's job to enforce it.
C. Review why the `useSelection` hook wants to check if the click has to
   be considered asynchronously, there should be a better way.
D. Configure the `useSelection` hook to consider a click on the
   backspace button as to be ignored, as handled manually by its own
   handlers anyway.

Option (A) should probably be done, by confirming zoom behaviors can be
prevented another way, but it cannot be done in stable anyway. The (B)
and (C) options should be investigated but would also not be stable to
change; also that would modify an exposed hook's behavior so more risky.
Option (D) can probably be done either way and is targeted on fixing the
bug described only, so this is the solution this commit went for.
In master, option (A) will be investigated in the forward-ported version
of this fix.

However... the bug was actually solved 3 months after [1], at [4] thanks
to secret option (E): not removing the `t-on-touchend` but changing it
entirely to call the same handler as the `t-on-click` one. A bit more
stable than option (A) but still not stable.
However... that solution (E) was broken 1 month later, again, by commit
[5] which destroyed step (5) while fixing an unrelated bug. Without that
step, the input cursor is not repositioned after OWL changes the value,
and by default OWL places it back at the end.

The solution is to restore step (5): the problem was that we were
checking if the user was not typing in another input before re-focusing
the keypad input... but the code considered the keypad input itself as
"another input". This commit still adds solution (D) on top of fixing
that, for good measures.

Note that in 19.0+, there is at least another cursor-related bugs,
related to commit [6]. It will be fixed in the forward-port of this one
as they need each other's fix to both work. Really there should be
better ways to handle that cursor position in OWL... might be done in a
future refactoring.

This commit adds a test to hopefully keep the bug fixed, as inspired by
commit [7].

[1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd
[2]: https://github.com/odoo/enterprise/commit/2e8f18801156a8069e26fb3d61d4f8d84893e891
[3]: https://github.com/odoo/odoo/commit/adc5448adf863b99b9b2be29985e560f5c12dbd4
[4]: https://github.com/odoo/enterprise/commit/668467678312632b5b9ecf234280690151bf3078
[5]: https://github.com/odoo/enterprise/commit/db82135fd73d5077fc26be7206105192a845c2bc
[6]: https://github.com/odoo/enterprise/commit/a06c02e8e163ed052c1c4d25a56bea9b6409abde
[7]: https://github.com/odoo/enterprise/commit/613ef7332b0d21e947871e9d33b68d069f1412c2

Related to task-5366961

Forward-Port-Of: odoo/enterprise#101856

-- 
\+ Extra commit:

    [FIX] voip: display keypad input cursor in mobile mode
    
    This basically reverts [1] and does what it wanted to do in an hopefully
    non-buggy way. The cursor was not appearing anymore because [1] simply
    totally removed focus/cursor management in mobile, with the idea of
    not showing the mobile keyboard on top of the odoo keyboard.
    
    This commit restores the focus/cursor management and finds a way to hide
    the mobile keyboard when it is needed, using the `inputMode` property.
    
    By default, the `<input>` is now rendered with "none" as inputMode,
    which should ensure that no update from OWL would open the keyboard. We
    also re-force "none" in the function that controls the focus. We only
    set to "text" when the user actually engages with the input using his
    finger. As soon as the input will change in any other way than using the
    mobile keyboard, this will be switched back to "none".
    
    [1]: https://github.com/odoo/enterprise/commit/a06c02e8e163ed052c1c4d25a56bea9b6409abde
    
    task-5366961