Issue: Mail scanners can send HTTP HEAD requests to links contained in emails, which can change the state of a sign request without user action. Steps: - send a sign request - look in mailhog to get the notification mail - copy the link at the bottom of the mail and `curl --head <url>` - the sign request is now ignored opw-4217355 Forward-Port-Of: odoo/enterprise#72182

Issue:
Mail scanners can send HTTP HEAD requests to links contained in emails, which can change the state of a sign request without user action.

Steps:
- send a sign request
- look in mailhog to get the notification mail
- copy the link at the bottom of the mail and `curl --head <url>`
- the sign request is now ignored

opw-4217355

Forward-Port-Of: odoo/enterprise#72182

In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523

In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set.

Therefore, in tests where the availability condition is set to country, the country should be set before.

task-4160643

Forward-Port-Of: odoo/enterprise#72523

Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183726

Use Case :

Argentinian Company (pesos)

Invoice in USD
Payment received in USD, with withholding tax on it

The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance.

This is of course incorrect.

opw-4150317

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

Forward-Port-Of: odoo/odoo#183726

Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045

Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o).

With this PR, the layout issue will be fixed to ensure it displays correctly.

Task-4210376

Forward-Port-Of: odoo/odoo#184045

__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this b

__Current behavior before commit:__
The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa.

__Description of the fix:__
Add a t-nocache to prevent `info` from being cached and always be up-to-date.

__Steps to reproduce the issue:__
On runbot this behavior is inconsistent since each worker has its own cache. It is however consistent in local with only one worker. Make sure you are **not** in debug mode

1. Set a livechat channel on the website, make sure there is no chatbot on it
2. Enter the livechat channel with the admin
3. Open the website on an incognito window (the chat bubble should be there)
4. Leave the livechat channel with the admin
4. Refresh the incognito window

The chat bubble is still there.

Note that the chat bubble might not appear at all even when the admin enter the livechat if the opposite has been cached before.

opw-4233744

[1]: https://github.com/odoo/odoo/blob/837a6a8/addons/im_livechat/views/im_livechat_channel_templates.xml#L100
[2]: https://github.com/odoo/odoo/blob/2997afa/addons/website/views/website_templates.xml#L86

Forward-Port-Of: odoo/odoo#184644

This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509

This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set.

task-4160643 

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

Forward-Port-Of: odoo/odoo#184686
Forward-Port-Of: odoo/odoo#182509

**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order lin

**Current behavior:**
Opening a purchase order, clicking on the forecast report for a
product in an orderline, then navigating to a "Used By" link,
then clicking the back button in browser will reusult in a
traceback when MRP is installed.

**Expected behavior:**
No traceback.

**Steps to reproduce:**
*install mrp,purchase*
*enable reception report in settings*

1. Open a purchase order with a product that is used in another
order

2. Click on the forecast report on the order line

3. Click on a linked record in the "Used by" column in the
report table

4. Click the browser back button -> traceback

**Cause of the issue:**
When trying to rebuild context, we get the actual model name
provided by this.props.action.res_model. This was invariably
treated as a stringified number in a read call to `ir.model` to
try to get the model name -> result of the read is nonsense and
when it is later used in an RPC, it tries to read fields from a
nonexistent model.

**Fix:**
Get rid of the String -> Number conversion, directly use the
value in `res_model` as the new `this.resModel`.

opw-4181590

Forward-Port-Of: odoo/odoo#183742

This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051

This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events.

task-4182649

Forward-Port-Of: odoo/odoo#180051

Steps to reproduce (on runbot): 1. enable "extra hours" and add extra hours to an employee 2. as an admin go to management > time off 3. make a new time off and choose "extra hours" as the time off type 4. The duration of extra hours is duplicated The issue happens because the form view inherits two identical views. This commit removes the unnecessary view. task-4102491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o

