When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see
 
https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177

That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc.

Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name.

Steps to reproduce:
1. Enable Reserve with Google on an appointment type.
2. Book a slot from Google Maps with given name John and family name Doe.
3. Open the created booking and its contact in Odoo.

=> the contact name is the email instead of John Doe

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

Forward-Port-Of: odoo/enterprise#120604

# Setup
Ensure you currently have no activity

# How to reproduce
- Go to any form view with a chatter (e.g. Quotation form view)
- Add 2 activities with a due date of today or before
> Notice there activity counter next to the activity clock icon in the top right should be 2
- Click on the activity clock icon in the top right
> Notifce the activity counter decreases to 1
- Mark as done both To-Do activites

# The problem
The activity counter is negative

# Cause
This issue is due to a desync between the activity counter client side and server side.
When clicking on the activity clock icon, the front-end fetches the mail store data from the
backend, which is why we see the activity counter decrease.

The server computes the activity counter the following way :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L457

It searches for up to 1000 activities and group them by the record they are
associated to (e.g. a sale.order). Then, for each of these records, if atleast
one activity is late or for today, increase the counter by 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L504-L509

Essentially, server side, we get a single +1 in the activity counter by record, not by activity

On the other hand, client side, we simply add 1 in the activity counter every time a
new activity is created. If an activity is deleted, then we remove 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/static/src/core/web/mail_core_web_service.js#L17-L30
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/mail_activity.py#L305-L309

# Proposed solution
Both the client and server side logic were edited fairly recently

Server side :
https://github.com/odoo/odoo/pull/234899

Client side :
https://github.com/odoo/odoo/pull/215880

According to experts, the activity counter should count records, not activities, so we
should fix the client side but properly doing so would introduce too much complexity.
We instead simply prevent the counter from going below 0.

opw-6116821

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

Forward-Port-Of: odoo/odoo#259602

The Thread component mirrors `thread.isLoaded` into `state.mountedAndLoaded` with a `useEffect` whose body only re-runs when the component re-renders (in `onPatched`). `reset()` forces `mountedAndLoaded` false and bumps `resetCount`, a dependency of that effect, so the mirror is meant to re-sync after a reset.

But `resetCount` was a plain instance field. The effect's dependency function reads it, and OWL only re-renders (hence re-runs the effect) when a value the render observed changes; a plain field is not reactive, so reading it observes nothing. Bumping it therefore never scheduled a render, and the mirror only re-ran when some other reactive write happened to schedule one. When a `reset()` lands while `mountedAndLoaded` is already false (a no-op write) with `isLoaded` true, and no such write follows, no render is scheduled: the mirror never re-runs and `mountedAndLoaded` strands at false, so the empty phantom list renders no message. This happens on an out-of-render-cycle `applyScroll` (a late `onImageLoaded` or `ResizeObserver`), and when `showLoadOlder` short-circuits on `loadOlder` false and leaves the render unsubscribed from `isLoaded`.

Move `resetCount` into `this.state`. Reading it in the effect's dependency array now subscribes the render to it (OWL subscribes the `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: `applyScroll` resets on every patch while `!isLoaded`, so an unconditional bump would spin the render loop during loading; the guard re-arms only in the case that heals.

https://runbot.odoo.com/odoo/error/940032

Forward-Port-Of: odoo/odoo#273651

Since [1], the `re-subscribe on reconnect` bus test has been failing intermittently. This is because that PR reduced `OUTGOING_BATCH_DELAY`, which is a good change since it speeds up the tests, but it also makes the ordering of some events non-deterministic.

In this particular case, the test expects the client to receive a `BUS:RECONNECT` event before the worker sends the `subscribe` request to the server.

However, there is no guarantee which one will be observed first by `expect.step`:
- `_sendToServer` is debounced.
- Messages sent to the client pass through several asynchronous stages, such as the message port and event dispatching.

In practice, the ordering does not matter as long as both events occur. This commit adds the `ignoreOrder` option to the `waitForSteps` call.

[1]: https://github.com/odoo/odoo/pull/272199

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

# How to reproduce
- Create a new Receipt
- Save
- Delete the new Receipt

# The issue
A traceback is shown :
`TypeError: Cannot read properties of undefined (reading 'label')`

# Cause
This is caused by the custom status bar for pickings `StockPickingLockedStatusBarField`. In its template, we replace the display of the current label : https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L20-L23 https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L4-L9

