This pull request formally signs Odoo's Contributor License Agreement (CLA), ensuring compliance with our open-source licensing. This update is a standard legal step for contributors and doesn't impact Odoo's functionality. It strengthens our commitment to the Odoo community.

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

Forward-Port-Of: odoo/odoo#157960

This pull request formally records that santiagopim has signed the Odoo Contributor License Agreement (CLA). This is a necessary step for santiagopim to contribute code to the Odoo project, ensuring compliance with our licensing terms. With the CLA now signed, santiagopim can begin contributing to Odoo.

Description of the issue/feature this PR addresses: Sign CLA agreement for santiagopim

Current behavior before PR: No CLA signed

Desired behavior after PR is merged: CLA signed




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

Forward-Port-Of: odoo/odoo#157955

Create a cron with an `interval_number` of 0 and change its nextcall so that it is called soon. When the cron gets executed, the cron worker enters an infinite loop during the computation of the next nextcall. The cron now gets disabled with an error message. On the form view, users now get a warning when `interval_number` is invalid. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158122 Forward-Port-Of: odoo/o

Create a cron with an `interval_number` of 0 and change its nextcall so
that it is called soon. When the cron gets executed, the cron worker
enters an infinite loop during the computation of the next nextcall.

The cron now gets disabled with an error message. On the form view,
users now get a warning when `interval_number` is invalid.




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

Forward-Port-Of: odoo/odoo#158122
Forward-Port-Of: odoo/odoo#144717

Related to https://github.com/odoo/odoo/commit/b6fc5ef468f47c109b2d007f211e02ca5f3fe093 Apply rule to account moves to prevent Expense Team Approver user can access to all moves **Description of the issue/feature this PR addresses**: User with Expenses: Team Approver group should not see all moves. **Example use case**: - Create a user with Expenses: Team Approver group. - Login with the created user to /my - The user will only see invoices linked to expenses. **Current behavior

Related to https://github.com/odoo/odoo/commit/b6fc5ef468f47c109b2d007f211e02ca5f3fe093

Apply rule to account moves to prevent Expense Team Approver user can access to all moves

**Description of the issue/feature this PR addresses**:
User with Expenses: Team Approver group should not see all moves.

**Example use case**:
- Create a user with Expenses: Team Approver group.
- Login with the created user to /my
- The user will only see invoices linked to expenses.

**Current behavior before PR**:
User with Expenses: Team Approver group will **only** be able to see invoices linked to expenses.

Ping @pedrobaeza 

@Tecnativa TT48242

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

Forward-Port-Of: odoo/odoo#156858

This PR contains a revamp of the digest email in the new "Milk" style replacing the old purple with the new one. This has been adapted in all digest data too. The images of the digest email's tips have been replaced by "milkified" versions of them, already available on odoo cdn by the way. Task-3338467 Forward-Port-Of: odoo/odoo#158351 Forward-Port-Of: odoo/odoo#125432

This PR contains a revamp of the digest email in the new "Milk" style replacing
the old purple with the new one. This has been adapted in all digest data too.

The images of the digest email's tips have been replaced by "milkified"
versions of them, already available on odoo cdn by the way.

Task-3338467

Forward-Port-Of: odoo/odoo#158351
Forward-Port-Of: odoo/odoo#125432

This commit simply removes the table-responsive class from the pivot view in desktop mode so that its eventual horizontal scrollbar will remain inside the viewport inside of being positioned at the very bottom of the page. Also hides the scrollbar in sample data mode so that the user cannot scroll horizontally in this case which introduces weird display. Forward-Port-Of: odoo/odoo#158083

This commit simply removes the table-responsive class from the pivot view in desktop mode so that its eventual horizontal scrollbar will remain inside the viewport inside of being positioned at the very bottom of the page. Also hides the scrollbar in sample data mode so that the user cannot scroll horizontally in this case which introduces weird display.

Forward-Port-Of: odoo/odoo#158083

This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account, and we restore the default accounts that could be set on sale, purchase, bank, and cash journals. The domain was broken since this commit: https://github.com/odoo/odoo/commit/3312657294947b1cc8670a0ed3557e12ee6969c8 The following journals must have the following possible default account types: - ba

This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account, and we restore the default accounts that could be set on sale, purchase, bank, and cash journals. The domain was broken since this commit: https://github.com/odoo/odoo/commit/3312657294947b1cc8670a0ed3557e12ee6969c8

The following journals must have the following possible default account types:
- bank: asset_cash,
- cash: asset_cash,
- sale: income, income_other,
- purchase: expense, expense_depreciation, expense_direct_cost,
- general: all account types are possible,

The object of the task was mainly to allow misc journals to allow receivable or payable default account type for the following use case:
Suppose a user creates a Miscellaneous Journal to manage the details of the credit card statements.

