Currently a `ParseError` arises when the user installs the `hr_work_entry_holidays` module after deleting all `Time Off Types` in the `Time Off` Configuration.

Steps to reproduce:
---
- Install `hr_holidays` module (without demo data)
- Time Off > Configuration > `Time Off Types` > Delete all
- Now install `hr_work_entry_holidays` module

Traceback:
---
```
Exception: Cannot update missing record 'hr_holidays.holiday_status_comp'

ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_work_entry_holidays/data/hr_payroll_holidays_data.xml:5, somewhere inside <record id="hr_holidays.holiday_status_comp" model="hr.leave.type">
            <field name="work_entry_type_id" ref="hr_work_entry_contract.work_entry_type_compensatory"/>
        </record>
```

The error occurs because the user deleted all `Time Off Types` and then installed the `hr_work_entry_holidays` module. which requires particular records.

This commit solves the above issue by using `noupdate="1"` and `forcecreate="False"` to bypass record creation if it violates checks.

https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/odoo/tools/convert.py#L364-L366

sentry-5731062091

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

In the calendar application, when clicking on an event, a window opens. In this window, we can select “yes,” “no,” or “maybe.” When one of the buttons is selected and the mouse hovers over the button to its right, the border of the selected button disappears. This commit fixes this display issue to ensure that all four borders remain visible when hovering over the button adjacent to the selected one.

Current behavior before PR:
<img width="430" alt="Screenshot 2025-03-31 at 18 14 31" src="https://github.com/user-attachments/assets/803358b7-139d-44d3-a5b2-d381bd2fc998" />

<img width="434" alt="Screenshot 2025-03-31 at 18 14 35" src="https://github.com/user-attachments/assets/4a2ce979-1da5-4c19-8e82-0bfe651e9c27" />


Desired behavior after PR is merged:
<img width="430" alt="Screenshot 2025-03-31 at 18 13 11" src="https://github.com/user-attachments/assets/c9faf40d-e913-481a-ac57-fc341091d56b" />
<img width="436" alt="Screenshot 2025-03-31 at 18 13 06" src="https://github.com/user-attachments/assets/12c0745f-a02a-4e59-99f3-4d6a2c791162" />

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

When submitting the new address, the `post` method from the `http` service is called. This method expects a response in JSON. The problem arises when a redirection occurs during that call, then the returned content might be of another type which triggers an error. For example, it is possible to be redirected to the `/shop/cart` page if the cart is not valid.

Steps to reproduce:
- Add a product to your cart
- Then head over to the address form during checkout.
- Before confirming your address, in another tab, open the backend and remove every order line in your cart.
- Then back on the previous tab, confirm your address.
- You can observe an error in the console:

```
SyntaxError: Unexpected token '<', ..."
        <!DOCTYPE "... is not valid JSON
```

This commit fixes this issue by sending the redirection URL in the result of `shop_address_submit` and lets the client handle the redirection.

This commit also renames the `successUrl` value to `redirectUrl` to make it more clear that it is not necessarily a success URL any more, but the next location URL for the user, ie. redirect.

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

Forward-Port-Of: odoo/odoo#201755

Before this commit, the IM status icon shown when the user is homeworking won't always be precise. This happens because of the IM status refactoring (https://github.com/odoo/odoo/pull/174814).

Steps to reproduce:
1. Setup user Marc Demo as homeworking in the current day
2. As Marc Demo open Discuss
3. As Mitchell Admin open the conversation with Marc Demo -> the correct home online icon is shown
4. As Marc Demo close all Odoo tabs -> user goes offline and Mitchell Admin sees the correct offline icon
5. As Marc Demo reopen Discuss -> Mitchell Admin sees the circle icon instead of the home icon

This commit fixes the issue by sending the user im_status information directly from its indentity model (`res.partner` or `mail.guest`) in the `bus.bus/im_status_updated` notification payload. This ensures that any overrides on the `im_status` field will be taken into consideration without having to re-establish the override client side.
`presence_status` now represents the status value of the presence model, while `im_status` represents the status value of the identity model.

