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

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: - 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#202653

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

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

The "Lot / SN" column is redundant with the "Pick From" column. When Pick From is displayed, we can hide the "Lot/SN". However, if the user does not have the lot/serial number in a quant, they still need a way to select it, so we allow for a quant creation. In order to not re-introduce the bug fixed by this commit: 60d95aa8304c11698e49336391d98926861e640d , we overwrite the name_create to return False, aka no action is done. --- ## BEFORE https://github.com/user-attachments/assets/7

The "Lot / SN" column is redundant with the "Pick From" column. When Pick From is displayed, we can hide the "Lot/SN".

However, if the user does not have the lot/serial number in a quant, they still need a way to select it, so we allow for a quant creation.

In order to not re-introduce the bug fixed by this commit: 60d95aa8304c11698e49336391d98926861e640d , we overwrite the name_create to return False, aka no action is done.

---

## BEFORE
https://github.com/user-attachments/assets/7e6c5a6a-ed86-4564-bcb5-51c94a5a4ae4

- Selecting a SN is very fast
- We can easily use an unavailable SN
- The unavailable SN is taken from a quant without lot
- Lot is displayed twice (pick from & lot/sn)


## AFTER
https://github.com/user-attachments/assets/f5bd7cc6-d77e-410c-a1aa-8ad6ba6d0020

- Selecting a SN is a bit harder
- Selecting an unavailable SN is even more complicated
- The unavailable SN is taken from a quant with its lot


OPW-4485159

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

Forward-Port-Of: odoo/odoo#199630

If the target url had duplicate keys in its query params, the redirect url would only contain the key-value pair corresponding to the first occurrence of the key. This is incorrect, as a shop url typically contains multiple attribute values in its query params. The issue was caused by an accidental cast from MultiDict to Dict when handling the query params. opw-4466925 Forward-Port-Of: odoo/odoo#199570

If the target url had duplicate keys in its query params, the redirect url would only contain the key-value pair corresponding to the first occurrence of the key. This is incorrect, as a shop url typically contains multiple attribute values in its query params. The issue was caused by an accidental cast from MultiDict to Dict when handling the query params.

opw-4466925

Forward-Port-Of: odoo/odoo#199570

### Steps to reproduce: - In Accounting create a new Payment Term with an early discount set on "Always(upon invoice)" - Create a new Contact and add the payment term to this contact - Open POS and create an order - Select the new contact as the customer - Go to payment, select the option to create an invoice and validate - The receipt and the generated invoice have different amounts: the payment terms were applied on the invoice but not on the receipt ### Cause: POS does not consider

### Steps to reproduce:
- In Accounting create a new Payment Term with an early discount set on "Always(upon invoice)"
- Create a new Contact and add the payment term to this contact
- Open POS and create an order
- Select the new contact as the customer
- Go to payment, select the option to create an invoice and validate
- The receipt and the generated invoice have different amounts: the payment terms were applied on the invoice but not on the receipt