Most journal entries will consist of journal items impacting the Payable Account, as this will reclassify the debt towards various vendors and address this debit to the credit card company.

It would in that case be necessary that the liquidity_payable accounts can be the default account on the miscellaneous journal. Otherwise, the user will have to fill in manually the account for each line of its credit card statement, and considering there can be a lot, this could become cumbersome.

task-3393017

Forward-Port-Of: odoo/odoo#157188

Purpose of this commit: Currently, people having access to different dashboards without any access rights would end up with a traceback when trying to search more employees. Steps to reproduce this issue: - have a user with timesheet officer rights and no hr rights - log in with that user account - go on the dashboard app and select "Timesheets" - go on employee filter and click on "search more" Current behaviour: A traceback is displayed because the user has no access to the view

Purpose of this commit:
Currently, people having access to different dashboards without any access rights would end up with a traceback when trying to search more employees.

Steps to reproduce this issue:
- have a user with timesheet officer rights and no hr rights
- log in with that user account
- go on the dashboard app and select "Timesheets"
- go on employee filter and click on "search more"

Current behaviour:
A traceback is displayed because the user has no access to the view

Expected behaviour:
The public employee search view should be displayed

How the issue was fixed:
The method called `_get_views` has been overriden in the `hr.employee` model to return the `hr.employee.public` views instead if the user doesn't have the appropriate access rights. As there was no way through the dashboard to define a relation, the method explicitely takes the result for the public employee and sets it as result of the private one as well.

Forward-Port-Of: odoo/odoo#158096
Forward-Port-Of: odoo/odoo#155739

Commit [1] made it possible to stay in the backend while refreshing the page with F5 or CTRL+R when viewing a Website Preview. Pressing it too fast when the page is still loading and the iframe isn't loaded yet triggers a traceback. This commit falls back to the default refresh in such cases. [1]: https://github.com/odoo/odoo/commit/e69c6eaed4e82e08d6bbf807cf4698f6327a9cdd task-3795143 Forward-Port-Of: odoo/odoo#157129

Commit [1] made it possible to stay in the backend while refreshing the
page with F5 or CTRL+R when viewing a Website Preview. Pressing it too
fast when the page is still loading and the iframe isn't loaded yet
triggers a traceback.
This commit falls back to the default refresh in such cases.

[1]: https://github.com/odoo/odoo/commit/e69c6eaed4e82e08d6bbf807cf4698f6327a9cdd

task-3795143

Forward-Port-Of: odoo/odoo#157129

Steps to reproduce: - - Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3) - Set routes to manifacture on each product - For P1, P2, P3 add a 0:0 reordering rule. - Add a BOM for P2 with 1 unit of P1 as components - Add a BOM for P3 with 1 unit of P2 as components - Add a BOM for FP with 1 unit of P3 and of P2 as components The MO overview of a FP should look like this : ``` FP /\ / \ P3 P2 | | P2 P1 | P1 ``` - Create and confirm a

Steps to reproduce:
-
- Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3)
- Set routes to manifacture on each product
- For P1, P2, P3 add a 0:0 reordering rule.
- Add a BOM for P2 with 1 unit of P1 as components
- Add a BOM for P3 with 1 unit of P2 as components
- Add a BOM for FP with 1 unit of P3 and of P2 as components The MO overview of a FP should look like this :
```
    FP
    /\
   /  \
  P3   P2
  |    |
  P2   P1
  |
  P1
```
- Create and confirm a manufacturing order for a FP

Current behavior:
-
As the quantity on hand is not sufficient to manufacture a FP, manufacturing orders are automatically created for P3, P2 and P1. However, the quantity on each of these MOs is of 1 unit.

Expected behavior:
-
Since 2 units of P2 and of P1 will be required to manufacture the FP the quantity of their respective MOs should be at 2.

Cause of the issue:
-

Confirming the MO for FP will  call the trigger_scheduler() on its raw stock move:
https://github.com/odoo/odoo/blob/79813f08e5a2f0188ac7d184d000486f25319503/addons/mrp/models/mrp_production.py#L1291
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L495
In this method, we compute the qty to order for the orderpoints of P2 and P3. Since these ones are positive, procurement will be run for both of these leading to the creation of 2 new MO's via the manufacture route. The post process of the scheduler is then run https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L550
An override of this method in mrp will then find the created MO and confirm these,  triggering the above process once more but now for the MO's of P3 and P2 rather than FP: we start by computing the qty to order for the orderpoints of P2 and P1 to manufacture P3 and P2. However, to compute this quantity, we look at the forecast of these quantities and this is where the problem comes in:
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L284
With the orderpoint of P2:
- `virtual_available` is at a value of -1 since there is currently 2 stock moves taking this product (one to manufacture FP and one to manufacture P3) and one stock move bringing one unit of this product (the one coming from the MO of P2 we are currently trying to confirm).
-  `orderpoint._quantity_in_progress()` has a value of 1 due to the MO of P2 that we are currently confirming.
Adding these quantities to one an other, the forecasted qty of P2 is at 0. This is a mistake since the incoming stock move for P2 is counted twice in the forecast qty: once in each term. As a result no new procurement will be generated for P2 hence the issue.

