**Steps to reproduce the bug:** - Create a storable product “P1”: - Vendor: Azure Interior - Reordering rule: - Trigger: Auto - Route: Buy - Go to the user settings and give Marc Demo access only to Sales. - Log in as Marc. - Create a sales order: - Product: 1 unit of P1. - Confirm the SO. - A purchase order is created. - Create a second SO with another 1 unit of P1. - Confirm it. **Problem:** An error is triggered: `odoo.exceptions.AccessError: You are not al

**Steps to reproduce the bug:**

- Create a storable product “P1”:
  - Vendor: Azure Interior
  - Reordering rule:
    - Trigger: Auto
    - Route: Buy

- Go to the user settings and give Marc Demo access only to Sales.
- Log in as Marc.
- Create a sales order:
  - Product: 1 unit of P1.
- Confirm the SO.
- A purchase order is created.
- Create a second SO with another 1 unit of P1.
- Confirm it.

**Problem:**
An error is triggered:
`odoo.exceptions.AccessError: You are not allowed to access 'Purchase Order Line' (purchase.order.line) records.`

When the second SO is confirmed, a quantity request is made, triggering the "buy" rule. A check is made if there is a candidate “purchase order line” with the same specifications to update its quantity instead of creating a new one:
https://github.com/odoo/odoo/blob/a9cbd2a2ae2e21f1ba14379aecd908c44497b8ab/addons/purchase_stock/models/stock_rule.py#L130-L136

The function `_update_purchase_order_line` is called, where access to the taxes associated with the purchase order line is attempted: https://github.com/odoo/odoo/blob/a9cbd2a2ae2e21f1ba14379aecd908c44497b8ab/addons/purchase_stock/models/stock_rule.py#L248

Since it’s a Many2Many field, a query is made to fetch all the records. However, because the user does not have access to the `account.tax` model, an error is triggered.

opw-4193125

Forward-Port-Of: odoo/odoo#181073

The demo failure stores the latest traceback when a failure happens. This does not always work well, for example when installing a chart template. In such cases, the only error given will be a generic parsing error pointing to the xml file triggering the call to try_loading, making it difficult to understand the exact issue. As this notification is intended for a developer in order to help investigating the error, a complete traceback would be better. This small change will instead use t

The demo failure stores the latest traceback when a failure happens.
This does not always work well, for example when installing a chart template.
In such cases, the only error given will be a generic parsing error pointing to the xml file triggering the call to try_loading, making it difficult to understand the exact issue.

As this notification is intended for a developer in order to help investigating the error, a complete traceback would be better.

This small change will instead use the traceback module to format the exception stored in the demo failure todo, which will give information about the exact cause of the issue.

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

Forward-Port-Of: odoo/odoo#189259

**Description of the issue/feature this PR addresses:** Improve job posting structured data with modifying remote job specific XML tags when the job is a remote job, in order to match the requirements from [Google Search results Job Posting structured data document](https://developers.google.com/search/docs/appearance/structured-data/job-posting) Currently Odoo website's job detail page with remote job is not passing the rich results test from [Google search rich result test](https://search.

**Description of the issue/feature this PR addresses:**
Improve job posting structured data with modifying remote job specific XML tags when the job is a remote job, in order to match the requirements from [Google Search results Job Posting structured data document](https://developers.google.com/search/docs/appearance/structured-data/job-posting)

Currently Odoo website's job detail page with remote job is not passing the rich results test from [Google search rich result test](https://search.google.com/test/rich-results), as jobLocation will be empty content when it is a remote job. In order to be eligible in appear in google's enriched search result, jobLocation should not be used in a remote job, instead jobLocationtype & applicantLocationRequirements should be applied.

**Current behavior before PR:**
Empty jobLocation content when the job is a remote job. No jobLocationType & applicantLocationsRequirement tag for remote job which not matching with google search result's requirement.

**Desired behavior after PR is merged:**
jobLocation tag will be removed if the job is a remote job. jobLocationType will be appeared and the content will be TELECOMMUTE, and applicantLocationRequirements will be company's country.

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

Forward-Port-Of: odoo/odoo#186706

Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal". This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'. This change remove the token when the privacy is changed at the time of the write() This change is done in the project module because it depends on "portal", and not the other way around. This change can also be

Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal".

This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'.

This change remove the token when the privacy is changed at the time of the write()

This change is done in the project module because it depends on "portal", and not the other way around.

This change can also be used as an invalidation mecanism in case of a token leak. Changing the privacy to
'private' then to 'portal' will allow for an invalidation of the previous token and the creation of new one.

opw-4104804
task-4354145

Closes #176177

Forward-Port-Of: odoo/odoo#189218
Forward-Port-Of: odoo/odoo#188264

When uploading invoices in EFFF format taxes were not applied even though the XML file correctly defined them. The issue came from not taking the `<cbc:Percent>` tag into account when outside of `{*}TaxCategory` tag. This commit adds support both structures by checking for the `<cbc:Percent>` tag within `<cac:TaxSubtotal>` and outside of it. task-4348339 Forward-Port-Of: odoo/odoo#188859 Forward-Port-Of: odoo/odoo#188062

When uploading invoices in EFFF format taxes were not applied even though the XML file correctly defined them.
The issue came from not taking the `<cbc:Percent>` tag into account when outside of `{*}TaxCategory` tag.

This commit adds support both structures by
checking for the `<cbc:Percent>`
tag within `<cac:TaxSubtotal>` and outside of it.

task-4348339

Forward-Port-Of: odoo/odoo#188859
Forward-Port-Of: odoo/odoo#188062

In this commit, we fix this tour that failed each hour at minute 31 when the tour is runned at this time. The goal is to check the message text content and not the hour it was sent. runbot-error-id~108435 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#189266

In this commit, we fix this tour that failed each hour at minute 31 when the tour is runned at this time. The goal is to check the message text content and not the hour it was sent.

runbot-error-id~108435

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#189266

Version: 17.0+ Issue: If there is no partner on the stock moves, the delivery address will not display on the delivery slip. Purpose of this PR: Change the logic to use the stock.picking partner so that the delivery address will be printed on the delivery slip. Steps to reproduce on runbot: 1) create a receipt transfer 2) return the receipt transfer 3) print the delivery slip for the return 4) view that there is no delivery address, only the warehouse address Notes: There are

Version: 17.0+

Issue:
If there is no partner on the stock moves, the delivery address will not display on the delivery slip.

Purpose of this PR:
Change the logic to use the stock.picking partner so that the delivery address will be printed on the delivery slip.

Steps to reproduce on runbot:
1) create a receipt transfer
2) return the receipt transfer
3) print the delivery slip for the return
4) view that there is no delivery address, only the warehouse address

Notes:
There are three conditions that must be met for the delivery address to be printed on the delivery slip.
- there are stock moves
- the first stock move has a partner
- the picking type code is outgoing

With the above workflow, the stock moves are not assigned a partner although a partner is assigned on the picking.

opw-4177811

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

Forward-Port-Of: odoo/odoo#180677

At the moment, when `l10n_ke_edi_oscu_stock` is installed, the purchase order view is broken for users that don't belong to the `account.group_account_invoice` group, because they don't have access to the `l10n_ke_edi.customs.import` model. This commit restricts the `l10n_ke_customs_import_ids` field on the `purchase.order` view to the `account.group_account_invoice` so that this error no longer occurs. runbot-70725 Forward-Port-Of: odoo/enterprise#74893

At the moment, when `l10n_ke_edi_oscu_stock` is installed, the purchase order view is broken for users that don't belong to the `account.group_account_invoice` group, because they don't have access to the `l10n_ke_edi.customs.import` model.

This commit restricts the `l10n_ke_customs_import_ids` field on the `purchase.order` view to the `account.group_account_invoice` so that this error no longer occurs.

runbot-70725

Forward-Port-Of: odoo/enterprise#74893

Forward-Port-Of: odoo/enterprise#74889

Forward-Port-Of: odoo/enterprise#74889

Steps to reproduce: - Insert a pivot from CRM - Create a global filter, with type date or text => The id field can be selected With this commit, field `id` is now available only on relational global filters. Task: 4348477 Forward-Port-Of: odoo/enterprise#74191

Steps to reproduce:
- Insert a pivot from CRM
- Create a global filter, with type date or text => The id field can be selected

With this commit, field `id` is now available only on relational global filters.

Task: 4348477

Forward-Port-Of: odoo/enterprise#74191

Current behavior: --- When putting product in packs, the quantity done amount can be like 10.1000000001 Expected behaviour: --- Should be rounded to 10.1 Steps to reproduce: --- 1. Install Purchase 2. Go to Settings, Inventory 3. Activate Packages 4. Go to Products 5. Create a new product 6. Set inventory > Tracking: By Lots 7. Go to Purchase, new Requests for Quotation 8. Add the new lot product, quantity 13.5 9. Click on Confirm order 10. Go to Barcode, operations, receipt

Current behavior:
---
When putting product in packs, the quantity done amount can be like 10.1000000001

Expected behaviour:
---
Should be rounded to 10.1

Steps to reproduce:
---
1. Install Purchase
2. Go to Settings, Inventory
3. Activate Packages
4. Go to Products
5. Create a new product
6. Set inventory > Tracking: By Lots
7. Go to Purchase, new Requests for Quotation
8. Add the new lot product, quantity 13.5
9. Click on Confirm order
10. Go to Barcode, operations, receipts
11. Select the last created receipt
12. Edit the line, input 5.66, save
13. Click on Put in pack
14. Select the empty line in the pack
15. Input 4.44, save
16. The first quantity is 10.1000000001

opw-3821629

Forward-Port-Of: odoo/enterprise#69524
Forward-Port-Of: odoo/enterprise#59401

**Email layout is not translated to targeted sender's language with Sign mails** Impacted versions: - 16.0 - 17.0 - 18.0 Steps to reproduce: 1. Create a partner with language other than the current user's language. 2. Create a sign request and send the request to the created partner. 3. The strings from the email layout like Odoo's `Powered By` and `Your Document` (Your Signature Request) are not translated to the partner's language, but translated with the user's language. This

**Email layout is not translated to targeted sender's language with Sign mails**

Impacted versions:
- 16.0
- 17.0
- 18.0
 
Steps to reproduce:
 1. Create a partner with language other than the current user's language.
 2. Create a sign request and send the request to the created partner.
 3. The strings from the email layout like Odoo's `Powered By` and `Your Document` (Your Signature Request) are not translated to the partner's language, but translated with the user's language. This differs from the language in the body.
 
Current behavior:

Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies.  

Expected behavior:

After this commit, only the language given in the kwargs is used and therefore fixing the translations issues.

Forward-Port-Of: odoo/enterprise#73784

Steps to reproduce =================== - Open the resource schedule, and go into day mode. - Switch to tomorrow, and click new. - The start date has been changed but not the end date, which is still now +duration. - Which creates a default duration of `-23:00 hours`. Second issue: - Open the resource type appointment and then create the booking from the Gantt view using the new button. - We get the wrong appointment type there. Technical =========== - Earlier, the stop was c

Steps to reproduce
===================
- Open the resource schedule, and go into day mode.
- Switch to tomorrow, and click new.
- The start date has been changed but not the end date, which is still
  now +duration.
- Which creates a default duration of `-23:00 hours`.

Second issue:
- Open the resource type appointment and then create the booking from the Gantt
  view using the new button.
- We get the wrong appointment type there.

Technical
===========
- Earlier, the stop was calculated based on the current time instead of `start`
  in the default_stop. we set stop datetime inside `onAddClicked` by default to
  start + 1 hour to override the calendar.event's default_stop.

- Earlier, we fell into the condition of fetching only the user appointment when
  we were not providing any resources inside the default_get method, which led to
  having the user-based appointment instead of the resource-based one. Here, we
  added a separate condition to fetch the resource-based when going through the
  action of resource gantt.

After this PR
===================
- This PR addresses the issue and fixes it  by adding the default stop for
  1 hour after the start time and assigning the correct appointment type.

Task-4330924

Forward-Port-Of: odoo/enterprise#74144

This will add new rule parameter values for 2024 for the CP200 salary scales. Task: 4274766 Forward-Port-Of: odoo/enterprise#73080

This will add new rule parameter values for 2024 for the CP200 salary scales.

Task: 4274766

Forward-Port-Of: odoo/enterprise#73080

When synchronizing orders from Amazon with Avatax enabled, sales order lines currently show no taxes and incorrectly set the tax included price as being the subtotal. This occurs because the fiscal position used does not include any tax, which is the expected behavior for Avatax. The recomputation then uses the full amount of the line (which is tax included), and in the absence of tax, consider this is also the subtotal. We now intentionally do not consider the tax amount from Amazon

When synchronizing orders from Amazon with Avatax enabled, sales order
lines currently show no taxes and incorrectly set the tax included
price as being the subtotal.

This occurs because the fiscal position used does not include any tax,
which is the expected behavior for Avatax. The recomputation then uses
the full amount of the line (which is tax included), and in the absence
of tax, consider this is also the subtotal.

We now intentionally do not consider the tax amount from Amazon on the
order lines, because the distribution of the Amazon's given tax amount
is unknown. The multiple real taxes across that line is not an
information that Amazon gives us, and needs to be seen from Avatax.

This setup ensures that the subtotal on sales order lines remain
accurate.

opw-4214775

Forward-Port-Of: odoo/enterprise#74995
Forward-Port-Of: odoo/enterprise#74007