The issue is that the base implementation of the current label properly handles the case were no item is currently selected:
https://github.com/odoo/odoo/blob/7630f8fe2d5198b7a1ed538241795dc26a497fa0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L298-L300

But the picking implementation does not :
https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.js#L12-L14

And it seems that the template is quickly rendered without any selected item before deletion.

opw-6345192

Forward-Port-Of: odoo/odoo#273184
Forward-Port-Of: odoo/odoo#273030

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121809
Forward-Port-Of: odoo/enterprise#119525

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
-  Set your warehouse to manufacture in 2 steps (pick then manufacture).
- Create a final product (FP) with a BOM in flexible consumption:
  - 1 x COMP (lot tracked)
- Create and confirm an MO for 1 units of FP
- Set the quantity producing on the MO to 1
> The consumed qty was updated to 1 unit
- Set a lot on the pre-production pikcing and validate
#### > The lot is not transfered to the MO which you are not able to validate since the registered component is lot less

### Cause of the issue:

The issue is caused by https://github.com/odoo/odoo/commit/3223deb871ca4cb4ac0381e4321f2dbf79a60189 as the `qty_waiting` is based on the reservation state of the move origin of the move rather than its actual demand:
https://github.com/odoo/odoo/blob/00118002bd6eab2f4c34a32e993a9219fded06ac/addons/mrp/models/mrp_production.py#L1419-L1426
In particular, since the backorder of the pre-production picking was not reserved (since nothing was available in stock), it was not taken into account as it should have been.

Issue 2:

Steps to reproduce:

- In the settings Enable Multi-Steps Routes
- Unarchive MTO
- Create 3 products: 
  - Final Product: Tracked by SN with a BOM: 1 X Super Component
  - Super Component: Tracked by SN, MTO with a BOM: 1 X Component
  - Basic Component: Put 10 units in stock
- Create and confirm an MO for 3 units of Final Product
> This should create an MO for 3 units of Super Component
- Go to the Child MO > Cogs wheel > Split in 3 MO's
- Click "Generate serial" on each Child MO and validate the first one
- On the MO for Final Product > Cogs wheel > Split in 3 MO's
- On the first MO, click "Generate Serial"
> Error: Reserving a negative quantity is not allowed.

### Cause of the issue:

The `action_generate_serial` calls in turn the `set_qty_producing`:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1601
However, since the main MO was split the Super component demand is of 1 but each child MO provide an origin quantity of 1 so that the `new_qty` will be set to a negative one here:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1418-L1426
But, since the first child MO was validated, there is already a move line associated to the Super component move and the `_set_quantity_done` will therefore try to adapt the reservation to a negative quantity which leads to the error:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/stock/models/stock_move_line.py#L469-L470

opw-6128575
opw-6317083

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

Forward-Port-Of: odoo/odoo#273168
Forward-Port-Of: odoo/odoo#271123

### Steps to reproduce:

- Create a storable product P tracked by SN, fifo perpetual lot valuated using the MTO route and with a BOM: 1 x COMP
- Create, confirm and validate an MO for 10 unit of P using COMP's at 10$ (by setting its standard price).
- Create and confirm a Sales Order for 1 unit of P
> This generate an MO
- Validate this MO for a new serial say SN011 using a COMP at 20$.
- Validate the Delivery Order using SN011
- Create and post the customer invoice
#### > The invoice COGS uses Std Price rather than the 20$ lot's fifo value

### Cause of the issue:

The cogs value are generated based on the moves returned by the `_get_stock_moves` call of the acount.move.line:
https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/account_move_line.py#L66-L68 Currently, if an account.move.line is linked to a sale.order.line, this methods returns the entire pull of stock moves linked to the sol: https://github.com/odoo/odoo/blob/79c9e7de6764e7f8e47709b827df6eee81e72637/addons/sale_stock/models/account_move.py#L155-L156 However, these moves include both, the delivery move and the `move_finished_ids` of the MTO prodcution. This is problematic since the delivery move is considered as positive cogs qty and the MO is considered as incoming cogs qty leading to a sum of 0 cogs qty which in turns make the cogs price unit fall back to the product standard price instead of the fifo cost of the produced lot.: https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/stock_move.py#L257-L271

opw-6292048


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

Forward-Port-Of: odoo/odoo#272815
Forward-Port-Of: odoo/odoo#271018

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121809
Forward-Port-Of: odoo/enterprise#119525