FIX:
-
Since this `_quantity_in_progress()` seems to have been introduced to improve purchase flows rather than to interact with manufacturing flows:  https://github.com/odoo/odoo/commit/943da6df0f1d39e8e10869b25c5ba8cc13a2aa54
We decided to ignore its contribution during our manufacturing flow for the forecast qty to be correctly computed.This requires to ignore the contribution of each mo triggering the scheduler and those that already triggered the scheduler since the confirmation of the MO of FP.

Notes: The test sets a little more complex MO overview than the above use case to be sure to catch corner cases situations.

opw-3689920
-


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

Forward-Port-Of: odoo/odoo#153400

**Description of the issue/feature this PR addresses:** - Remove context which came from the calendar action to only show short name in activity message - ~Add the start and end datetime for notification of the manager, otherwise the manager has a useless email which would need to open a browser to get the notified information (waste of time)~ - Replace date connector with - as a / does not help to better understand the data given **Current behavior before PR:** Incomplete information i

**Description of the issue/feature this PR addresses:**
- Remove context which came from the calendar action to only show short name in activity message
- ~Add the start and end datetime for notification of the manager, otherwise the manager has a useless email which would need to open a browser to get the notified information (waste of time)~
- Replace date connector with - as a / does not help to better understand the data given


**Current behavior before PR:**
Incomplete information in the notification emails for time off approvals

**Desired behavior after PR is merged:**
A better and at least valuable information provided to the manager in a stable way to fix things.

Info: @wt-io-it

In relation to:
- OPW-3628915 
- OPW-3764283

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

Forward-Port-Of: odoo/odoo#157891
Forward-Port-Of: odoo/odoo#155900

Before this commit sol name was not reflacting invoice status when it moved to posted it only reflect draft and cancel state. This commit re-compute downpayment related sol name when invoice related to that sol get posted this way it'll update sol name to proper name instead of keeping always Draft string in it. opw-3768323 Forward-Port-Of: odoo/odoo#157824

Before this commit sol name was not reflacting invoice
status when it moved to posted it only reflect draft
and cancel state.

This commit re-compute downpayment related sol name
when invoice related to that sol get posted this
way it'll update sol name to proper name instead of
keeping always Draft string in it.

opw-3768323

Forward-Port-Of: odoo/odoo#157824

Steps to reproduce: * Create a product tag (available on ecommerce) * Select that filter on the /shop page * Enter a search string -> Traceback The selected tag is given as a string to the autocomplete route, and not a list of ids, which fails when converted to an 'in' domain leaf. `[('product_variant_ids.all_product_tag_ids', 'in', tags)]` This commit makes sure to convert the given ids to a list, correctly handled by the orm. Fixes #155327 Forward-Port-Of: odoo/odoo#1554

Steps to reproduce:

* Create a product tag (available on ecommerce)
* Select that filter on the /shop page
* Enter a search string

-> Traceback

The selected tag is given as a string to the
autocomplete route, and not a list of ids,
which fails when converted to an 'in' domain leaf.

`[('product_variant_ids.all_product_tag_ids', 'in', tags)]`

This commit makes sure to convert the given ids to a list, correctly handled by the orm.

Fixes #155327

Forward-Port-Of: odoo/odoo#155430

Before this commit, radio buttons in the offcanvas filters (displayed on mobile) were not working as they should: clicking on the label worked fine but the click on the radio itself did not trigger anything. We impeach input's `pointer-event` so, the `<a>` becomes main and only interaction This commit also fixes an contrast issue in the tag filter in the offcanvas task-3649662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-

Before this commit, radio buttons in the offcanvas filters (displayed
on mobile) were not working as they should: clicking on the label 
worked fine but the click on the radio itself did not trigger anything.

We impeach input's `pointer-event` so, the `<a>` becomes main and only
interaction

This commit also fixes an contrast issue in the tag filter in the 
offcanvas
task-3649662

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

Forward-Port-Of: odoo/odoo#147129

**Current behaviour before commit:** After selecting cells in table, moving cursor through arrowkeys doesn't deselect cells. **Desired behaviour after commit:** Now cells are getting deselected. task-3718716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153365

**Current behaviour before commit:**

After selecting cells in table, moving cursor through arrowkeys doesn't deselect cells.

**Desired behaviour after commit:**

