Steps to reproduce: * Open the form view of any UoM category. * Add a new line in the units list. * Without saving, Uncheck "Active" checkbox. * Before saving, change the type of this unit to reference. * Save the form. Expected behavior: An error should be thrown as it's not allowed to have more than one reference unit for some category. Current behavior: The record is normally saved without any errors. This issue caused an inconsistency when upgarding a database in such state t

Steps to reproduce:
* Open the form view of any UoM category.
* Add a new line in the units list.
* Without saving, Uncheck "Active" checkbox.
* Before saving, change the type of this unit to reference.
* Save the form.

Expected behavior:
An error should be thrown as it's not allowed to have more than one reference unit for some category.

Current behavior:
The record is normally saved without any errors.

This issue caused an inconsistency when upgarding a database in such state to saas18.1, where each unit points to its reference as a parent. Having multiple references in the same category caused a having a cycle in this link.

See: https://github.com/odoo/upgrade/blob/master/migrations/uom/saas~18.1.1.0/pre-migrate.py#L16-L25

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

Forward-Port-Of: odoo/odoo#197634

Avoids inconsistencies, simplifies control flow sometimes. Not all manual savepoints are converted: - The implementation details of `Savepoint` can't exactly be converted. - The test case savepoint is difficult to convert as the savepoint name / id is "leaked" for historical reasons, but also `test_mail_bounce_during_send` does exceedingly strange stuff and needs to re-create the test savepoint because it commits multiple times... Forward-Port-Of: odoo/odoo#198537

Avoids inconsistencies, simplifies control flow sometimes.

Not all manual savepoints are converted:

- The implementation details of `Savepoint` can't exactly be converted.
- The test case savepoint is difficult to convert as the savepoint name / id is "leaked" for historical reasons, but also `test_mail_bounce_during_send` does exceedingly strange stuff and needs to re-create the test savepoint because it commits multiple times...

Forward-Port-Of: odoo/odoo#198537

The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. Forward-Port-Of: odoo/odoo#198500

The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test).

This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us.

Forward-Port-Of: odoo/odoo#198500

**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A

**Issue Description**
When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A).

This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records.

**Steps to Reproduce**
1. Create a BoM (Bill of Materials) that includes Product A as a by-product with a quantity of 1.
2. Create a Manufacturing Order (MO) from this BoM.
3. Confirm the MO and set it to In Progress.
4. In the MO interface: Change the by-product from Product A to Product B.
5. Complete the MO.


https://github.com/user-attachments/assets/811e181d-894d-4605-aeb9-027ff379d40d



**Current Behavior**
The product in the stock.move is updated to Product B. However, the product in the related stock.move.line remains as Product A.

**Expected Behavior**
The byproduct's product_id shouldn't even be editable in the first place when the MO has already been confirmed (as it is for components).
It would be worth to add the same kind of readonly condition on the byproduct side as well.





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

Forward-Port-Of: odoo/odoo#197381
Forward-Port-Of: odoo/odoo#194972

Before this commit, when the user creates a project in the form and select a stage to directly put it in another stage then the first one given as default value. The stage is changed to set again the project in the default stage instead of keeping the choice made by the user. This commit makes sure the stage chosen by the user is still kept once the project is created. Steps to reproduce: ------------------ 1. Install project 2. Go to Project > Configuration > Settings 3. Enable the Pr

Before this commit, when the user creates a project in the form and select a stage to directly put it in another stage then the first one given as default value. The stage is changed to set again the project in the default stage instead of keeping the choice made by the user.

This commit makes sure the stage chosen by the user is still kept once the project is created.

Steps to reproduce:
------------------
1. Install project
2. Go to Project > Configuration > Settings
3. Enable the Project Stage feature
4. Go to Project > Configuration > Projects
5. Click on new button to create a new project
6. Set the project name and click on the second project stage

Current Behavior:
----------------
The project goes back to the default stage instead of staying in the stage selected by the user.

Expected Behavior:
-----------------
The project should be in the stage selected.

Forward-Port-Of: odoo/odoo#198452

Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were. In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR. The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different emai

Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were.

In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR.

The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different email addresses appart (for debugging). Redaction so it hard to find the original email address back (for privacy). It must also be simple.

