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

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

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

Description of the issue/feature this PR addresses: The goals of the PR are multiple: - The thread names in the discuss app are not muted when "mute all conversations" is enabled or when the specific thread is muted. - The threads with no new messages are invisible when the parent thread is muted Current behavior before PR: see above Desired behavior after PR is merged: The thread opacity is set to 50 whenever the thread is muted (by any of the two ways) task-4607160 --- I co

Description of the issue/feature this PR addresses:
The goals of the PR are multiple:
- The thread names in the discuss app are not muted when "mute all conversations" is enabled or when the specific thread is muted.
- The threads with no new messages are invisible when the parent thread is muted

Current behavior before PR:
see above

Desired behavior after PR is merged:
The thread opacity is set to 50 whenever the thread is muted (by any of the two ways)

task-4607160


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

Forward-Port-Of: odoo/odoo#200310

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

**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

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

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#202454
Forward-Port-Of: odoo/odoo#200650

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

**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#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#200623

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

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

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

### Steps to reproduce: - Create a storable product tracked by serial number available from the pos and with a set pos category. - Open a pos session and click on your product. > A dialog openns for you to register serial numbers. - Edit a first SN: SN001 and press enter > A new line can now be set to create a second one. - Edit a second SN: SN002 and press enter - Confirm the dialog #### > The quantity displayed on teh POS order line is 1 rather than 2. ### Cause of the issue: C

### Steps to reproduce:

- Create a storable product tracked by serial number available from the pos and with a set pos category.
- Open a pos session and click on your product.
> A dialog openns for you to register serial numbers.
- Edit a first SN: SN001 and press enter
> A new line can now be set to create a second one.
- Edit a second SN: SN002 and press enter
- Confirm the dialog
#### > The quantity displayed on teh POS order line is 1 rather than 2.

### Cause of the issue:

Clicking on the product card from the pos will trigger a call of the `AddProductToCurrentOrder` that will add a quantity of the product set via the options:
https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/pos_store.js#L1965-L1978 However, the `getAddProductOptions` call sets a quantity to add of 1 no matter if you added multiple or even removed multiple registered SN. https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L180 On the other hand, since at the moment of this call we do not have the info of the lines that were removed in the dialog it is not possible to always provide the correct (possibly negative) quantity to add to the line for the qty to be correctly handledby the posorder line. However, just as when you edit the line dirrectly this can be achieved by updating the quantity based on the relevant lots present on the line: https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L570-L572

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

Forward-Port-Of: odoo/odoo#202252
Forward-Port-Of: odoo/odoo#199127

In case of fully flexible working schedules, the leaves must not be computed from the working schedule (as there is none). The test for this bug is in the following related PR: https://github.com/odoo/enterprise/pull/80785 task-4623219 Forward-Port-Of: odoo/odoo#200379

In case of fully flexible working schedules, the leaves must not be computed from the working schedule (as there is none).

The test for this bug is in the following related PR: https://github.com/odoo/enterprise/pull/80785

task-4623219

Forward-Port-Of: odoo/odoo#200379

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

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

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

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

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

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

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

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

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

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

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

**=pos_urban_piper_swiggy Following this commit: ==== - Previously, static values like 'CGST' and 'SGST' were used. However, 'SGST' has been renamed to 'SGST/UTGST'. - To prevent similar issues in the future, tax group names are now fetched dynamically instead of using hardcoded values. - This ensures accurate tax computation and better maintainability. task-4626494 Forward-Port-Of: odoo/enterprise#80756

**=pos_urban_piper_swiggy

Following this commit:
====
- Previously, static values like 'CGST' and 'SGST' were used. However, 'SGST' has been renamed to 'SGST/UTGST'.
- To prevent similar issues in the future, tax group names are now fetched dynamically instead of using hardcoded values.
- This ensures accurate tax computation and better maintainability.

task-4626494

Forward-Port-Of: odoo/enterprise#80756

The bug has been introduced by this commit : https://github.com/odoo/enterprise/commit/4cba2fb58560a95d5ce93eb6e6c1483ef0428ba5 The bug appears when trying to generate batch of payslips with fully flexible working schedules. When the contract linked to the payslip has no working schedule, the check of the timezone is done on the employee linked to the payslip. The fix only consists on taking the employee of each slip instead of taking the employee on self, which was causing a 'singleton expe

The bug has been introduced by this commit : https://github.com/odoo/enterprise/commit/4cba2fb58560a95d5ce93eb6e6c1483ef0428ba5

The bug appears when trying to generate batch of payslips with fully flexible working schedules. When the contract linked to the payslip has no working schedule, the check of the timezone is done on the employee linked to the payslip.
The fix only consists on taking the employee of each slip instead of taking the employee on self, which was causing a 'singleton expected' error.

This commit also contains a test for the related fix in the following related PR:

task-4623219

Forward-Port-Of: odoo/enterprise#80785

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

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

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