Now cells are getting deselected.

task-3718716


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

Forward-Port-Of: odoo/odoo#153365

Steps: - Install sales app. - Create SO and add a product. - Confirm that SO and create invoice and post it. - Reverse that invoice via adding credit note. - Go to portal view of that SO. Issue: - `Waiting Payment` badge is displaying instead of `Paid` as invoice is reversed Cause: - Only to payment status added to display `Paid` badge. Fix: - Add `Reversed` badge in portal and display reversed badge when payment_state is in reversed state. opw-3677622 Forward-Port-Of: odoo

Steps:
- Install sales app.
- Create SO and add a product.
- Confirm that SO and create invoice and post it.
- Reverse that invoice via adding credit note.
- Go to portal view of that SO.

Issue:
- `Waiting Payment` badge is displaying instead of `Paid` as invoice is reversed

Cause:
- Only to payment status added to display `Paid` badge.

Fix:
- Add `Reversed` badge in portal and display reversed badge when
payment_state is in reversed state.

opw-3677622

Forward-Port-Of: odoo/odoo#158418
Forward-Port-Of: odoo/odoo#157693

This fixes an issue where access rules are checked on a new record: the rule domains are evaluated with method `filtered_domain()`, and one rule uses the operator `'child_of'`, which is implemented with a call to `search()`. When used with a new record, `filtered_domain()` returns an empty recordset instead of the record itself. By design, the ORM doesn't check security on new records. A base automation of type `'onchange'` will run some server action on a new record. The server action may

This fixes an issue where access rules are checked on a new record: the rule domains are evaluated with method `filtered_domain()`, and one rule uses the operator `'child_of'`, which is implemented with a call to `search()`.  When used with a new record, `filtered_domain()` returns an empty recordset instead of the record itself.

By design, the ORM doesn't check security on new records.  A base automation of type `'onchange'` will run some server action on a new record.  The server action may still check access rights on the model, but should not check access rules.

Forward-Port-Of: odoo/odoo#158309

The barcode service using jquery for chrome on mobile is not working properly without jquery included, we include it here task-3817495 Forward-Port-Of: odoo/odoo#158275

The barcode service using jquery for chrome on mobile is not working properly without jquery included, we include it here 
task-3817495

Forward-Port-Of: odoo/odoo#158275

The push-to-talk extension service sends a message to the extension when starting to check if it is enabled. If the response is received before the RTC service is started, the answer is ignored, and the service acts as if the extension were not available. This PR fixes this issue. Forward-Port-Of: odoo/odoo#158252

The push-to-talk extension service sends a message to the extension
when starting to check if it is enabled. If the response is received
before the RTC service is started, the answer is ignored, and the
service acts as if the extension were not available. This PR fixes
this issue.

Forward-Port-Of: odoo/odoo#158252

Since [1] when the social share widget was introduced, a hashtag is generated from the name of the website that is found inside the page title. This fails when the page title is replaced through the SEO feature. This commit prevents the failure but not extracting the website name if it is missing from the title. Steps to reproduce: - Install website_forum. - Go to a forum post. - Set SEO title to a value without `|` (pipe). - Share to X. => An error popup was shown. [1]: https:/

Since [1] when the social share widget was introduced, a hashtag is generated from the name of the website that is found inside the page title.
This fails when the page title is replaced through the SEO feature.

This commit prevents the failure but not extracting the website name if it is missing from the title.

Steps to reproduce:
- Install website_forum.
- Go to a forum post.
- Set SEO title to a value without `|` (pipe).
- Share to X.

=> An error popup was shown.

[1]: https://github.com/odoo/odoo/commit/1c91e27c8c8cb7492d26f03e27c4991b53a1675d

opw-3799914

Forward-Port-Of: odoo/odoo#158064

Removed background color of crm enrich mail messages, so that they look good on both light and dark mode Related task: 3541419 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 Forward-Port-Of: odoo/odoo#158119 Forward-Port-Of: odoo/odoo#158003

Removed background color of crm enrich mail messages, so that they look good on both light and dark mode

Related task: 3541419

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

Forward-Port-Of: odoo/odoo#158119
Forward-Port-Of: odoo/odoo#158003

Steps to reproduce: - Enter in edit mode. - Select the 'Header' menu. - Switch the default template to 'Rounded box menu'. - Select again the 'Header' menu and on the 'Navbar' details, update the format value (i.e: 10px) and save. -> Problem: some buttons are not affected by the change of the format value. The problem is that since [1], those buttons have the `rounded-circle` class so their font size is not the custom one (but it is the value of `$font-size-base` instead). To solve

Steps to reproduce:
- Enter in edit mode.
- Select the 'Header' menu.
- Switch the default template to 'Rounded box menu'.
- Select again the 'Header' menu and on the 'Navbar' details, update the
format value (i.e: 10px) and save.