We conducted several experiments using a dataset of 600ish email address (95% of which have a local part that is at least 6 characters long) to determine a nice function. The final function keep the first character for shorter inputs (length of local part < 6) and the first plus two lasts chars for longer inputs (>=6). Using that function we achieve a 99% disambiguation of emails in the dataset (with or without redacting the domain) while retaining minimal info (3 chars at most).

Redacting the domain isn't that useful as most addresses use gmail, hotmail, outlook, yahoo.

Task-4361561

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#192724
Forward-Port-Of: odoo/odoo#188697

Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed. This com

Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed.

This commit adds a condition to determine to know if a timesheet is not billed. The timesheet should now be:
- not linked to an invoice
- or the invoice linked should be cancelled and payment status should not be "Invoicing App Legacy".

Steps to reproduce the issue:
----------------------------
1. install Accounting, Sales and Timesheets app
2. Create a SO with a service product and confirm the SO
3. Create a timesheet for the SOL contained the service product
4. Create a invoice to partially invoice the service made for the SO.
5. Go to "Accounting app > Settings"
6. Enable the "Invoicing Switch Threshold" feature and make sure the date set on that feature is most recent than the one set on the invoice created in step 4. By doing that, the invoice created in step 4 should now be cancelled but with payment status set to "Invoicing App Legacy".
7. Create another timesheet for the same SOL
8. Go back to the SO created in step 2 and create another invoice to invoice the another timesheet.

Current behavior:
----------------

The timesheet linked to the first invoice is now linked to the second one with the other timesheet.

Expected behavior:
------------------

Since the first invoice is not really cancelled, the timesheet should still be linked to the invoice and so that timesheet should be considered as billed.

opw-4556956

Forward-Port-Of: odoo/odoo#198516
Forward-Port-Of: odoo/odoo#198277

Steps to reproduce the issue: - Create a storable product P1. - Create a subcontracted product P2. - Create a receipt with 5 units of P1 and P2. - Mark it as To Do. - Set the quantities as follows: - P1 -> 2 units - P2 -> 2 units - Validate the receipt and create a backorder. Problem: A picking is validated with only 2 units of P2, and a backorder is created with 5 units of P1 and 3 units of P2, instead of correctly validating the picking with: - P1 -> 2 units -

Steps to reproduce the issue:
- Create a storable product P1.
- Create a subcontracted product P2.
- Create a receipt with 5 units of P1 and  P2.
    - Mark it as To Do.
    - Set the quantities as follows:
- P1 -> 2 units
- P2 -> 2 units
      - Validate the receipt and create a backorder.

Problem:
A picking is validated with only 2 units of P2, and a backorder is
created with 5 units of P1 and 3 units of P2, instead of correctly
validating the picking with:
 - P1 -> 2 units
 - P2 -> 2 units
And creating a backorder with:
 - 3 units of P1
 - 3 units of P2

This occurs because, when updating the move for P2 from 5 to 2, a move
line is created and marked as picked. As a result, when computing the
picked value for the move, it is also marked as picked:
 https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock/models/stock_move.py#L206-L207
Thus, when validating the picking, since only the move for P2 is marked
as picked, it is the only one that gets validated.

opw-4357997

Forward-Port-Of: odoo/odoo#189481

Revert of commit ca1fa38815070325e3b998efcc0ec0d663b2f3b8 The fix introduced the impossibility of manually editing the duration days of attendances due to a depends cycle. The duration days of attendance should be manually editable. Forward-Port-Of: odoo/odoo#198379

Revert of commit ca1fa38815070325e3b998efcc0ec0d663b2f3b8 

The fix introduced the impossibility of manually editing the duration days of attendances due to a depends cycle.
The duration days of attendance should be manually editable.

Forward-Port-Of: odoo/odoo#198379

Before this commit, when tips were enabled after payment and early receipt printing was enabled, clicking on Bill would show the suggested tips on the Bill screen, but they were not included when printing the receipt. opw-4455884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196871 Forward-Port-Of: odoo/odoo#192726

Before this commit, when tips were enabled after payment and early receipt printing was enabled, clicking on Bill would show the suggested tips on the Bill screen, but they were not included when printing the receipt.

opw-4455884

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

Forward-Port-Of: odoo/odoo#196871
Forward-Port-Of: odoo/odoo#192726