Steps to reproduce (on runbot):
1. enable "extra hours" and add extra hours to an employee
2. as an admin go to management > time off
3. make a new time off and choose "extra hours" as the time off type
4. The duration of extra hours is duplicated

The issue happens because the form view inherits two identical views. This commit removes the unnecessary view.

task-4102491

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

Forward-Port-Of: odoo/odoo#178866
Forward-Port-Of: odoo/odoo#176929

When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with

When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records.  However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts).

This commit simply makes the cleanup ignore such a case.  It makes sense, because the whole table will be deleted anyway (if there are no migration scripts).

STEPS
 - install a module that defines a model with a selection field
 - rename or remove the model
 - upgrade the module

This commit fixes #179392.
It was inspired by #104624.

opw-3024537

Forward-Port-Of: odoo/odoo#184764

e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port

e-Resguardo document type must not have internal type 

**Current behavior before PR**:
e-Resguardo document type has "invoice" internal type 
![image](https://github.com/user-attachments/assets/ebef6645-7530-4559-ae77-bd58eec7fdd5)

**Desired behavior after PR is merged**:
e-Resguardo document type do not have internal type 

**Task Adhoc side**: 43467
**Task Latam side**: 1280


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

Forward-Port-Of: odoo/odoo#184810

The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different language. The problem came form Convert the "Reset Password" template into QWeb view in https://github.com/odoo/odoo/pull/125874, Before, to sent the email `mail.send_mail()` function was used, and it has a check for the receiver language. and after https://github.com/odoo/odoo/pull/125874 th

The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different language.

The problem came form Convert the "Reset Password" template into QWeb view in https://github.com/odoo/odoo/pull/125874,    Before, to sent the email  `mail.send_mail()`  function was used, and it has a check for the receiver language. and after  https://github.com/odoo/odoo/pull/125874 the function wasnt used any more. it replaces with `mail.send()` that send the rendered content directly.

To resolve this issue, the language of the receiver user is explicitly set in the context before rendering the email template. This ensures the email content is translated based on the user's preferred language then calling the function that send it. 

Now the template is rendered using the receiver's language (`user.lang`), or falls back to the website language `self.env.lang` if the receiver's language is not set. Or falls back to  'en_US' if the language is not set.

owp-4149894


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

Forward-Port-Of: odoo/odoo#182635

A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that

A traceback occurs from version 18.0 when the user creates a new link tracker.

To reproduce this issue in 18.0:

1) Install website, link tracker and enable debug mode
2) Tries to create a new link tracker record from the link tracker

Error:- 
```
TypeError: Cannot mix str and bytes arguments (got (False, 'False'))
```

The onchange sets computes to False by default when they're requested,
and apparently does not recompute them if they don't depend on anything.

Because of that the `short_url_host` value will be False and this leads to a traceback
when the compute method of `short_url` triggers.

Ref of the breaking commit:- 

https://github.com/odoo/odoo/pull/170548/commits/20d2f122568feead98df18706ca0a4691c8393c5

sentry-5969318187

Forward-Port-Of: odoo/odoo#182898

We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027

We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded).
All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359

task-3794536




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

Forward-Port-Of: odoo/odoo#185027

### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached. ### Fix: Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering. Setting `drag_and_drop` tour in Monthly Calendar v

### Issue:

`test_dblclick_event_from_calendar` tour test fails on Saturday

### Explanation:

In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached.

### Fix:

Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering.
Setting `drag_and_drop` tour in Monthly Calendar view to avoid issues caused by potential `drag_and_drop` behaviour changes. In Monthly Calendar view, some days from previous and following months are visible, with a maximum of 6 before (Feb 23, see Mar 2025) and 14 after (Mar 14, see Feb 2026). Initial date being set in the backend, it does not have to respect those limitations. Changes operated in the frontend are bound to these and must be set between 15 and 22 included with the current selector.

runbot-error-65494

Forward-Port-Of: odoo/odoo#166502