### Steps to reproduce:

- Create a storable product P tracked by SN, fifo perpetual lot valuated using the MTO route and with a BOM: 1 x COMP
- Create, confirm and validate an MO for 10 unit of P using COMP's at 10$ (by setting its standard price).
- Create and confirm a Sales Order for 1 unit of P
> This generate an MO
- Validate this MO for a new serial say SN011 using a COMP at 20$.
- Validate the Delivery Order using SN011
- Create and post the customer invoice
#### > The invoice COGS uses Std Price rather than the 20$ lot's fifo value

### Cause of the issue:

The cogs value are generated based on the moves returned by the `_get_stock_moves` call of the acount.move.line:
https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/account_move_line.py#L66-L68 Currently, if an account.move.line is linked to a sale.order.line, this methods returns the entire pull of stock moves linked to the sol: https://github.com/odoo/odoo/blob/79c9e7de6764e7f8e47709b827df6eee81e72637/addons/sale_stock/models/account_move.py#L155-L156 However, these moves include both, the delivery move and the `move_finished_ids` of the MTO prodcution. This is problematic since the delivery move is considered as positive cogs qty and the MO is considered as incoming cogs qty leading to a sum of 0 cogs qty which in turns make the cogs price unit fall back to the product standard price instead of the fifo cost of the produced lot.: https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/stock_move.py#L257-L271

opw-6292048


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

Forward-Port-Of: odoo/odoo#272815
Forward-Port-Of: odoo/odoo#271018

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089




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

Forward-Port-Of: odoo/odoo#273090
Forward-Port-Of: odoo/odoo#269510

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089

Forward-Port-Of: odoo/enterprise#122280
Forward-Port-Of: odoo/enterprise#120210

The Thread component mirrors `thread.isLoaded` into `state.mountedAndLoaded` with a `useEffect` whose body only re-runs when the component re-renders (in `onPatched`). `reset()` forces `mountedAndLoaded` false and bumps `resetCount`, a dependency of that effect, so the mirror is meant to re-sync after a reset.

But `resetCount` was a plain instance field. The effect's dependency function reads it, and OWL only re-renders (hence re-runs the effect) when a value the render observed changes; a plain field is not reactive, so reading it observes nothing. Bumping it therefore never scheduled a render, and the mirror only re-ran when some other reactive write happened to schedule one. When a `reset()` lands while `mountedAndLoaded` is already false (a no-op write) with `isLoaded` true, and no such write follows, no render is scheduled: the mirror never re-runs and `mountedAndLoaded` strands at false, so the empty phantom list renders no message. This happens on an out-of-render-cycle `applyScroll` (a late `onImageLoaded` or `ResizeObserver`), and when `showLoadOlder` short-circuits on `loadOlder` false and leaves the render unsubscribed from `isLoaded`.

Move `resetCount` into `this.state`. Reading it in the effect's dependency array now subscribes the render to it (OWL subscribes the `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: `applyScroll` resets on every patch while `!isLoaded`, so an unconditional bump would spin the render loop during loading; the guard re-arms only in the case that heals.

https://runbot.odoo.com/odoo/error/940032

Forward-Port-Of: odoo/odoo#273651

**Steps to reproduce:**
- Install Documents app
- Upload a sound file (mp3 for example, but the
    behavior is the same for other formats)
- Share the document and copy the link
- Log out
- Paste the link
- Click on preview button
- Media is working fine on Firefox
- Media won't read on Chrome
```
Loading media from '' violates the following Content Security Policy directive: "default-src 'none'".
Note that 'media-src' was not explicitly set, so 'default-src' is used as a fallback.
The action has been blocked.
```

**Issue:**
Since [1] default CSP Headers are too strict for Chrome default media rendering, which breaks the file preview (and force user download).

This only impacts Chrome as they seem to render generate `<video><source>` elements to render the file which triggers a secondary request and fails due to the CSP constraint.

**Fix:**
Could re-apply the header fix of 17.4 (see [2]), but it seems better to block the preview of audio files as well by default (to match how we manage videos).