Follow-up to #190162 Steps to reproduce: - Create a new Manufacturing Order - Set a product that is in stock as component with a quantity of 1 - Confirm the Manufacturing Order Issue: The component will be displayed in yellow (i.e. overconsumption), as the condition checks always on `should_consume_qty`, which is the quantity that should be used for that amount of `qty_producing`. But that quantity will *always* be 0 for confirmed MOs, as the `qty_producing` will be 0 at the time. I

Follow-up to #190162

Steps to reproduce:
- Create a new Manufacturing Order
- Set a product that is in stock as component with a quantity of 1
- Confirm the Manufacturing Order

Issue:
The component will be displayed in yellow (i.e. overconsumption), as the condition checks always on `should_consume_qty`, which is the quantity that should be used for that amount of `qty_producing`. But that quantity will *always* be 0 for confirmed MOs, as the `qty_producing` will be 0 at the time.

Instead, while the MO isn't started yet, we can simply compare to the demand to see if there's enough reservation.

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

Forward-Port-Of: odoo/odoo#198593

Before this commit all systray items of website were hidden for users that did not have the Restricted Editor right. This commit limits only some of the items to users having the Restricted Editor right: - Published: unrelated - Mobile preview: unrelated - Website switcher: unrelated - + New: Restricted Editor only - Edit in backend: unrelated - Translate: Restricted Editor only - Edit: Restricted Editor only It therefore now shows the Published button only based on the result of th

Before this commit all systray items of website were hidden for users that did not have the Restricted Editor right.

This commit limits only some of the items to users having the Restricted Editor right:
- Published: unrelated
- Mobile preview: unrelated
- Website switcher: unrelated
- + New: Restricted Editor only
- Edit in backend: unrelated
- Translate: Restricted Editor only
- Edit: Restricted Editor only

It therefore now shows the Published button only based on the result of the `_compute_can_publish` method of the `website.published.mixin`. The default implementation now checks whether the user has write access to the `website_published` field on the record.

Steps to reproduce:
- Install `website_crm_partner_assign`.
- Connect as a user without any Website role, and in Sales, the "User: Own Documents Only" role.
- Go to a partner in the `/partners` page. => "Published" button did not appear.

And on the contrary:
- Connect as a Restricted Editor user without Sales rights.
- Go to a partner in the `/partners` page.
- Click on "Published". => An access right error notification did appear.

task-3175890

Forward-Port-Of: odoo/odoo#195866
Forward-Port-Of: odoo/odoo#112421

Before this commit we had a schemeID equals to TN every time. But it should be equals to TN only if the partner is from 'JO' otherwise 'PN' task: 4547131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196619

Before this commit we had a schemeID equals to TN every time. But it should be equals to TN only if the partner is from 'JO' otherwise 'PN'

task: 4547131




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

Forward-Port-Of: odoo/odoo#196619

The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ. The main issue is `python3-gevent` which is missing in the control file. With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages.

The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ.

The main issue is `python3-gevent` which is missing in the control file.

With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages.

*  `python3-cryptography` is installed by `python3-openssl`
*  `python3-idna` and `python3-urllib3` are installed by `python3-requests` 
*  `python3-markupsafe` is installed by `python3-jinja2`

Forward-Port-Of: odoo/odoo#198102
Forward-Port-Of: odoo/odoo#197302

Before this commit, inset call participant cards had no background, which would let some elements of the UI from below it to show when the video does not have a 16:9 aspect ratio. Before (inset card mask is transparent) <img width="198" alt="Screenshot 2025-02-19 at 15 58 56" src="https://github.com/user-attachments/assets/358a072d-d949-4e81-9ef7-7b09c2dd5c56" /> After (inset card mask is filled) <img width="189" alt="Screenshot 2025-02-19 at 15 59 34" src="https://github.com/user-attach

Before this commit, inset call participant cards had no background, which would let some elements of the UI from below it to show when the video does not have a 16:9 aspect ratio.

Before (inset card mask is transparent)
<img width="198" alt="Screenshot 2025-02-19 at 15 58 56" src="https://github.com/user-attachments/assets/358a072d-d949-4e81-9ef7-7b09c2dd5c56" />

After (inset card mask is filled)
<img width="189" alt="Screenshot 2025-02-19 at 15 59 34" src="https://github.com/user-attachments/assets/df32dbc8-d042-4802-a9b4-2f3d93e97963" />

