This PR introduces a local upgrade script to fix the duplicate UUID issue for customers who upgraded to 18.0 before this PR was merged: #194990 The creation of this local upgrade script was requested towards the end of the conversation on that PR. Before the above PR was merged, older POS [order, order.line, payment] records all got the same UUID during the upgrade to 18.0 for the reason laid out in the conversation on the PR: > [in reference to the default value for the uuid column c

This PR introduces a local upgrade script to fix the duplicate UUID issue for customers who upgraded to 18.0 before this PR was merged:

#194990 

The creation of this local upgrade script was requested towards the end of the conversation on that PR.

Before the above PR was merged, older POS [order, order.line, payment] records all got the same UUID during the upgrade to 18.0 for the reason laid out in the conversation on the PR:
> [in reference to the default value for the uuid column calling `uuid4()`] ... when the ORM inits the column it will set the same value for all rows.

Current behavior before PR:
Post-upgrade POS tickets get sent to Tech for us to clean manually via a server action that duplicates UUIDs.

Desired behavior after PR is merged:
Post-upgrade POS tickets can be solved in Functional by "Upgrading" the `point_of_sale` module **or** the customer doesn't need to create a ticket because they solved it themselves by upgrading their module.

Forward-Port-Of: odoo/odoo#201287
Forward-Port-Of: odoo/odoo#200067

Nothing prevents from creating templates and composers on non thread models. However most necessary code relies on mail.thread. Here we move code from mail.thread directly to BaseModel. For most business models it does not change anything. For some side models it allows / fixes usage of SMS composer, allowing to dynamically find numbers / partners, ... One notable use case that triggered this PR is sending of SMS to users using their work phone number, or through their partner. Either

Nothing prevents from creating templates and composers on non thread
models. However most necessary code relies on mail.thread.

Here we move code from mail.thread directly to BaseModel. For most
business models it does not change anything. For some side models
it allows / fixes usage of SMS composer, allowing to dynamically
find numbers / partners, ...

One notable use case that triggered this PR is sending of SMS to
users using their work phone number, or through their partner. Either
we hack user model, either we provide a generic fix.

Note that in current master (18.2+) most 'mail' generic features are
supported on non-thread models (template usage and sending, mailing
using composer, ...). SMS is still thread-specific while phone
capabilities have already been moved to generic code.

We therefore continue towards generic simple mail / sms usage on
business records, while advanced features (followers, logs, direct
post using SMS type) require thread-enabled models.

Task-4113190
sentry-4681535519

Forward-Port-Of: odoo/odoo#202809
Forward-Port-Of: odoo/odoo#200650

This commit add a new default filter on the analytic reporting view, which filters data based on date >= 1st day of last fiscal year. task-4453226 Forward-Port-Of: odoo/odoo#200030 Forward-Port-Of: odoo/odoo#194983

This commit add a new default filter on the analytic reporting view, which filters data based on date >= 1st day of last fiscal year.

task-4453226

Forward-Port-Of: odoo/odoo#200030
Forward-Port-Of: odoo/odoo#194983

We are switching away from Clearbit which is very unreliable. For that reason we had an autosync feature which would update IAP's data for a company based on the data provided in Odoo. Instead, we are now switching to Dun & Bradstreet which has much more reliable data. Some routes have been changed to target the new API on IAP. We continue to use Clearbit for the logos which are not provided by DnB (yet). This is a backport of https://github.com/odoo/odoo/pull/196373 where models, fi

We are switching away from Clearbit which is very
unreliable. For that reason we had an autosync
feature which would update IAP's data for a company based on the data provided in Odoo.

Instead, we are now switching to Dun & Bradstreet
which has much more reliable data. Some routes have been changed to target the new API on IAP.

We continue to use Clearbit for the logos which are not provided by DnB (yet).

This is a backport of https://github.com/odoo/odoo/pull/196373 where models, fields, and public methods have been kept to respect the stable policy.

task-4416928

Forward-Port-Of: odoo/odoo#202737
Forward-Port-Of: odoo/odoo#202546