### Cause:
POS does not consider at any point the payment terms so the total to be paid does not include the payment terms. Payment terms were included in invoices from POS with this [commit](https://github.com/odoo/odoo/pull/100100/commits/c1cd62f0b207b3f3bbf5a03009bd8e34ee9b479f)

### Solution:
Remove the payment terms on invoices from POS.

opw-4458036

Forward-Port-Of: odoo/odoo#199385

Steps to reproduce: - insert a line chart into a spreadsheet with the horizontal axis being a time axis - ensures a domain is applied such that at least some past data is excluded - open the configuration side panel - check the "Cumulative data" checkbox => the chart doesn't take into account past data. When reloading it works. opw-4646477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202746

Steps to reproduce:

- insert a line chart into a spreadsheet with the horizontal axis being a time axis
- ensures a domain is applied such that at least some past data is excluded
- open the configuration side panel
- check the "Cumulative data" checkbox

=> the chart doesn't take into account past data. When reloading it works.

opw-4646477


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

Forward-Port-Of: odoo/odoo#202746

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

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

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

**Steps to reproduce:** - Install Accounting and l10n_ke_edi_tremol - Switch to a Kenyan company (e.g. KE Company) - Configure USD currency: * Rounding Factor: 0.000100 * Decimal Places: 4 * Rate: 0.007729205731 Unit per KES 129.379400000000 KES per Unit - Create a product with decimal in the price (e.g. 1234.56) - Create an invoice: * Customer: [a Kenyan customer] * Currency: USD * Product: [the created product] * Taxes: 16% - Confirm the invoice - Send the invoice t

**Steps to reproduce:**
- Install Accounting and l10n_ke_edi_tremol
- Switch to a Kenyan company (e.g. KE Company)
- Configure USD currency:
  * Rounding Factor: 0.000100
  * Decimal Places: 4
  * Rate: 0.007729205731 Unit per KES 129.379400000000 KES per Unit
- Create a product with decimal in the price (e.g. 1234.56)
- Create an invoice:
  * Customer: [a Kenyan customer]
  * Currency: USD
  * Product: [the created product]
  * Taxes: 16%
- Confirm the invoice
- Send the invoice to fiscal device (It will not be possible without some credentials. However, if a breakpoint is set at the last line ("return" line) of "_l10n_ke_cu_lines_messages" method, the total amount in KSh sent to the fiscal device can be checked.)

**Issue:**
The total amount in KSh sent to the fiscal device is different than the total amount in USD converted to KSh with the used currency rate.

**Cause:**
In the "_l10n_ke_cu_lines_messages" method (the method used to compute the amounts sent to the fiscal device), a rounding is done by forcing the number of decimal to 2 without taking into account the configuration of the currency when computing the price.

opw-4567098




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

Forward-Port-Of: odoo/odoo#202888
Forward-Port-Of: odoo/odoo#202706

# HOW TO REPRODUCE: - Create products FNS & CMP - Set available quantity of CMP to 2 - Create MO of 1 FNS and 2 CMP -> Confirm - Open MO in barcode - Set FNS quantity to 1 - Set CMP quantity to 1 (1/2 of the demand) -> Produce MO => The CMP move has 2 lines of 1 unit, so 2 unit have been consumed instead of the 1 put on the barcode. https://github.com/user-attachments/assets/237c81bc-f342-4293-bc76-008b5c7cf876 OPW-4517284 Forward-Port-Of: odoo/enterprise#81343

# HOW TO REPRODUCE:
- Create products FNS & CMP
- Set available quantity of CMP to 2
- Create MO of 1 FNS and 2 CMP -> Confirm
- Open MO in barcode
  - Set FNS quantity to 1
  - Set CMP quantity to 1 (1/2 of the demand) -> Produce MO => The CMP move has 2 lines of 1 unit, so 2 unit have been consumed instead of the 1 put on the barcode.

https://github.com/user-attachments/assets/237c81bc-f342-4293-bc76-008b5c7cf876


OPW-4517284

Forward-Port-Of: odoo/enterprise#81343

Steps to reproduce the bug: - create a storable product “P1” and “C1” - create a quality point for C1: - Operation type: Manufacturing - Control per: quantity - Control Frequency: all - Partial Test: 10% - Type: pass-fail - Create a manufacturing order: - Finished product: 2 units of P1 - Components: C1 -> 10 units - Confirm the MO - go to the quality check Problem: A quality check is created, but the quantity to test is based on the manufacturin

Steps to reproduce the bug:
- create a storable product “P1” and “C1”
- create a quality point for C1:
    - Operation type: Manufacturing
    - Control per: quantity
    - Control Frequency: all
     - Partial Test: 10%
     - Type: pass-fail

- Create a manufacturing order:
    - Finished product: 2 units of P1
    - Components: C1 -> 10 units

- Confirm the MO
- go to the quality check

Problem:
A quality check is created, but the quantity to test is based on the manufacturing order's produced quantity instead of the stock move line quantity linked to the quality check.

opw-4527413

Forward-Port-Of: odoo/enterprise#81773

If a list contains multi-line content, only the first line of the content is shown in the spreadsheet cells. This commit fixes this with an `AUTORESIZE_ROWS`, which now works for multi-line formulas. Task: [4609545](https://www.odoo.com/web#id=4609545&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#81325

If a list contains multi-line content, only the first line of the content is shown in the spreadsheet cells. This commit fixes this with an `AUTORESIZE_ROWS`, which now works for multi-line formulas.

Task: [4609545](https://www.odoo.com/web#id=4609545&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#81325

This https://github.com/odoo/enterprise/commit/f6af0b3285b4835256fa1ab7b729dc3b334abe76 introduced un unwanted side-effect. When trying to modify/remove an analytic distribution on a line, it would make the widget go blank. The fix for the stable versions is to make sure the statement line is passed into the context before reloading the liquidity line. A permanent fix will be done in master by turning _action_reload_liquidity_line() into a context manager. Forward-Port-Of: odoo/enterprise

This https://github.com/odoo/enterprise/commit/f6af0b3285b4835256fa1ab7b729dc3b334abe76 introduced un unwanted side-effect. When trying to modify/remove an analytic distribution on a line, it would make the widget go blank.

The fix for the stable versions is to make sure the statement line is passed into the context before reloading the liquidity line.

A permanent fix will be done in master by turning _action_reload_liquidity_line() into a context manager.

Forward-Port-Of: odoo/enterprise#81846

Currently on the Frontdesk welcome screen the words "Welcome" and "to" (welcoming visitors to your company) were exported separately, because they weren't in the same parent node. This caused translation issues, since the word "to" is translated differently depending on the context and was not scoped to the module (Javascript translation). This commit puts "Welcome to" together in the same parent node, so the phrase is exported as a whole. [task-4421055](https://www.odoo.com/odoo/project.t

Currently on the Frontdesk welcome screen the words "Welcome" and "to" (welcoming visitors to your company) were exported separately, because they weren't in the same parent node. This caused translation issues, since the word "to" is translated differently depending on the context and was not scoped to the module (Javascript translation).

This commit puts "Welcome to" together in the same parent node, so the phrase is exported as a whole.

[task-4421055](https://www.odoo.com/odoo/project.task/4421055)

Forward-Port-Of: odoo/enterprise#78781

### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operation Types - Manufacturing > uncheck: Create New Lots/Serial Numbers for Component - Create a product tracked by SN and put one SN in stock. - Create and confirm an MO for an other product using your tracked product as component. - Go to the barcode a

### Issue:

Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots.

### Steps to reproduce:

- Inventory > Configuration > Warehouse Management > Operation Types
- Manufacturing > uncheck: Create New Lots/Serial Numbers for Component
- Create a product tracked by SN and put one SN in stock.
- Create and confirm an MO for an other product using your tracked product as component.
- Go to the barcode app > Manufacturing > your MO
- Click on the component line and scan a string that do not correspond to an existing SN of your tracked product.
> The Scanned string is added as a "lot_name" on a new line. In
   particular, at validation a new move line without lot and with a
   set lot_name will be created. This line without lot will be used in
   all the `pre_button_mark_done` checks like: `_check_sn_uniqueness`
   which btw will fail if you scanned 2 non-existing lots. And, if you
   manage to pass all check for instance by scanning a non-existing lot
   and the initially reserved one, the validation of the new move line
   will create the lot.

Cause of the issue:

Scanning the non existing lot will correctly fail to find a match via the barcode parser:
https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode/static/src/models/barcode_model.js#L963 As such and since a line is selected, you will end up setting the barcode as a lotName:
https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode/static/src/models/barcode_model.js#L1018-L1034 This happens notably because you `this.canCreateNewLot` is always set to `True` on productions but should not:
https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L126-L128

opw-4618963

Forward-Port-Of: odoo/enterprise#81272