Forward-Port-Of: odoo/odoo#198320

They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change. Forward-Port-Of: odoo/enterprise#79815

They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted.

Using non-flushing savepoint to avoid risks of behaviour change.

Forward-Port-Of: odoo/enterprise#79815

The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups - I was not able to remove the view file as it will affect our database and that may affect the system. - We may need to remove that file in the master Task-4567218 Forward-Port-Of: odoo/enterprise#79111

The Book keeper was not able to see the General info of bank accounts and so on

- The problem was that there was an xpath that overwrite the groups
- I was not able to remove the view file as it will affect our database and that may affect the system.
- We may need to remove that file in the master

Task-4567218

Forward-Port-Of: odoo/enterprise#79111

In scenarios where invoices are in USD and payments in MXN, the SAT requires the 'equivalenciaDR' (exchange rate) to reflect how many units of the invoice currency (USD) equal one unit of the payment currency (MXN). Previously, using the official exchange rate and rounding could produce one- or two-cent differences, causing some PACs (e.g., Quadrum) to reject the payment CFDI (CRP20268 error). This replaces the use of the official rate (and its rounding) with the absolute quotient of the invo

In scenarios where invoices are in USD and payments in MXN, the SAT requires the 'equivalenciaDR' (exchange rate) to reflect how many units of the invoice currency (USD) equal one unit of the payment currency (MXN). Previously, using the official exchange rate and rounding could produce one- or two-cent differences, causing some PACs (e.g., Quadrum) to reject the payment CFDI (CRP20268 error).

This replaces the use of the official rate (and its rounding) with the absolute quotient of the invoice and payment amounts (`invoice_amount / payment_amount`). This approach removes rounding discrepancies and ensures consistent values in the XML, preventing these rejections.

Forward-Port-Of: odoo/enterprise#79038

The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will

The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test).

This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us.

For `web_gantt` the savepoint is closed but not on all paths (if `ValueError` is raised the savepoint is never rolled back let alone closed), the manual use is also rather unnecessary as we can just rollback around the relevant method call, none of the later mess interacts with the cursor / connection.

Forward-Port-Of: odoo/enterprise#79797

These fields shouldn't have a namespace. Removing them indeed makes the validation with the xsd succeed. We also clean the xml, by removing whitespaces. Forward-Port-Of: odoo/enterprise#79200

These fields shouldn't have a namespace.
Removing them indeed makes the validation with the xsd succeed.
We also clean the xml, by removing whitespaces.

Forward-Port-Of: odoo/enterprise#79200

The Bookkeeper should be allowed to create modify and remove the asset as requested - I have edited the security file in asset model making it group_account_user task-4567264 Forward-Port-Of: odoo/enterprise#79106

The Bookkeeper should be allowed to create modify and remove the asset as requested
- I have edited the security file in asset model making it group_account_user

task-4567264

Forward-Port-Of: odoo/enterprise#79106

Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line. Now we only take the first tax found in database. opw-4493544 Forward-Port-Of: odoo/enterprise#79695

Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line.

Now we only take the first tax found in database.

opw-4493544

Forward-Port-Of: odoo/enterprise#79695

We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none Forward-Port-Of: odoo/enterprise#79790

We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar.

task-none

Forward-Port-Of: odoo/enterprise#79790

Forward-Port-Of: odoo/enterprise#79660

Forward-Port-Of: odoo/enterprise#79660

Related to https://github.com/odoo/odoo/pull/195866. Now that `Can publish` is based on access rights, some extra queries are needed when `website` is installed. Note that the `appointment`-only and `appointment.hr`-only counts are unchanged. task-3175890 Forward-Port-Of: odoo/enterprise#79231

Related to https://github.com/odoo/odoo/pull/195866.

Now that `Can publish` is based on access rights, some extra queries are needed when `website` is installed.

Note that the `appointment`-only and `appointment.hr`-only counts are unchanged.

task-3175890

Forward-Port-Of: odoo/enterprise#79231

This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions. `url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc. task-4583612 Forward-Port-Of: odoo/enterprise#79834

This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions.

`url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc.

task-4583612

Forward-Port-Of: odoo/enterprise#79834