Currently, an error occurs when the user attempts to import a `Datetime` object into a field that is not of type Datetime (e.g., `External ID`). Steps to replicate: - Install Accounting and Import Invoices through the file attached. - On any date field select `External ID` and click Test. Error: `TypeError: argument of type 'datetime.date' is not iterable` This error occurs due to a recent change introduced in version saas-18.1 [PR](https://github.com/odoo/odoo/pull/206876), where `D

Currently, an error occurs when the user attempts to import a `Datetime` object into a field that is not of type Datetime (e.g., `External ID`).

Steps to replicate:
- Install Accounting and Import Invoices through the file attached.
- On any date field select `External ID` and click Test.

Error:
`TypeError: argument of type 'datetime.date' is not iterable`

This error occurs due to a recent change introduced in version saas-18.1 [PR](https://github.com/odoo/odoo/pull/206876), where `Datetime` objects are now passed directly [1] instead of being converted to string(18.0 [2]). This change has led to multiple issues during data processing.

This commit resolves the issue by preemptively raising column-level warnings for fields with incompatible data types (e.g.,importing a Date into an External ID column), preventing errors before they occur.

[1]-https://github.com/odoo/odoo/blob/d000cf0be02253af1ac1beb6d54b46dcdeac3648/addons/base_import/models/base_import.py#L480-L484
[2]-https://github.com/odoo/odoo/blob/752ba2927e0b61cd6315e5c780a5292a6e99fe17/addons/base_import/models/base_import.py#L479-L483
[Journal Entry (account.move) (25) (1).xlsx](https://github.com/user-attachments/files/20339804/Journal.Entry.account.move.25.1.xlsx)
sentry-6604789067, 6591445640, 6604916781, 6596056524, 6589051928
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#210729

_Description of the issue/feature this PR addresses:_ When setting up a new activity template on a new activity plan, HR specific values for 'Assignment' such as Coach or Manager are not available. _Current behavior before PR:_ As an HR manager, go to menu HR -> Configuration -> Activity Plan. Click 'New'. Under Activities To Create, click 'Add a line'. Under 'Assignment', the only options available are Ask at launch and Default user. <img src="https://github.com/user-attachments/ass

_Description of the issue/feature this PR addresses:_

When setting up a new activity template on a new activity plan, HR specific values for 'Assignment' such as Coach or Manager are not available.

_Current behavior before PR:_

As an HR manager, go to menu HR -> Configuration -> Activity Plan. Click 'New'. Under Activities To Create, click 'Add a line'. Under 'Assignment', the only options available are Ask at launch and Default user.

<img src="https://github.com/user-attachments/assets/97be6790-b450-42c6-910a-07483c30e175" width=50% height=50%>

Cancel the 'Create Activities' popup. Give the plan a name and save it. Again, under Activities To Create, click 'Add a line'. Only now are HR specific options (Coach, Manager etc) available under 'Assignment'.

_Desired behavior after PR is merged:_

HR specific values for 'Assignment' are immediately availalbe when setting up a new plan for the Employee model.

![image](https://github.com/user-attachments/assets/391da1c1-c1ed-495a-a25f-48941554791a)

_Technical solution:_

Pass the plan's model as the default model for new templates so that the related field is populated with a value that unlocks the HR specific values before first saving the plan.

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

Forward-Port-Of: odoo/odoo#213411

**Description of the issue/feature this PR addresses:** There's no hook to manipulate order values before write. **Current behavior before PR:** You cannot add custom logic easily w/o writing again on the order **Desired behavior after PR is merged:** Ease custom logic implementation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213167

**Description of the issue/feature this PR addresses:**

There's no hook to manipulate order values before write.

**Current behavior before PR:** 

You cannot add custom logic easily w/o writing again on the order

**Desired behavior after PR is merged:**

Ease custom logic implementation.




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

Forward-Port-Of: odoo/odoo#213167

Ensure that automatically generated discount lines inherit the analytic distribution from the original invoice lines. This allows consistent reporting and accurate profitability analysis in analytic accounting. 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#213229 Forward-Port-Of: odoo/odoo

Ensure that automatically generated discount lines inherit the analytic distribution from the original invoice lines.
 This allows consistent reporting and accurate
profitability analysis in analytic accounting.

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#213229
Forward-Port-Of: odoo/odoo#208279

--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209922

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

Forward-Port-Of: odoo/odoo#209922

Steps to reproduce: - Go to any Report (Ex: Sale Analysis) - Switch to the pivot view - Add on y-column any **int** field - Download as csv Tracebrack is thrown, because the controller tries to concat int to str in the csv generated file. opw-4762807 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-

Steps to reproduce:
- Go to any Report (Ex: Sale Analysis)
- Switch to the pivot view
- Add on y-column any **int** field
- Download as csv

Tracebrack is thrown, because the controller tries to concat int to str in the csv generated file.

opw-4762807

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#212007
Forward-Port-Of: odoo/odoo#208403

**Issue** When the tax group name is too long, it pushes the total amount off the page in the invoice PDF, making the amount unreadable. **Steps to Reproduce** 1. Install the Accounting module. 2. Go to Taxes. 3. Select a tax and open Advanced Options. 4. Set a very long name for the tax group. 5. Go to Accounting > Customers > Invoices. 6. Create and confirm an invoice using the tax with the long group name. 7. Print the invoice PDF and observe the layout issue. **Root Cause** Th

**Issue**
When the tax group name is too long, it pushes the total amount off the page in the invoice PDF, making the amount unreadable.

**Steps to Reproduce**
1. Install the Accounting module.
2. Go to Taxes.
3. Select a tax and open Advanced Options.
4. Set a very long name for the tax group.
5. Go to Accounting > Customers > Invoices.
6. Create and confirm an invoice using the tax with the long group name.
7. Print the invoice PDF and observe the layout issue.

**Root Cause**
The text-nowrap CSS class prevents the tax group name from wrapping, causing it to expand the table cell width and push the amount outside the page boundary.

**Fix**
Remove the text-nowrap class and apply a maximum width to the <td> element, allowing the tax group name to wrap or truncate properly without overlapping or pushing the total amount off the page.

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

Forward-Port-Of: odoo/odoo#211950

This commit is a followup of [1] where we compute the minimum required width for date and datetime fields in list views. However, it didn't take into account decorations that could be applied to list views, in particular `decoration-bf`, which may, for certain fonts, increase the width of date values. We tested all languages, on different systems (thus different standard fonts), and an increase of 5% of the computed width is enough on those systems to display date and datetimes without an ellips

This commit is a followup of [1] where we compute the minimum required width for date and datetime fields in list views. However, it didn't take into account decorations that could be applied to list views, in particular `decoration-bf`, which may, for certain fonts, increase the width of date values. We tested all languages, on different systems (thus different standard fonts), and an increase of 5% of the computed width is enough on those systems to display date and datetimes without an ellipsis, even in bold.

[1] odoo/odoo#210584

No task, issue reported on our prod

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

Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on order confirmation; 2. give it a sales description; 3. add it to an order and confirm. Issue ----- The task is named using the sales description. Cause ----- Commits 47d223759f07 & c3877b2acd74 attempted to restore previous task/display name behavior by using the second line of the SOL description as the task/display name. This behavior only happened in previous versions when the line des

Versions
--------
- 18.0+

Steps
-----
1. Have a service product that creates a task on order confirmation;
2. give it a sales description;
3. add it to an order and confirm.

Issue
-----
The task is named using the sales description.

Cause
-----
Commits 47d223759f07 & c3877b2acd74 attempted to restore previous task/display name behavior by using the second line of the SOL description as the task/display name.

This behavior only happened in previous versions when the line description was manually modified.

Solution
--------
Only use the new behavior if the line name isn't the same as the default.

opw-4634149

Forward-Port-Of: odoo/odoo#213225

**Steps to reproduce:** 1. Accounting > Configuration Menu > Journals 2. Archive a Journals with outgoing payment method 3. Go to Expenses > Configuration Menu 4. Settings > Payment methods Under Accounting 5. Notice that the payment methods from archived journals are still visible **Issue:** - In this commit https://github.com/odoo/odoo/commit/c4f21085f8f77d8786eb1bc9494ae0fc1327b8b8 the overridden action_archived method was removed, which previously prevented journals with link

**Steps to reproduce:**
1. Accounting > Configuration Menu > Journals
2. Archive a Journals with outgoing payment method
3. Go to Expenses > Configuration Menu
4. Settings > Payment methods Under Accounting
5. Notice that the payment methods from archived journals are still visible

**Issue:**
- In this commit https://github.com/odoo/odoo/commit/c4f21085f8f77d8786eb1bc9494ae0fc1327b8b8
  the overridden action_archived method was removed, which previously prevented journals with 
  linked payment methods from being archived.

**Solution:**
- Update the company_expense_allowed_payment_method_line_ids field's domain field to include only payment methods from  active journals

opw-4745525

Forward-Port-Of: odoo/odoo#210314

In test_generate_all_export_files, PDF and XLSX reports were not generated due to them timing-out the runbot, which was happening randomly. This has been fixed here by only testing the generation of the data then given to wkhtmltopdf, since wkhtmltopdf is quite slow and can randomly create errors. This is taking about 4 minutes with this fix when all reporting modules are enabled in v17.0 but taking around 20 minutes when creating PDFs. task-3603619 Forward-Port-Of: odoo/enterprise#872

In test_generate_all_export_files, PDF and XLSX reports were not generated due to them timing-out the runbot, which was happening randomly.

This has been fixed here by only testing the generation of the data then given to wkhtmltopdf, since wkhtmltopdf is quite slow and can randomly create errors.

This is taking about 4 minutes with this fix when all reporting modules are enabled in v17.0 but taking around 20 minutes when creating PDFs.

task-3603619

Forward-Port-Of: odoo/enterprise#87232
Forward-Port-Of: odoo/enterprise#86307

## Pull Request HOOT (PRHOOT) 32 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/210041 --- I confirm I have signed

## Pull Request HOOT (PRHOOT) 32

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

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

Forward-Port-Of: odoo/enterprise#87149
Forward-Port-Of: odoo/enterprise#85562

When executing follow-up actions, a KeyError could occur if the 'journals' key was missing from the options dictionary Steps to reproduce: Go to Accounting > Reports, open the Follow-up Report, and click Options. Untick journals so that the 'journals' list is effectively removed. Go to Customers, select any customer, Click on Customer Statement. Try to change Report (up right) to Follow_Up Report OPW-4798813 Forward-Port-Of: odoo/enterprise#87079

When executing follow-up actions, a KeyError could occur if the 'journals' key was missing from the options dictionary

Steps to reproduce:
Go to Accounting > Reports, open the Follow-up Report, and click Options. Untick journals so that the 'journals' list is effectively removed. Go to Customers, select any customer, Click on  Customer Statement. Try to change Report (up right) to Follow_Up Report

OPW-4798813

Forward-Port-Of: odoo/enterprise#87079

**Issue** In the Mexican localization, the CFDI usage (`l10n_mx_edi_usage`) field is not visible on POS orders in the backend. This prevents users from selecting or modifying the usage when manually generating an invoice from the POS order. **Steps to Reproduce** 1. Install the Point of Sale app and the Mexican localization (l10n_mx) 2. Complete a POS order without generating an invoice 3. In the backend, go to Point of Sale > Orders > Orders 4. Open the newly created order 5. Notice th

**Issue**
In the Mexican localization, the CFDI usage (`l10n_mx_edi_usage`) field is not visible on POS orders in the backend. This prevents users from selecting or modifying the usage when manually generating an invoice from the POS order.

**Steps to Reproduce**
1. Install the Point of Sale app and the Mexican localization (l10n_mx)
2. Complete a POS order without generating an invoice
3. In the backend, go to Point of Sale > Orders > Orders
4. Open the newly created order
5. Notice that the CFDI Usage field is missing

**Root Cause**
The usage field is given a default value at the model level: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/l10n_mx_edi_pos/models/pos_order.py#L65-L70 However, this value gets lost during the order processing flow. When an invoice is requested directly from the POS UI, the usage is explicitly set in the `sync_from_ui` method: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/l10n_mx_edi_pos/models/pos_order.py#L110-L112 But if no invoice is requested at the time of the order, the usage is not preserved or restored in the backend. 

**Fix**
Explicitly set the CFDI usage to its default value when an invoice is not requested during the POS flow. This ensures the usage field is retained and displayed properly in the backend, allowing users to create invoices manually.

opw-4776487

Forward-Port-Of: odoo/enterprise#85954

When a signed document is moved to trash in the documents app, when the cron tries to delete the said document it should raise a foreign key violation error in the terminal not in UI. **Steps to reproduce:** * Install document and sign * Document App> all> click `Employment contract.pdf`. * Select sign>drag and drop Signature>Sign now * Sign the document>validate and send completed document * Documents>certificate of completion or the signed document>actions>trash * The error will be pr

When a signed document is moved to trash in the documents app, when the cron tries to delete the said document it should raise a foreign key violation error in the terminal not in UI.

**Steps to reproduce:**
* Install document and sign
* Document App> all> click `Employment contract.pdf`.
* Select sign>drag and drop Signature>Sign now
* Sign the document>validate and send completed document
* Documents>certificate of completion or the signed document>actions>trash
* The error will be produced when cron deletes the document.
* You can delete the document from trash to see what error will be displayed by cron.
  
 `ERROR: update or delete on table "ir_attachment" violates foreign key constraint "sign_request_completed_document_rel_ir_attachment_id_fkey" on table "sign_request_completed_document_rel"`
 
**Solution:**
* Modifying the domain for `_gc_clear_bin` via a new function called overridden `_gc_documents_domain` in `documents_sign` this will allow for cron to skip over signed required document during unlink process.
* This will still throw an `Validation Error` when the user tries to delete it from the GUI letting them know it cannot be deleted.

Sentry-6225030131

Forward-Port-Of: odoo/enterprise#83765

Previously, the `company_id` field on `budget.analytic` was mandatory. - Removed the `required=True` constraint on the `company_id` field in the `budget.analytic` model. - Updated the record rules `budget_comp_rule` and `budget_lines_comp_rule` to allow access to records where `company_id` is either in the user's companies or unset (`False`). task-4677599 Forward-Port-Of: odoo/enterprise#82955

Previously, the `company_id` field on `budget.analytic` was mandatory.

- Removed the `required=True` constraint on the `company_id` field in the `budget.analytic` model.
- Updated the record rules `budget_comp_rule` and `budget_lines_comp_rule` to allow access to records where `company_id` is either in the user's companies or unset (`False`).

task-4677599

Forward-Port-Of: odoo/enterprise#82955

Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete. Steps to reproduce: ------------------- * Install fedex * In operation types, select Delivery Orders then hardware * In print on validation, enable Carrier Labels and Export Documents * In the shipping methods, select fedex international * Change Label format to ZPL11 * Connect the database to an iot box * Set up the shipping labels to be send on z

Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels and Export Documents
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Set up commercial invoice (/invoice) to be sent to another printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Validate the delivery
> Observation: Nothing prints, jobs are sent to CUPS bu not printing

Why the fix:
------------
https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_fedex_rest/models/delivery_fedex.py#L192-L196

As show, when sending the shipping, if the invoice is generated, it gets added to the attachements. The function `message_post` will post all attachments in the same chatter message.

In `delivery_iot` the `message_post` function is overridden to allow sending the printing jobs to the iot.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L33-L46

Here, `attachments_names` will both contain `Label` and `ShippingDoc`. Since we enter the first if condition, the report is related to the shipping labels. Then we send the data related to all attachments to the device linked to the shipping labels, aka the zebra printer. Since the other attachment is of type PDF, the zebraprinter does not know what to do with it and ends up printing nothing.

Since we can have multiple different attachment, the if/elseif condition does not make sense. By breaking it in two if, we can send both reports separately, while still keeping all attachments in the same chatter message.

opw-4546715

Forward-Port-Of: odoo/enterprise#83481
Forward-Port-Of: odoo/enterprise#82094

Currently, there is an button related to the MX localization that can be accessed outside the localization if `l10n_mx` is installed. Steps to reproduce: ------------------- * Install `l10n_mx` * With company other than MX, go to the pos orders * Select multiple pos orders, select the button **Actions** > Observation: The action `Create Global Invoice` is visible * Select the action `Create GLobal Invoice` > Validation error, Selected orders are not eligible for CFDI Why the fix: -

Currently, there is an button related to the MX localization that can be accessed outside the localization if `l10n_mx` is installed.

Steps to reproduce:
-------------------
* Install `l10n_mx`
* With company other than MX, go to the pos orders
* Select multiple pos orders, select the button **Actions**
> Observation: The action `Create Global Invoice` is visible
* Select the action `Create GLobal Invoice`
> Validation error, Selected orders are not eligible for CFDI

Why the fix:
------------
This is an `ir.actions.server` which is introduced in the `l10n_mx` localization.

It does not look possible to add `invisible` on the xml for the action. https://github.com/odoo/odoo/blob/2540155b5e00a6547fcceee4af4b83f385dcd4ad/odoo/addons/base/models/ir_actions.py#L179-L215

What we can do instead is to throw a more explicit error when trying to use the action outside the MX loca.

opw-4805257

Forward-Port-Of: odoo/enterprise#86612

Duplicate field was introduced in https://github.com/odoo/enterprise/commit/0703cf2834aeca2db498575ac6e0a35e37e7d048 Duplicate of : https://github.com/odoo/enterprise/pull/85692/files#diff-a75131997102fa2a43d54afca5d43c93165f9eb91a0afc1a707d82ad80e35cf9L48 Forward-Port-Of: odoo/enterprise#85692

Duplicate field was introduced in https://github.com/odoo/enterprise/commit/0703cf2834aeca2db498575ac6e0a35e37e7d048

Duplicate of : https://github.com/odoo/enterprise/pull/85692/files#diff-a75131997102fa2a43d54afca5d43c93165f9eb91a0afc1a707d82ad80e35cf9L48

Forward-Port-Of: odoo/enterprise#85692

Steps: ----------- - Install the pos_l10n_se module. - Open a POS session with the Swedish Fiscal Data Module configured in the IoT Box settings. - Add a product to the order. Issue: ------------- - An error popup states: "Product has an invalid tax amount. Only 25%, 12%, 6% and 0% are allowed." even when the product is correctly configured with one of these tax rates. Cause: ---------- - The validation logic incorrectly applies conditions for displaying the error popup, mistakenly

Steps:
-----------
- Install the pos_l10n_se module.
- Open a POS session with the Swedish Fiscal Data Module configured in the IoT Box settings.
- Add a product to the order.

Issue:
-------------
- An error popup states: "Product has an invalid tax amount. Only 25%, 12%, 6% and 0% are allowed." even when the product is correctly configured with one of these tax rates.

Cause:
----------
- The validation logic incorrectly applies conditions for displaying the error popup, mistakenly rejecting valid tax rates when the PoS receipt label is set.

FIX:
-----------
- Updated the tax validation conditions to handle products correctly, allowing tax rates, and preventing false error messages.

task-4687156

Forward-Port-Of: odoo/enterprise#87275
Forward-Port-Of: odoo/enterprise#83221