(Note: we don't want to be used as a media streaming platform)

[1] (set csp to none by default) https://github.com/odoo/odoo/commit/64beb80205dffe4b432c8b5813a3271b073fa85e
[2] (similar issue which was not fixed in 18.0+) https://github.com/odoo/enterprise/commit/a7af78eeb2b9763045a5bda8714172f5e7402df8
[3] (mp4 preview removed) https://github.com/odoo/enterprise/commit/ea88cf7c6d5f077b60fb59347659507fded0e2fe

opw-6235043

Forward-Port-Of: odoo/enterprise#119644

## Issue
When using the *Auto Plan* feature on a planning slot with a Role and a Project set, a resource which operated on the same project will be chosen if available, without taking into account the Role set on the slot.

## Steps to reproduce
1. Install Project Planning (`project_forecast`)
2. In Planning > Configuration > Roles, create two planning roles A and B
    - Role A: Assign a resource R
    - Role B: No resource
3. Open Planning (Schedule by Resource), and go back a few weeks (to prevent overlaps with potential demo data)
4. Create two new slots:
    1. Set Role B and a random Project P, then click Auto Plan: there should be no available resource (because we didn't set any resource for Role B)
    2. Set Role A and the same Project P, then click Auto Plan: it should assign the resource R assigned to Role A
5. After assigning a resource to the slot for Role A, edit the Open Shift for Role B again and click Auto Plan: **it assigns the same resource R, even though that resource is not assigned to Role B.**

## Cause
The `_get_open_shifts_resources` override in `project_forecast` looks for resources that were assigned to slots related to the same project. It does not filter resources based on the requested role.

https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/project_forecast/models/planning_slot.py#L104-L116

This means that resources that are not part of the requested role can be assigned to the slot, as long as the resource operated on another slot for the same project.

opw-6325744

Forward-Port-Of: odoo/enterprise#122035

The Thread component mirrors `thread.isLoaded` into `state.mountedAndLoaded` with a `useEffect` whose body only re-runs when the component re-renders (in `onPatched`). `reset()` forces `mountedAndLoaded` false and bumps `resetCount`, a dependency of that effect, so the mirror is meant to re-sync after a reset.

But `resetCount` was a plain instance field. The effect's dependency function reads it, and OWL only re-renders (hence re-runs the effect) when a value the render observed changes; a plain field is not reactive, so reading it observes nothing. Bumping it therefore never scheduled a render, and the mirror only re-ran when some other reactive write happened to schedule one. When a `reset()` lands while `mountedAndLoaded` is already false (a no-op write) with `isLoaded` true, and no such write follows, no render is scheduled: the mirror never re-runs and `mountedAndLoaded` strands at false, so the empty phantom list renders no message. This happens on an out-of-render-cycle `applyScroll` (a late `onImageLoaded` or `ResizeObserver`), and when `showLoadOlder` short-circuits on `loadOlder` false and leaves the render unsubscribed from `isLoaded`.

Move `resetCount` into `this.state`. Reading it in the effect's dependency array now subscribes the render to it (OWL subscribes the `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: `applyScroll` resets on every patch while `!isLoaded`, so an unconditional bump would spin the render loop during loading; the guard re-arms only in the case that heals.

https://runbot.odoo.com/odoo/error/940032

# Setup
Ensure you currently have no activity

# How to reproduce
- Go to any form view with a chatter (e.g. Quotation form view)
- Add 2 activities with a due date of today or before
> Notice there activity counter next to the activity clock icon in the top right should be 2
- Click on the activity clock icon in the top right
> Notifce the activity counter decreases to 1
- Mark as done both To-Do activites

# The problem
The activity counter is negative

# Cause
This issue is due to a desync between the activity counter client side and server side.
When clicking on the activity clock icon, the front-end fetches the mail store data from the
backend, which is why we see the activity counter decrease.

The server computes the activity counter the following way :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L457

It searches for up to 1000 activities and group them by the record they are
associated to (e.g. a sale.order). Then, for each of these records, if atleast
one activity is late or for today, increase the counter by 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L504-L509

Essentially, server side, we get a single +1 in the activity counter by record, not by activity

On the other hand, client side, we simply add 1 in the activity counter every time a
new activity is created. If an activity is deleted, then we remove 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/static/src/core/web/mail_core_web_service.js#L17-L30
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/mail_activity.py#L305-L309

# Proposed solution
Both the client and server side logic were edited fairly recently

Server side :
https://github.com/odoo/odoo/pull/234899

Client side :
https://github.com/odoo/odoo/pull/215880

According to experts, the activity counter should count records, not activities, so we
should fix the client side but properly doing so would introduce too much complexity.
We instead simply prevent the counter from going below 0.

opw-6116821

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

Forward-Port-Of: odoo/odoo#259602

The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24)
override builds link.tracker short URLs from
`website.get_current_website()` and the current company's website
domain. It was introduced by
https://github.com/odoo/odoo/commit/f13ecb15af7f0bdc67e37dfb41e8bac77f5a541a
for a multi-company backend flow (users switching companies to post
social marketing links), but it runs for every compute, including
CRON contexts with no HTTP request such as the mass-mailing queue.

Without a request, `get_current_website()` picks an arbitrary website
(the first in the database) and `self.env.company` resolves to the
user's main company, so the short URL uses that company's website
domain instead of `web.base.url`.

Fall back to `super()._compute_short_url_host()` (which uses
`web.base.url`) when no website is resolvable from the request,
session, or context. Backend flows with a real request still hit the
company-aware branch.

Steps to reproduce:
1. Install Email Marketing and Website.
2. Settings > Companies: create a second company B. Settings >
   Websites: ensure website A points to company A with domain A, and
   create website B for company B with domain B.
3. Settings > Technical > Parameters > System Parameters: set
   `web.base.url` to a third domain C, and add `web.base.url.freeze`
   = `True`.
4. On company A, Email Marketing: create a mailing with body
   `<a href="http://example.com">test</a>` and a recipient list,
   then click Send.
5. Settings > Technical > Automation > Scheduled Actions > "Mass
   Mailing: Process queue" > Run Manually.
6. Email Marketing > Configuration > Link Tracker: open the tracker
   generated for the mailing.

=> The Tracked URL uses domain A.
=> The Tracked URL uses domain C.

Ticket [link](https://www.odoo.com/odoo/project.task/6038590)
opw-6038590

Forward-Port-Of: odoo/odoo#259200

### Steps to Reproduce
1. Activate any other language (ex. FR)
2. Create a new Discount code in Discount & Loyalty
3. Change your user language preference to FR, open the newly created loyalty reward, and change the Description on Order to Test Discount for both languages
4. Navigate to the backend Product Variants menu and observe how its name did not translate in English

### Description of the issue/feature this PR addresses:
**Issue:** When you edit a translation for a loyalty.reward description in a multi-language setup, the product name (`discount_line_product_id.name`) fails to receive the complete translation in all languages. It only updates the current language.

**Solution:**
Override the 'update_field_translations' method on the loyalty.reward model. When changes are saved for the 'description' field on the discount code, intercept the payload and mirror directly at the discount product's `name` field.

### Current behavior before PR:
Updating the reward description only updates the current language and all other languages do not change.

### Desired behavior after PR is merged:
For all languages in which changes are made in a discount code's description, the discount line product name will reflect the same changes. 

opw-6314760

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

Forward-Port-Of: odoo/odoo#271680

## Issue
When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sets the current user's notification preference to "Handle in Odoo" (`inbox`)
3. Create a sign request and send it to Marc Demo
4. As Marc Demo, sign the request
5. **The user who sent the sign request did not receive a notification to notify them that the request was signed.**

## Fix
This is a partial backport of both https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda (saas-18.2) and a related fix https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 (19.0). Before the first commit, users would not receive inbox notification when sign requests would be completed.

## Note to reviewer
The issue only occurs in 18.0, as it is fixed by https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda in 18.2, but we can backport the fix from https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 from 18.2 to 18.4 if desired.

opw-6251702

Forward-Port-Of: odoo/enterprise#120740

`_l10n_tr_nilvera_add_pdf_to_invoice` writes the response from `client.request('GET', '.../pdf')` directly into `ir.attachment.raw`. The Nilvera client sets `Accept: application/json` on the session and calls `response.json()` by default, so the returned value is a Python `str` holding the base64-encoded PDF body, not raw binary bytes.

The previous code wrote to the base64-aware `datas` field, which auto-decoded its input. An earlier fix switched to `raw` to work around a `binascii.Error` from Python 3.14's stricter base64 validation in the `datas` auto-decode path. That switch silently changed what ends up on disk (`datas` decodes its input, `raw` does not)

Storing that string in the binary `raw` field encodes it as UTF-8, so the file on disk ends up as the literal ASCII of the base64 text. The attachment is served as `application/pdf` but the browser receives base64 ASCII and cannot preview or download the PDF.

Call `b64decode(response)` before storing so the attachment contains the actual PDF bytes.

OPW-6302803

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