**Current behavior before PR**: The 'mute conversation' button was always visible, even when 'mute all conversations' was enabled. **Desired behavior after PR is merged**: The 'mute conversation' button is hidden when 'mute all conversations' is enabled task-[4630970](https://www.odoo.com/odoo/project/1519/tasks/4630970) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202795 Forward-Port-Of: odoo/odoo#200623

**Current behavior before PR**:

The 'mute conversation' button was always visible, even when 'mute all conversations' was enabled.

**Desired behavior after PR is merged**:

The 'mute conversation' button is hidden when 'mute all conversations' is enabled

task-[4630970](https://www.odoo.com/odoo/project/1519/tasks/4630970)

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

Forward-Port-Of: odoo/odoo#202795
Forward-Port-Of: odoo/odoo#200623

When a user deletes a user-message in discuss or chatter, the message content is replaced by "This message has been removed". Some actions are still possible on the message, such as adding reactions. However some features do no make sense, like 'Translate', as the message has no content anymore and the "This message has been removed" is translated automatically to the user viewing this message. This commit fixes the issue by not showing the 'Translate' message action on deleted messages.

When a user deletes a user-message in discuss or chatter, the message content is replaced by "This message has been removed". Some actions are still possible on the message, such as adding reactions.

However some features do no make sense, like 'Translate', as the message has no content anymore and the "This message has been removed" is translated automatically to the user viewing this message.

This commit fixes the issue by not showing the 'Translate' message action on deleted messages.

Task-4661959

Forward-Port-Of: odoo/odoo#202730

Steps to reproduce: - In any of the SOL Many2one field with create=True. - Create a SOL using create option in dropdown. Issue: - A SOL is created without product. Reason: - Incorrect SQL constraint passed . Fix: - Adding a validation error which is tapped in if Many2one quick create i.e., Create option fails and opens the Many2X form. - We cant change the SQL contraint because it is only applied when module is intalled/updated/reinstalled. --- Why the SQL contsrai

Steps to reproduce:

- In any of the SOL Many2one field with create=True.
- Create a SOL using create option in dropdown.

Issue:

- A SOL is created without product.

Reason:

- Incorrect SQL constraint passed .

Fix:

- Adding a validation error which is tapped in if Many2one quick create i.e.,
Create option fails and opens the Many2X form.

- We cant change the SQL contraint because it is only applied when module
is intalled/updated/reinstalled.

---
Why the SQL contsraint fails

"CHECK(display_type IS NOT NULL OR is_downpayment OR (product_id IS NOT NULL AND product_uom IS NOT NULL))"

Also is_downpayment doesnt have a default value.

Here consider we dont event send a single value all as nulls then result would
be

CHECK(NULL IS NOT NULL OR NULL OR (NULL IS NOT NULL AND NULL IS NOT NULL))

CHECK(FALSE OR NULL OR (FALSE AND FALSE)

CHECK(FALSE OR NULL OR FALSE)

CHECK(NULL)

SQL doesn't categorize NULL into truthy or falsy value.

For example a SQL constraint as
CHECK (row1 NOT NULL OR row2 ...(and N number of conditions)) -- will always
pass the check (even if you pass all the rows as NULL)

NULL OR NULL -- TRUE (passes the empty NULL column value as [null])
FALSE OR NULL -- TRUE (passes the empty NULL column value as [null])
TRUE OR NULL -- TRUE

It there is another column which has value it glady create a row with values
and [null]/empty value for others.

task-4441043

Co-Authored By - @xavierbol

Forward-Port-Of: odoo/odoo#202769
Forward-Port-Of: odoo/odoo#192464

This reverts commit 43041dfd66e984978ad743c4f720e580f82bd1aa. It looks like Google and Microsoft flag custom headers as Spam. opw-4439329 opw-4458057 opw-4471333 opw-4492740 opw-4501103 opw-4503823 opw-4507802 opw-4517232 opw-4523135 opw-4529415 opw-4547995 opw-4556927 opw-4557754 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 a

This reverts commit 43041dfd66e984978ad743c4f720e580f82bd1aa.

It looks like Google and Microsoft flag custom headers as Spam.

opw-4439329
opw-4458057
opw-4471333
opw-4492740
opw-4501103
opw-4503823
opw-4507802
opw-4517232
opw-4523135
opw-4529415
opw-4547995
opw-4556927
opw-4557754

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#202812
Forward-Port-Of: odoo/odoo#200193

Requirements: l10n_it_edi, IT company - Change the exchange rate between EUR and USD (or any foreign currency) to 2. - Create an invoice in USD with one product priced at 100, then generate the XML. In the XML, PrezzoUnitario (price unit) is not equal to PrezzoTotale (price total), even though there is only one quantity. When using a currency other than the company currency, PrezzoUnitario is in the foreign currency (here, USD). Both PrezzoTotale and PrezzoUnitario should be in the comp

Requirements: l10n_it_edi, IT company

- Change the exchange rate between EUR and USD (or any foreign currency) to 2.

- Create an invoice in USD with one product priced at 100, then generate the XML.

In the XML, PrezzoUnitario (price unit) is not equal to PrezzoTotale (price total), even though there is only one quantity. When using a currency other than the company currency, PrezzoUnitario is in the foreign currency (here, USD). Both PrezzoTotale and PrezzoUnitario should be in the company currency.

The test test_export_foreign_currency xml has also been updated to reflect recent changes. Specifically, in the XML export: 

- The price unit is recorded as 1068.11(USD).
- To total price is recorded as 841.49(EUR) which was converted from 907.49(USD).
- Knowing there is a 15% discount, the correct unit price should be 841.49(EUR) / 0.85 = 990(EUR)
(similar logic to justify changing the other xml)

opw-4593300



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

Forward-Port-Of: odoo/odoo#200189

Reduce the memory footprint and slightly improve the performance of export, especially when we traverse multiple levels of relational fields. We replace the https://github.com/odoo/odoo/pull/22494 solution because it is only works at the top level of the export, to avoid invalidating records that may be used by the next iteration, and because the cache memory footprint of the cache has been reduced in recent years anyway. Instead, we explicitly read the only asked fields recursively. Memo

Reduce the memory footprint and slightly improve the performance of export, especially when we traverse multiple levels of relational fields.

We replace the https://github.com/odoo/odoo/pull/22494 solution because it is only works at the top level of the
export, to avoid invalidating records that may be used by the next iteration, and because the cache memory footprint of the cache has been reduced in recent years anyway. Instead, we explicitly read the only asked fields recursively.

Memory/Performance changes:

For exporting 10K of stock.picking (Transfers) with basic fields of the list view:
```
Before: 25 Mb of memory peak - 31 SQL requests, +- 55 ms of queries, +- 2440 ms of Python
After : 29 Mb of memory peak - 31 SQL requests, +- 45 ms of queries, +- 2402 ms of Python
```


For exporting 10K of stock.picking (Transfers) with their stock moves (30K) and their stock move line (4K):
```
Before: 191 Mb of memory peak - 162 SQL requests, +- 455 ms of queries, +- 7050 ms of Python
After : 140 Mb of memory peak - 129 SQL requests, +- 315 ms of queries, +- 6930 ms of Python
```

Forward-Port-Of: odoo/odoo#201041
Forward-Port-Of: odoo/odoo#199218

Current behaviour: --- Mexican phone numbers are not managed correctly following the 2019 changes in Mexico. (Removing a 1 in phone numbers) Cause of the issue: --- The phonenumbers library removing support of mexican phone numbers starting with 1 in 8.13.38 The Whatsapp API still using the mexican phone numbers starting with 1 Fixes: --- Patched the phonenumbers library, removing 1 at the right place for mexican phone numbers. Similar to: https://github.com/odoo/odoo/commit/53885

Current behaviour:
---
Mexican phone numbers are not managed correctly following the 2019 changes in Mexico.
(Removing a 1 in phone numbers)

Cause of the issue:
---
The phonenumbers library removing support of mexican phone numbers starting with 1 in 8.13.38
The Whatsapp API still using the mexican phone numbers starting with 1

Fixes:
---
Patched the phonenumbers library, removing 1 at the right place for mexican phone numbers.
Similar to: https://github.com/odoo/odoo/commit/53885e41867653ad45ca3aef55886c280240b76a

Changed the forcing to international format when parsing, to make sure the patches are applied before detecting an issue. 
Similar to: https://github.com/odoo/odoo/commit/29a4de8e29a2e330b8e5993c9fde23c69a2eff5e

opw-4473528

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

Forward-Port-Of: odoo/odoo#202295
Forward-Port-Of: odoo/odoo#197838

Steps to reproduce: - Install event_booth_sale module - Create SO. - Add product and apply any reward or promotion. - Try changing the quantity of the reward line. Issue: - Quantity of reward line is editable when event_booth_sale module is installed. Cause: - The readonly attribute was completely overridden instead of adding condition. - As a result, the quantity is only set to readonly when is_event_booth is True. Fix: - Update the readonly attribute by including the is_event_

Steps to reproduce:
- Install event_booth_sale module
- Create SO.
- Add product and apply any reward or promotion.
- Try changing the quantity of the reward line.

Issue:
- Quantity of reward line is editable when event_booth_sale module is installed.

Cause:
- The readonly attribute was completely overridden instead of adding condition.
- As a result, the quantity is only set to readonly when is_event_booth is True.

Fix:
- Update the readonly attribute by including the is_event_booth condition using the 'or' operator, ensuring that quantity of reward lines remain readonly as intended.

opw-4585797

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

Forward-Port-Of: odoo/odoo#202788
Forward-Port-Of: odoo/odoo#202653

If you open the same SO in two different tabs, confirming it in one tab while further modifying it in the other, the readonly restriction won't be considered and you might shoot yourself in the foot by modifying something you shouldn't have. This commit makes sure the product cannot be modified on order lines where it's not supposed to be possible (unless you try to be smart/dumb by opening it in two tabs, or two salesmen are modifying it separately). opw-4595008 --- I confirm I have s

If you open the same SO in two different tabs, confirming it in one tab while further modifying it in the other, the readonly restriction won't be considered and you might shoot yourself in the foot by modifying something you shouldn't have.

This commit makes sure the product cannot be modified on order lines where it's not supposed to be possible (unless you try to be smart/dumb by opening it in two tabs, or two salesmen are modifying it separately).

opw-4595008

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

Forward-Port-Of: odoo/odoo#202664

**Steps to reproduce:** - Install Accounting and l10n_sa_edi - Switch to a Saudi Arabian company (e.g. SA Company) - Duplicate "Customer Invoices" journal: * Default Income Account: 500001 Sales Account * Electronic invoicing: [disabled] - Create a retention tax: * Name: Retention 10% * Amount: -10.00000% * Is Retention: [checked] - Create an invoice: * Customer: [a Saudi Arabian contact] (e.g. ARAMCO Medinah Branch) * Journal: Customer Invoices * Invoice Lines:

**Steps to reproduce:**
- Install Accounting and l10n_sa_edi
- Switch to a Saudi Arabian company (e.g. SA Company)
- Duplicate "Customer Invoices" journal:
  * Default Income Account: 500001 Sales Account
  * Electronic invoicing: [disabled]
- Create a retention tax:
  * Name: Retention 10%
  * Amount: -10.00000%
  * Is Retention: [checked]

- Create an invoice:
  * Customer: [a Saudi Arabian contact] (e.g. ARAMCO Medinah Branch)
  * Journal: Customer Invoices
  * Invoice Lines:
    - Price: 100.00
    - Taxes: "Sales Tax 15%" + "Retention 10%"
- Confirm the invoice
- Print the invoice
- Scan the QR code on the invoice with an app like "E-invoice QR Reader"

=> In the QR code, the total amount of the invoice with VAT included is 115.00 and the total amount of the VAT is 15.00.
The amount of the retention tax is excluded from the total and the VAT amounts, which is the expected behavior.

- Create the exact same invoice with the duplicated journal without electronic invoicing
- Confirm the invoice
- Print the invoice
- Scan the QR code on the invoice

**Issue:**
In the QR code, the amount of the retention (-10.00) is taken into account.
The total amount of the invoice with VAT included is 105.00 and the total amount of the VAT is 5.00.
The QR code should provide the same amounts either the used journal has "Electronic invoicing" enabled or not.

**Cause:**
Depending on the presence of an electronic invoice document or not, the QR code is generated by the overriding compute method from "l10_sa_edi" or the original one in "l10n_sa".
However, the "Is Retention" field of the "account.tax" model is introduced by "l10n_sa_edi" module and when the QR code is computed by the original method, this field is not taken into account and the corresponding retention tax is wrongly handled like any other tax.

**Solution:**
Use the same total amounts than the ones computed in "l10n_sa_edi" (where retention tax are excluded) in the original compute method if "l10n_sa_edi" is installed.

**Issue 2:** (revealed by the fix)
In "_get_invoice_line_allowance_vals_list" method, a variable can be used without being assigned (i.e. "fixed_tax_charge_vals_list").

opw-4525519



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

Forward-Port-Of: odoo/odoo#196640

The aim of this commit is to allow non-users employee to be considered as "forwarding" vendor bills instead of sending it in their name, as the vendor would be the company anyway Steps to reproduce: - Create a fresh db with the mailing aliases setup and employee and account apps installed - Choose a demo data employee that has no user and set the parent_id as the db company. - Make sure the company doesn't have an email set. - Send an email from that employee work_email to the email alias

The aim of this commit is to allow non-users employee to be considered as "forwarding" vendor bills instead of sending it in their name, as the vendor would be the company anyway

Steps to reproduce:
- Create a fresh db with the mailing aliases setup and employee and account apps installed
- Choose a demo data employee that has no user and set the parent_id as the db company.
- Make sure the company doesn't have an email set.
- Send an email from that employee work_email to the email alias of the Vendor Bills journal.

Problem, the created bill has the employee set as the vendor.

Expected behavior is that no vendor is set.

opw-4516730

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

### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced

### Steps to reproduce:

- In the settings, enable multi-step routes.
- Set Warehouse to 2-step Manufacturing
- Create a BoM with an operation and one move raw: 1 x COMP
- Create confirm, plan and **start** an MO with that bom.
- Through Shop Floor, on your operation > Wheel > add components
- Set the quantity of COMP to 10 instead of 1.
#### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated

### Cause of the issue:

Adding a product already referenced as a raw material via the catalog will trigger a call of the `_update_order_line_info` which will update the demand of the move raw:
https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2895-L2898 https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2913-L2914 If you did not start the MO, this would run the procurement to update the demand and thus update the picking:
https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/stock_move.py#L434-L438 However, since the MO was started the state of the MO is 'in_progress' instead of 'confirmed'.

Note:

The issue was not reproducible before 18.0. Since adding a component was done via a call that would create and confirm a new move (hence running the procurements):
https://github.com/odoo/enterprise/blob/b3febe5a1afd5c1c8fd598db95e8c58fa4131563/mrp_workorder/wizard/additional_product.py#L63-L68

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

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

Forward-Port-Of: odoo/odoo#202332
Forward-Port-Of: odoo/odoo#201592

Steps to reproduce the bug: - Create a storable product “P1” - Go to Operations > Replenishment: - An orderpoint is created for “P1” - Click on the Snooze button: - Snooze for 1 day - Snooze date: today - The orderpoint for "P1" becomes invisible thanks to the “Snooze” filter - Refresh the page Problem: The snooze filter is correctly applied, but an orderpoint for "P1" is still visible. This happens because the old snoozed orderpoint was unlinked, and a new one was create

Steps to reproduce the bug:
- Create a storable product “P1”
- Go to Operations > Replenishment:
    - An orderpoint is created for “P1”
- Click on the Snooze button:
    - Snooze for 1 day
    - Snooze date: today
- The orderpoint for "P1" becomes invisible thanks to the “Snooze” filter
- Refresh the page

Problem:
The snooze filter is correctly applied, but an orderpoint for "P1" is still visible. This happens because the old snoozed orderpoint was unlinked, and a new one was created without the snoozed_until field set.

https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_orderpoint.py#L596-L599

opw-4628611

Forward-Port-Of: odoo/odoo#200777

Previously, the `lang` parameter was missing from the URL, and URLs were not correctly updated when a 308 redirect was present. This commit ensures that the `lang` parameter is added and that URLs are properly converted after a 308 redirect. Forward-Port-Of: odoo/odoo#202462

Previously, the `lang` parameter was missing from the URL, and URLs were not correctly updated when a 308 redirect was present.

This commit ensures that the `lang` parameter is added and that URLs are properly converted after a 308 redirect.

Forward-Port-Of: odoo/odoo#202462

We're skipping the unit test to check for indeterminisms with mutations. Indeed, the strategy for detecting this kind of indeterminism needs to be rethought, and for the moment, this test is failing in an indeterministic way (lol) in master. 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#20266

We're skipping the unit test to check for indeterminisms with mutations. Indeed, the strategy for detecting this kind of indeterminism needs to be rethought, and for the moment, this test is failing in an indeterministic way (lol) in master.

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

Steps: - Install sales and contact app. - Create a price-list and archive it. - Go to contact form and click on Sale stat button. - Create an SO and click on price-list field. Issue: - Archive price-list are visible in price-list field. Cause: - In [PR] added active_test and because of that user can select archive records from this action like price-list in our case. Fix: - Remove active_test context from these actions since active_test context already added on child_ids field

Steps:
- Install sales and contact app.
- Create a price-list and archive it.
- Go to contact form and click on Sale stat button.
- Create an SO and click on price-list field.

Issue:
- Archive price-list are visible in price-list field.

Cause:
- In [PR] added active_test and because of that user can select archive records from this 
action like price-list in our case.

Fix:
- Remove active_test context from these actions since active_test context already added
on child_ids field definition in [commit].

[PR]: https://github.com/odoo/odoo/pull/189270
[commit]: https://github.com/odoo/odoo/pull/165127/commits/310a8ab2a408d17d86026afc2c59063f5891bf3d

opw-4657678

Forward-Port-Of: odoo/odoo#202639

Steps to reproduce: - Open To-Do app - Open a todo and click on chatter - Go back and open another todo - The chatter is closed by default Issue: - The chatter should be opened if opened earlier - If todo opened from activity view chatter is not opened Reason: - No logic to preserve the state if chatter. Solution: - Using local storage to store the state of the chatter and thus apply changes accordingly. task-4592501 Forward-Port-Of: odoo/odoo#200518

Steps to reproduce:

- Open To-Do app
- Open a todo and click on chatter
- Go back and open another todo
- The chatter is closed by default

Issue:

- The chatter should be opened if opened earlier
- If todo opened from activity view chatter is not opened

Reason:

- No logic to preserve the state if chatter.

Solution:

- Using local storage to store the state of the chatter and thus apply changes accordingly.

task-4592501

Forward-Port-Of: odoo/odoo#200518

Currently, changing the plan of an analytic account won't do anything with regards to the analytic lines currently using that account: the value will stay recorded in a wrong field. This commit will update all the lines currently using that account in the column of the previous plan. opw-4338406 Forward-Port-Of: odoo/odoo#202207 Forward-Port-Of: odoo/odoo#199287

Currently, changing the plan of an analytic account won't do anything with regards to the analytic lines currently using that account: the value will stay recorded in a wrong field.

This commit will update all the lines currently using that account in the column of the previous plan.

opw-4338406

Forward-Port-Of: odoo/odoo#202207
Forward-Port-Of: odoo/odoo#199287

In order to avoid locking for longer periods, we want to put the sequence assignment as late as possible in the SQL transaction. In order to do that, we flush everything before assigning the number so that the ORM doesn't have to flush it implicitly before committing. We also reuse the same savepoint to avoid messing with the memory of Postgres Forward-Port-Of: odoo/odoo#202171 Forward-Port-Of: odoo/odoo#201171

In order to avoid locking for longer periods, we want to put the
sequence assignment as late as possible in the SQL transaction.
In order to do that, we flush everything before assigning the number so
that the ORM doesn't have to flush it implicitly before committing.

We also reuse the same savepoint to avoid messing with the memory of
Postgres

Forward-Port-Of: odoo/odoo#202171
Forward-Port-Of: odoo/odoo#201171

- Create an invoice and set its delivery date to a date other than today. - Generate the cii facturx xml. Under <ram:ActualDeliverySupplyChainEvent>, the date is incorrectly set to today instead of the invoice's delivery date. This commit applies the same treatment as https://github.com/odoo/odoo/commit/dda560005b2372ed8f6fa0cf3fd6c6f7ca0d1fe3 but for account_edi_xml_cii_facturx. opw-4531928 Description of the issue/feature this PR addresses: Current behavior before PR: Desi

- Create an invoice and set its delivery date to a date other than today.

- Generate the cii facturx xml.

Under <ram:ActualDeliverySupplyChainEvent>, the date is incorrectly set to today instead of the invoice's delivery date.

This commit applies the same treatment as https://github.com/odoo/odoo/commit/dda560005b2372ed8f6fa0cf3fd6c6f7ca0d1fe3 but for account_edi_xml_cii_facturx.

opw-4531928

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#202340
Forward-Port-Of: odoo/odoo#201230

This commit reverts 5594b08f8bd399e7c653ca25e6211ae64ea7d898 because while buyer reference is mandatory for B2G it is not for B2C and B2B: "The buyer reference must be indicated on every electronic invoice to public contracting authorities of the federal administration." https://en.e-rechnung-bund.de/e-invoicing-faq/buyer-reference/ opw-4460079 X-original-commit: f6af0b3285b4835256fa1ab7b729dc3b334abe76 Description of the issue/feature this PR addresses: Current behavior before

This commit reverts 5594b08f8bd399e7c653ca25e6211ae64ea7d898 because while buyer reference is mandatory for B2G it is not for B2C and B2B:

"The buyer reference must be indicated on every electronic invoice to public contracting authorities of the federal administration."

https://en.e-rechnung-bund.de/e-invoicing-faq/buyer-reference/

opw-4460079

X-original-commit: f6af0b3285b4835256fa1ab7b729dc3b334abe76

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

Steps: - Go to /shop as a guest (without logging in). - Select a pricelist different from the default. - Add a product to the cart and proceed to checkout. - Fill in the address form and submit. - Observe that the pricelist is reset to the default instead of retaining the selected one. Issue - When a user selects a pricelist on the /shop page without logging in, the selected pricelist resets to the default during checkout after filling in the address form. Cause - The upda

Steps:
- Go to /shop as a guest (without logging in).
- Select a pricelist different from the default.
- Add a product to the cart and proceed to checkout.
- Fill in the address form and submit.
- Observe that the pricelist is reset to the default instead of retaining the
  selected one.

Issue
- When a user selects a pricelist on the /shop page without logging in, 
  the selected pricelist resets to the default during checkout after filling in
  the address form.

Cause
- The update_address method updates the partner_id of the sale.order
- During this process, the write method triggers a recomputation that resets the
  pricelist_id to the default instead of preserving the user-selected pricelist.

Fix
- Assign the selected pricelist to partner_sudo.property_product_pricelist
  before updating the sale order’s partner.
- This ensures that the pricelist remains unchanged throughout the checkout
  process.

Affected Version-saas-17.4
opw-4455367

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

Forward-Port-Of: odoo/odoo#202122
Forward-Port-Of: odoo/odoo#199927

before this PR: - The QR code on the E-Invoice broke when multiple invoice lines reduced the available space. after this PR: - Adjusted the layout to ensure the QR code moves to a new page if there isn't enough space on the current page. task - 4658271 Forward-Port-Of: odoo/odoo#202503

before this PR:
- The QR code on the E-Invoice broke when multiple invoice lines reduced the available space.

after this PR:
- Adjusted the layout to ensure the QR code moves to a new page if there isn't enough space on the current page.

task - 4658271

Forward-Port-Of: odoo/odoo#202503

**Issue**: A traceback error is raised when deleting the quotation attachment before sending it via email. **Steps to reproduce:** - go to Sales. - open a quotation. - click "Send by Email." - delete the attachment. A traceback error occurs. opw-4486182 Forward-Port-Of: odoo/odoo#202564 Forward-Port-Of: odoo/odoo#194593

**Issue**:
A traceback error is raised when deleting the quotation attachment before sending it via email.

**Steps to reproduce:**
	- go to Sales.
	- open a quotation.
	- click "Send by Email."
	- delete the attachment.

A traceback error occurs.

opw-4486182

Forward-Port-Of: odoo/odoo#202564
Forward-Port-Of: odoo/odoo#194593

Also: - Add some missing gettext + proper list formattings - Fix some incorrect English since the modules haven't been translated yet so no translations will be lost. Note that the English of "Allow to export Working Entries to your Social Secretariat" was purposely left bad since it's used in other already translated modules + it's expected that only Belgians will be using the modules and/or the modules will be used only in French/Dutch Forward-Port-Of: odoo/enterprise#81873 Forward-Port-O

Also:

- Add some missing gettext + proper list formattings
- Fix some incorrect English since the modules haven't been translated yet so no translations will be lost. Note that the English of "Allow to export Working Entries to your Social Secretariat" was purposely left bad since it's used in other already translated modules + it's expected that only Belgians will be using the modules and/or the modules will be used only in French/Dutch

Forward-Port-Of: odoo/enterprise#81873
Forward-Port-Of: odoo/enterprise#81841

Since odoo/enterprise@a94227b, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to the same code, without having to ensure a 1 to 1 relationship

Since odoo/enterprise@a94227b, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to the same code, without having to ensure a 1 to 1 relationship between the accounts of the source and consolidating company.

This, however, was only implemented for standard engines. Custom engines were not modified, and none of them did the proper call to _fields_to_sql, to ensure the join condition of the query is adapted to run this grouping. This commit adds it, together with a test ensuring the custom engines are all evaluated on runbot with a non-stored custom groupby, so that errors are spotted directly and the developers just don't have to remember this "by heart".

task-4596355

Forward-Port-Of: odoo/enterprise#81627
Forward-Port-Of: odoo/enterprise#81495

We are switching away from Clearbit which is very unreliable. For that reason we had an autosync feature which would update IAP's data for a company based on the data provided in Odoo. Instead, we are now switching to Dun & Bradstreet which has much more reliable data. Some routes have been changed to target the new API on IAP. We continue to use Clearbit for the logos which are not provided by DnB (yet). This is a backport of https://github.com/odoo/odoo/pull/196373 where models, fi

We are switching away from Clearbit which is very
unreliable. For that reason we had an autosync
feature which would update IAP's data for a company based on the data provided in Odoo.

Instead, we are now switching to Dun & Bradstreet
which has much more reliable data. Some routes have been changed to target the new API on IAP.

We continue to use Clearbit for the logos which are not provided by DnB (yet).

This is a backport of https://github.com/odoo/odoo/pull/196373 where models, fields, and public methods have been kept to respect the stable policy.

task-4416928

Forward-Port-Of: odoo/enterprise#81859
Forward-Port-Of: odoo/enterprise#81767

Current behaviour: --- Mexican phone numbers are not managed correctly following the 2019 changes in Mexico. (Removing a 1 in phone numbers) Cause of the issue: --- The phonenumbers library removing support of mexican phone numbers starting with 1 in 8.13.38 The Whatsapp API still using the mexican phone numbers starting with 1 Fixes: --- See community commit Adding extra tests in test_whatsapp Similar to: https://github.com/odoo/enterprise/commit/a35a039e5fba569cd379b23d37ce512b

Current behaviour:
---
Mexican phone numbers are not managed correctly following the 2019 changes in Mexico.
(Removing a 1 in phone numbers)

Cause of the issue:
---
The phonenumbers library removing support of mexican phone numbers starting with 1 in 8.13.38
The Whatsapp API still using the mexican phone numbers starting with 1

Fixes:
---
See community commit
Adding extra tests in test_whatsapp
Similar to: https://github.com/odoo/enterprise/commit/a35a039e5fba569cd379b23d37ce512b5a23f7e2

opw-4473528

Forward-Port-Of: odoo/enterprise#81677
Forward-Port-Of: odoo/enterprise#79416

### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced

### Steps to reproduce:

- In the settings, enable multi-step routes.
- Set Warehouse to 2-step Manufacturing
- Create a BoM with an operation and one move raw: 1 x COMP
- Create confirm, plan and **start** an MO with that bom.
- Through Shop Floor, on your operation > Wheel > add components
- Set the quantity of COMP to 10 instead of 1.
#### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated

### Cause of the issue:

Adding a product already referenced as a raw material via the catalog will trigger a call of the `_update_order_line_info` which will update the demand of the move raw:
https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2895-L2898 https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2913-L2914 If you did not start the MO, this would run the procurement to update the demand and thus update the picking:
https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/stock_move.py#L434-L438 However, since the MO was started the state of the MO is 'in_progress' instead of 'confirmed'.

### Note:

The issue was not reproducible before 18.0. Since adding a component was done via a call that would create and confirm a new move (hence running the procurements):
https://github.com/odoo/enterprise/blob/b3febe5a1afd5c1c8fd598db95e8c58fa4131563/mrp_workorder/wizard/additional_product.py#L63-L68

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

opw-4638371

Forward-Port-Of: odoo/enterprise#81691
Forward-Port-Of: odoo/enterprise#81361

When no partner is set on the bank transaction, we do not show the draft items among candidates. Reason : avoid showing too many irrelevant candidates quickly making the feature unusable. But if the user filters the candidate and selects a partner, then show the draft items of this partner among the candidates. Even though the partner filter is a conscious one (input by the user) and not computed by the partner on the bank transaction. This is done by adding a 'posted' filter to the lis

When no partner is set on the bank transaction, we do not show the draft items among candidates.

Reason : avoid showing too many irrelevant candidates quickly making the feature unusable.

But if the user filters the candidate and selects a partner, then show the draft items of this partner among the candidates. Even though the partner filter is a conscious one (input by the user) and not computed by the partner on the bank transaction.

This is done by adding a 'posted' filter to the list view that is automatically added when no partner is set in the statement.

task-4554569

Forward-Port-Of: odoo/enterprise#80682

### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP - Process the MO from the barcode app. - Click on "Add Component" select COMP as a product and set 1 unit - Confirm the additional move line #### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the pr

### Steps to reproduce:

- Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance.
- Create and confirm an MO for 1 unit of FP
- Process the MO from the barcode app.
- Click on "Add Component" select COMP as a product and set 1 unit
- Confirm the additional move line
#### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category."

### Cause of the issue:

When processing an MO from the barcode app and adding a component the method `_getNewLineDefaultContext` will be called to set the default context of that new line before creation:
https://github.com/odoo/enterprise/blob/83268aa3a5a7afdc8c09b0ac9bbee2b673fd25e9/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L367-L372 However, in this flow, `this.record` is an `mrp.production` and its `product_uom_id` is the product_uom_id of FP. In particular, the `default_product_uom_id` key will be used to alter the vals_list used in the create of our stock move line and an error will be raised since the unit category of COMP2 is Weight and is not compatible with the default product uom set by the context.

opw-4527706

Forward-Port-Of: odoo/enterprise#81472
Forward-Port-Of: odoo/enterprise#79266

The authorized signatory image is resized and loses it's aspect ratio. To fix, the w-100 (100% width) class is removed. OPW-4586108 Forward-Port-Of: odoo/enterprise#81613

The authorized signatory image is resized and loses it's aspect ratio.

To fix, the w-100 (100% width) class is removed.

OPW-4586108

Forward-Port-Of: odoo/enterprise#81613

Same logic as: https://github.com/odoo/enterprise/pull/79947 rb-145524 rb-145525 Forward-Port-Of: odoo/enterprise#81763

Same logic as:
https://github.com/odoo/enterprise/pull/79947

rb-145524
rb-145525

Forward-Port-Of: odoo/enterprise#81763

This commit removes deprecated operations, associated with code that was deleted from the OPERATIONS_WHITELIST in commit (1). It made no longer sense to list those operations as they are no longer callable. (1) 2a27ee64c19d1a467fd99e15d375af16abfaaa70 Forward-Port-Of: odoo/enterprise#81739

This commit removes deprecated operations, associated with code that was deleted from the OPERATIONS_WHITELIST in commit (1). It made no longer sense to list those operations as they are no longer callable.

(1) 2a27ee64c19d1a467fd99e15d375af16abfaaa70

Forward-Port-Of: odoo/enterprise#81739