Forward-Port-Of: odoo/odoo#202776
Forward-Port-Of: odoo/odoo#199936

When there are none or more than 1 partner that have the same subcontracting location setup, then any procurement made to this subcontracting location will be removed, even if another configuration is applicable.


## How to reproduce:
https://drive.google.com/file/d/1jvT1pmCqY0JNAinvqmbonX0CDYYysoJz/view?usp=sharing

- Activate Routes, Subcontracting, Dropshipping
- Create custom subcontracting location
- Create partners "Partner 1" & "Partner 2", with custom sub loc setup
- Create custom route 'Resupply Subcontractor', with rule:
  - action: Pull From
  - operation: delivery
  - source: Stock
  - dest: custom sub loc
  - method: take from stock
  - Partner Address: Partner 1
- Create product with reordering rule:
  - manual, min 0, max 0, custom sub loc, custom route
- In Replenishment -> Find custom reordering rule -> set Order Qty to 1 -> Order Once
  - Created Transfer does not have any partner address
- Cancel created transfer
- Remove subcontracting loc for "Partner 2"
- In Replenishment -> Find custom reordering rule -> set Order Qty to 1 -> Order Once
  - Created Transfer has the partner address

OPW-4576260

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

Forward-Port-Of: odoo/odoo#203961
Forward-Port-Of: odoo/odoo#200169

* stock{,_barcode, _barcode_quality_control}, quality_control

### Issue:

Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.

The above issue can be triggered in many situations. Here are the two major ones:

### Use case I:

Creating a delivery or an internal transfer on the fly from the barcode app.

### Steps to reproduce:

- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133

### Use case II:

Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailled operations.

### Steps to reproduce:

- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.

### Fix:

We ensure the creation of quality checks for moves that end up being created but will never be confirmed.

### Technical limitation:

Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.

Enterprise: https://github.com/odoo/enterprise/pull/81850

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

Forward-Port-Of: odoo/odoo#202859
Forward-Port-Of: odoo/odoo#202725

Steps to reproduce the bug:
- Create a quality point:
    - Operations: Receipt
    - Control per: Product
    - Control frequency: All
    - Type: Worksheet
    - Template: Select any one
    - Success conditions: Match all the following rules
    - Created by: Is set

- Create a receipt order:
    - Product: Select any product
    - Confirm the receipt → A quality check is created

- Click on the "Quality Check" smart button
- Open the Worksheet"
- Complete the worksheet

Problem:
The quality check is not being automatically marked as passed or failed.

When accessing the worksheet through the quality check view, the
function “action_quality_worksheet” is called instead of
“action_open_quality_check_wizard” , which means that the key
“quality_wizard_id” is not added to the context:

https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L64

However, when clicking on save, the function “action_worksheet_check”
is triggered:

https://github.com/odoo/enterprise/blob/b51da60213232ccbc537c399e1c007d6051e40ae/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L19

At this point, the system checks whether “quality_wizard_id” is present
in the context to proceed with the quality check; otherwise, it simply
closes the wizard:

https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L95-L97

https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L98-L100


Opw-4652268

Forward-Port-Of: odoo/enterprise#82225

* stock{,_barcode, _barcode_quality_control}, quality_control

### Issue:

Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.

The above issue can be triggered in many situations. Here are the two major ones:

### Use case I:

Creating a delivery or an internal transfer on the fly from the barcode app.

### Steps to reproduce:

- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133

### Use case II:

Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailed operations.

### Steps to reproduce:

- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.

### Fix:

We ensure the creation of quality checks for moves that end up being created but will never be confirmed.

### Technical limitation:

Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.

Community: https://github.com/odoo/odoo/pull/202725

opw-4480104

Forward-Port-Of: odoo/enterprise#81903
Forward-Port-Of: odoo/enterprise#81850