-> Problem: some buttons are not affected by the change of the format
value.

The problem is that since [1], those buttons have the `rounded-circle`
class so their font size is not the custom one (but it is the value of
`$font-size-base` instead). To solve the problem, the css rule has been
adapted in order to force the font size of the buttons inside the header
to the custom value if it exists.

[1]: https://github.com/odoo/odoo/commit/e3e9c492e0d1e009a0c459a1dc591e122b4b65d3

opw-3810794

Forward-Port-Of: odoo/odoo#158135

Since [1] when the "Padding (Y, X)" option was added, form elements are recognized as columns because they match the `.row > div` selector of that new option. This commit excludes those form elements from this option's selector. Steps to reproduce: - Drop a website form. - Click on field's input. => An empty "Column" editor appeared in the side panel, and an error occurred when trying to delete it. [1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712

Since [1] when the "Padding (Y, X)" option was added, form elements are recognized as columns because they match the `.row > div` selector of that new option.

This commit excludes those form elements from this option's selector.

Steps to reproduce:
- Drop a website form.
- Click on field's input.

=> An empty "Column" editor appeared in the side panel, and an error
occurred when trying to delete it.

[1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712

task-3748574

Forward-Port-Of: odoo/odoo#157572

When the user inserts a video with the `/video` command and provides a link of an unlisted vimeo video, the system generates a new url based on the options selected but omits the hash parameter granting access to the given video. As a result, the video can not be loaded and the vimeo `iframe` indicates that the video does not exist. To fix the issue, we will copy the hash parameter from the original link to the newly generated url. That way, the video will be loaded properly and the user will

When the user inserts a video with the `/video` command and provides a link of an unlisted vimeo video, the system generates a new url based on the options selected but omits the hash parameter granting access to the given video. As a result, the video can not be loaded and the vimeo `iframe` indicates that the video does not exist.

To fix the issue, we will copy the hash parameter from the original link to the newly generated url. That way, the video will be loaded properly and the user will be able to embed unlisted vimeo videos.

Steps to reproduce the issue:
1. Install the website app
2. Open the website builder
3. Drag and drop a text block
4. In the text block, type the `/video` command to insert a video
5. In the modal, paste the link of an unlisted video
6. The `iframe` indicates that the video does not exist

=> The system should extract the hash parameter from the provided url and set it on the generated url. The video should then be loaded properly.

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

Forward-Port-Of: odoo/odoo#157279
Forward-Port-Of: odoo/odoo#150663

# Context With 17.0 the `mail.alias.domain` was introduced, allowing the configuration of the bounce, catchall and default from email addresses at the company level (`res_company`). For this purpose, the `_compute_email_from` method was introduced to correctly compute the `email_from` in various email contexts. But, the `email_from` field in mass_mailing was using an obsolete combination of `default=` and a compute method. This meant that when one created a new `mailing.mailing` record,

# Context
With 17.0 the `mail.alias.domain` was introduced, allowing the configuration of the bounce, catchall and default from email addresses at the company level (`res_company`).

For this purpose, the `_compute_email_from` method was introduced to correctly compute the `email_from` in various email contexts.

But, the `email_from` field in mass_mailing was using an obsolete combination of `default=` and a compute method.
This meant that when one created a new `mailing.mailing` record, it was always defaulting to `self.env.user.email_formatted`. The compute was only triggered when the `mail_server_id` field manually updated.

This is corrected with this fix and a unit test was added to test three different use cases.
An invisible `create_uid` was added to the base mailing From view xml
to have the compute method trigger correctly in some unit tests.

## How to reproduce bug:
See related github issue https://github.com/odoo/odoo/issues/151310

## Behavior after this fix:
If `mail.alias.domain` is setup for the company and a default `ir.mail_server` is configured for Email Marketing, `_compute_email_from` will select the expected `email_from` at record creation for `mailing.mailing`.

opw-3704715
Fixes #151310

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

Forward-Port-Of: odoo/odoo#152655

Forward-Port-Of: odoo/odoo#158035

Forward-Port-Of: odoo/odoo#158035

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 Forward-Port-Of: odoo/odoo#157954 Forward-Port-Of: odoo/odoo#157817

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

Forward-Port-Of: odoo/odoo#157954
Forward-Port-Of: odoo/odoo#157817

Steps to reproduce: - Install both ups_rest and ups legacy - Configure the new ups shipping method as admin - Create an SO and try to add ups delivery as demo - Access error Bug: in ups legacy credential fields are only accessible to the admin sudo is used on the request on the new app they aren't hidden so no sudo was added on the request Fix: it makes sense for me to keep the credentials hidden for the new module and use sudo on the request opw-3771840 Forward-Port-Of: odoo/en

Steps to reproduce:
- Install both ups_rest and ups legacy
- Configure the new ups shipping method as admin
- Create an SO and try to add ups delivery as demo
- Access error

Bug:
in ups legacy credential fields are only accessible to the admin sudo is used on the request
on the new app they aren't hidden so no sudo was added on the request

Fix:
it makes sense for me to keep the credentials hidden for the new module and use sudo on the request

opw-3771840

Forward-Port-Of: odoo/enterprise#58895

- In PR #54687, a currency tag label "moneda" was added for all electronic documents and in the wrong position. - Fix the position to add the "moneda" tag for invoices, liquidations, credit notes and fix the tests for this electronic documents. Forward-Port-Of: odoo/enterprise#58932

- In PR #54687, a currency tag label "moneda" was added for all electronic documents and in the wrong position.
- Fix the position to add the "moneda" tag for invoices, liquidations, credit notes and fix the tests for this electronic documents.

Forward-Port-Of: odoo/enterprise#58932

Previously, the availability widget showed non-rental info, even for rental order lines. This was because the rental dates were never passed to the widget. This commit ensures the rental dates are passed. opw-3700809 Forward-Port-Of: odoo/enterprise#59015

Previously, the availability widget showed non-rental info, even for rental order lines. This was because the rental dates were never passed to the widget. This commit ensures the rental dates are passed.

opw-3700809

Forward-Port-Of: odoo/enterprise#59015

This PR contains a revamp of the digest email in the new "Milk" style replacing the old purple with the new one. This has been adapted in all digest data too. The images of the digest email's tips have been replaced by "milkified" versions of them, already available on odoo cdn by the way. Task-3338467 Forward-Port-Of: odoo/enterprise#58992 Forward-Port-Of: odoo/enterprise#42790

This PR contains a revamp of the digest email in the new "Milk" style replacing
the old purple with the new one. This has been adapted in all digest data too.

The images of the digest email's tips have been replaced by "milkified"
versions of them, already available on odoo cdn by the way.

Task-3338467

Forward-Port-Of: odoo/enterprise#58992
Forward-Port-Of: odoo/enterprise#42790

In such a hierarchy: Clara -> Maxime -> Gregory Before this revision: Maxime and Gregory can validate Clara's timesheets, but only Maxime can edit fields of Clara's validated timesheets thanks to the fact he is the direct manager of Clara. Gregory is the manager of Clara by recursivity, and the recursivity was correctly handled in the validation check, but not in the edition of validated timesheets. After this revision: Maxime and Gregory can validate Clara's timesheets, Max

In such a hierarchy:

Clara -> Maxime -> Gregory

Before this revision:

Maxime and Gregory can validate Clara's timesheets,
but only Maxime can edit fields of Clara's validated timesheets thanks to the fact he is the direct manager of Clara.

Gregory is the manager of Clara by recursivity,
and the recursivity was correctly handled in the validation check, but not in the edition of validated timesheets.

After this revision:

Maxime and Gregory can validate Clara's timesheets,
Maxime and Gregory can edit fields of Clara's validated timesheets.

opw-3613473

Forward-Port-Of: odoo/enterprise#58874
Forward-Port-Of: odoo/enterprise#58782

Steps to reproduce: - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - In Contacts, Configure a bank account (Banco de la nación - BANCPEPL) for PE Company - In Accounting settings, run the automatic currency rates service ([PE] SUNAT) - Create a product: (e.g. Product X) * Sales Price: 990.00 * Withhold code: Arrendamiento de bienes muebles * Withhold Percentage: 10.00 - Create an invoice: * Customer: [a Peruvian contact] (e.g. Comercial Co

Steps to reproduce:
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- In Contacts, Configure a bank account (Banco de la nación - BANCPEPL) for PE Company
- In Accounting settings, run the automatic currency rates service ([PE] SUNAT)
- Create a product: (e.g. Product X)
  * Sales Price: 990.00
  * Withhold code: Arrendamiento de bienes muebles
  * Withhold Percentage: 10.00
- Create an invoice:
  * Customer: [a Peruvian contact] (e.g. Comercial Constructora los Patitos S.A.)
  * Operation Type: [1001] Operation Subject to Detraction
  * Payment terms: End of Following Month
  * Journal in: USD
  * Invoice Lines:
    - Product: Product X
    - Account: 7012100 Merchandise - Merchandise - Local sale - Third parties
    - Price: 990.00 
    - Taxes: 18% 
    - EDI Affect. Reason: Taxed- Onerous Operation
- Confirm the invoice
- Process to EDI service

Issue:
The remaining amount after deducting the withholding is not correct in the generated EDI document.
The total is 990.00 + Taxes (18%) = 1168.20
The withholding is 1168.20 * 10% = 116.82
The remaining amount should be 1168.20 - 116.82 = 1051,38
However, the remaining amount set in the EDI document is 1052,20, which is not correct.

Cause:
The rounding used to compute the withholding amounts are not correct.
The amount in the selected currency should contain 2 decimal digits (precision_rounding should be 0.01, instead of 2).
Also, the Detraction amount should be declared in PEN currency in the EDI document and should not contain the decimal part (precision_rounding should be 1, instead of 2).

opw-3747620

Forward-Port-Of: odoo/enterprise#58944
Forward-Port-Of: odoo/enterprise#58473

When disposing of an asset after an increase, we have 2 assets in the recordset. Where we should have used `asset`, we used `self` Forward-Port-Of: odoo/enterprise#58838

When disposing of an asset after an increase, we have 2 assets in the recordset.
Where we should have used `asset`, we used `self`

Forward-Port-Of: odoo/enterprise#58838

When the user imports CSV file of a bank statement and the file has an empty date in one of the rows, a traceback will appear. Steps to reproduce the error: - Go to Accounting > Dashboard > Bank > Import Statement - Select a CSV file that has an empty date in one of the rows > Upload Traceback: ``` TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date' File "odoo/http.py", line 2157, in __call__ response = request._serve_db() File "odoo/http.py", l

When the user imports CSV file of a bank statement and the file has an empty date in one of the rows,
a traceback will appear.

Steps to reproduce the error:
- Go to Accounting > Dashboard > Bank > Import Statement
- Select a CSV file that has an empty date in one of the rows > Upload

Traceback:
```
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 466, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "home/odoo/src/enterprise/17.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py", line 121, in execute_import
    res = super().execute_import(fields, columns, options, dryrun=dryrun)
  File "addons/base_import/models/base_import.py", line 1313, in execute_import
    input_file_data = self._parse_import_data(input_file_data, import_fields, options)
  File "home/odoo/src/enterprise/17.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py", line 68, in _parse_import_data
    if dates != sorted(dates):
```

https://github.com/odoo/enterprise/blob/312b4e5df327b25e1678755b24bd27803720cd3d/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L104-L105 
Here, When one of the dates is empty, line[index_date] will be None,
So, when it tries to sort dates at "sorted(dates)",
It will lead to above traceback.

sentry-4687473224

Forward-Port-Of: odoo/enterprise#58605
Forward-Port-Of: odoo/enterprise#52019

**Before this PR:** Status icons in the embedded view were overlapping with the menu. **After this PR:** The issue has been resolved, and now the menu is displayed correctly over the icons. **Task**-3717057 Forward-Port-Of: odoo/enterprise#56926

**Before this PR:**
Status icons in the embedded view were overlapping with the menu.

**After this PR:**
The issue has been resolved, and now the menu is displayed correctly over the icons.

**Task**-3717057

Forward-Port-Of: odoo/enterprise#56926

Forward-Port-Of: odoo/enterprise#58846

Forward-Port-Of: odoo/enterprise#58846

In studio, click on the "Automation" menu item. Create, or edit, one base.automation record, and modify some fields. Hit the button "Close" to get out of Studio. Before this commit, the base automation record was not saved. This was because the studio's action service did not receive the clear uncommitted changes from the main one. After this commit, the record is saved when we leave studio. Note that the ViewEditor mode should not be affected as we operate under a clean owl environmen

In studio, click on the "Automation" menu item.
Create, or edit, one base.automation record, and modify some fields. Hit the button "Close" to get out of Studio.

Before this commit, the base automation record was not saved. This was because the studio's action service did not receive the clear uncommitted changes from the main one.

After this commit, the record is saved when we leave studio.

Note that the ViewEditor mode should not be affected as we operate under a clean owl environment in StudioView.

Forward-Port-Of: odoo/enterprise#59018
Forward-Port-Of: odoo/enterprise#58862

Steps to reproduce the problem: - create a product and list it on eBay - uncheck the sell on eBay setting for the product. Don't archive it - create a second product and list it to the existing listing in eBay - sync an order with that product ==> First created product is shown in the sale order The eBay_id stays on the product, even after unchecking the setting. This seems to be voluntary as when relisting a product, after some time without selling it on eBay for instance, this id will t

Steps to reproduce the problem:
- create a product and list it on eBay
- uncheck the sell on eBay setting for the product. Don't archive it
- create a second product and list it to the existing listing in eBay
- sync an order with that product ==> First created product is shown in the sale order

The eBay_id stays on the product, even after unchecking the setting. This seems to be voluntary as when relisting a product, after some time without selling it on eBay for instance, this id will then be used. We now take the first product that is checked as used in eBay.

opw-3503924

Forward-Port-Of: odoo/enterprise#58852

Versions -------- - 15.0+ Steps ----- 1. Have a public holiday; 2. add a planning slot overlapping the holiday; 3. go to Project / Reporting / Timesheets and Planning Analysis. Issue ----- Planned Hours includes holiday hours. Cause ----- The SQL query generating the report only looks at standard workdays. Solution -------- In the SQL query, add a left join on `resource.calendar.leaves` and only select dates date that don't overlap with an employee's leave. opw-3509155

Versions
--------
- 15.0+

Steps
-----
1. Have a public holiday;
2. add a planning slot overlapping the holiday;
3. go to Project / Reporting / Timesheets and Planning Analysis.

Issue
-----
Planned Hours includes holiday hours.

Cause
-----
The SQL query generating the report only looks at standard workdays.

Solution
--------
In the SQL query, add a left join on `resource.calendar.leaves` and only select dates date that don't overlap with an employee's leave.

opw-3509155

Forward-Port-Of: odoo/enterprise#58867
Forward-Port-Of: odoo/enterprise#56847

Since `account.full.reconcile` doesn't have a `display_name`, the header of the group is not displayed nicely. By grouping per `matching_number` instead, we can have a nicer display. Forward-Port-Of: odoo/enterprise#58840

Since `account.full.reconcile` doesn't have a `display_name`, the header of the group is not displayed nicely.
By grouping per `matching_number` instead, we can have a nicer display.

Forward-Port-Of: odoo/enterprise#58840

Currently, log-level errors occur when WhatsApp webhooks are called, and the app secret may be missed. This commit changes 'logger.error' to 'logger.warning' since this is not an error in the codebase. sentry-4482005357 Forward-Port-Of: odoo/enterprise#47521

Currently, log-level errors occur when WhatsApp webhooks are called, and the app secret may be missed.

This commit changes 'logger.error' to 'logger.warning' since this is not an error in the codebase.

sentry-4482005357

Forward-Port-Of: odoo/enterprise#47521

The amount rounding tour was broken. As it used `:contains(), it was always checking for a substring of the current value of a line. Since it has to wait for the change to open (rpc call), there was a lot of indeterminism. It is fixed by adding more robust extra triggers. Forward-Port-Of: odoo/enterprise#58285

The amount rounding tour was broken. As it used `:contains(), it was always checking for a substring of the current value of a line. Since it has to wait for the change to open (rpc call), there was a lot of indeterminism.

It is fixed by adding more robust extra triggers.

Forward-Port-Of: odoo/enterprise#58285

The Customs values for a commodity needs to be the values of the entire package. Currently, the value per unit is set which results in the following warning. ``` { 'Severity': 'WARNING', 'Source': 'crs', 'Code': '448', 'Message': 'The sum of internationalDetail commodities customs value amounts do not the equal the internationalDetail customs value amount; the greater customs value amount was used to rate.', 'LocalizedMessage': 'The sum of internationalDetail commodi

The Customs values for a commodity needs to be the values of the entire package. Currently, the value per unit is set which results in the following warning.

```
{
    'Severity': 'WARNING',
    'Source': 'crs',
    'Code': '448',
    'Message': 'The sum of internationalDetail commodities customs value amounts do not the equal the internationalDetail customs value amount; the greater customs value amount was used to rate.',
    'LocalizedMessage': 'The sum of internationalDetail commodities customs value amounts do not the equal the internationalDetail customs value amount; the greater customs value amount was used to rate.',
    'MessageParameters': []
}
```

A previous fix https://github.com/odoo/enterprise/pull/38056 missed to correct the value for rating api so a following fix https://github.com/odoo/odoo/pull/116068 was made, which made the first fix obsolete + incorrect. The followup PR missed adjusting the FedEx value to match its change (i.e. other carriers were checked, but FexEx was overlooked) This commit corrects this issue and sets the correct commodity value for FedEx.

This corrects the sequence of arguments passed to the method
`_fedex_update_srm` The method on the super class is intended to be
overridden to add additional information on the Fedex Request.
The incorrect sequence of arguments restricts it from being overridden
correctly.

Forward-Port-Of: odoo/enterprise#58734

Steps to produce: - add new form from editor on website - add action create ticket on it - submit ticket on multi-company environment. Cause: access error while submit ticket with multi-company Solution: access ticket using sudo resolve this issue. task-3635784 Forward-Port-Of: odoo/enterprise#58882 Forward-Port-Of: odoo/enterprise#53389

Steps to produce:

- add new form from editor on website
- add action create ticket on it
- submit ticket on multi-company environment.

Cause: access error while submit ticket with multi-company

Solution: access ticket using sudo resolve this issue.

task-3635784

Forward-Port-Of: odoo/enterprise#58882
Forward-Port-Of: odoo/enterprise#53389