A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url. As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered. Task-3502174 Forward-Port-Of: odoo/odoo#184290 Forward-Port-Of: odoo/odoo#176074

A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url.

As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered.

Task-3502174

Forward-Port-Of: odoo/odoo#184290
Forward-Port-Of: odoo/odoo#176074

### Steps to reproduce the issue: 1. Activate Italian Localization 2. Create a contact in any country but Italy 3. Assign VAT number starting with 'IT' (Tax ID or Identification Number) 4. Save and receive error: > Invalid Codice Fiscale '[VAT number]': should be like 'MRTMTT91D08F205J' for physical person and '12345670546' for businesses. ### Explanation: When `country_id` or `vat` is changing, `_l10n_it_onchange_vat` will try to create a `l10n_it_codice_fiscale` if `res.part

### Steps to reproduce the issue:

1. Activate Italian Localization
2. Create a contact in any country but Italy
3. Assign VAT number starting with 'IT' (Tax ID or Identification Number)
4. Save and receive error:

>     Invalid Codice Fiscale '[VAT number]': should be like 'MRTMTT91D08F205J' for physical person and '12345670546' for businesses.

### Explanation:

When `country_id` or `vat` is changing, `_l10n_it_onchange_vat` will try to create a `l10n_it_codice_fiscale` if `res.partner` respects some conditions. Those conditions are flawed because if `country_id` is not Italy but `vat` starts with "IT", it will enter the condition.

(Kind of a hack: if `country_id` is set after a `l10n_it_codice_fiscale` has been added to `res.partner`, the first condition will not be met but the second will, and `l10n_codice_fiscale` will turn back to False.)

### Fix reasoning:

We will only check conditions related to `vat` and `country_id` and always perform changes to avoid inconsistencies where `vat` is no longer correct but `l10n_it_codice_fiscale` did not change and is still valid.

opw-4261959

Forward-Port-Of: odoo/odoo#185604
Forward-Port-Of: odoo/odoo#184406

Before this commit, when loading the data for the point of sale, all the uom categories were not being loaded due to a wrong domain declaration. The domain was comparing uom categories ids with uom ids, which is wrong. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185807

Before this commit, when loading the data for the point of sale, all the uom categories were not being loaded due to a wrong domain declaration. The domain was comparing uom categories ids with uom ids, which is wrong.

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

Forward-Port-Of: odoo/odoo#185807

HTML user menu items were escaped on the mobile client Fixes #145693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152809

HTML user menu items were escaped on the mobile client

Fixes #145693

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

Forward-Port-Of: odoo/odoo#152809

Specification: This PR aims to resolve the issue occured while discarding the upload process the `this.fileInput.el` becomes undefined as image is discarded which resulted in traceback. task-4255826 Forward-Port-Of: odoo/odoo#183547

Specification:

This PR aims to resolve the issue occured while discarding the upload process the `this.fileInput.el` becomes undefined as image is discarded which resulted in traceback.

task-4255826

Forward-Port-Of: odoo/odoo#183547

Steps to reproduce: - Create and confirm an invoice at 2024/10/01 with a line containeing a tax_id - In journal items, try to "cut-off" Issue: You won't be able to do so because of the tax lock date Cause: We need the correct accounting date to find back the reference move but before the fix, a side effect was to check for tax lock date which does not make sense in this flow. We create move line without tax_ids/tag_grid and so it does not impact the tax report: https://github.com/odoo/

Steps to reproduce:
- Create and confirm an invoice at 2024/10/01 with a line containeing a tax_id
- In journal items, try to "cut-off"

Issue:
You won't be able to do so because of the tax lock date

Cause:
We need the correct accounting date to find back the reference move but before the fix, a side effect was to check for tax lock date which does not make sense in this flow. We create move line without tax_ids/tag_grid and so it does not impact the tax report: https://github.com/odoo/odoo/blob/16.0/addons/account/wizard/account_automatic_entry_wizard.py#L242-L271

Solution:
we set the `has_tax` to False to byapss the check. The user, if he wishes, could excatly the same flow by creating an entry "a la mano" <->  We don't need to block this flow

opw-4191527

Forward-Port-Of: odoo/odoo#185078

Before this commit, the selected value in dropdowns within the text editor toolbar was barely visible. This commit adds styles to highlight the selected option, making it clearly visible and aligned with the other dropdowns for better user experience and consistency. Before:  After:  task-4150489 Forward

Before this commit, the selected value in dropdowns within the text editor toolbar was barely visible.

This commit adds styles to highlight the selected option, making it clearly visible and aligned with the other dropdowns for better user experience and consistency.

Before:
![image](https://github.com/user-attachments/assets/e4ee1705-ab80-488e-a93e-83810781b43a)

After:
![image](https://github.com/user-attachments/assets/d90e594f-a060-45b1-ab6b-31b435fc3c84)


task-4150489

Forward-Port-Of: odoo/odoo#181060

When viewing more than 1 viewable file in the FileViewer, the navigation buttons `<` and `>` are barely visible. This commit fixes it by putting white icon on dark rounded background for the buttons. Task-4056907 <img width="2559" alt="Screenshot 2024-10-30 at 17 34 03" src="https://github.com/user-attachments/assets/b26cc55c-d2e0-47f4-8c60-99fd55a46bf2"> Backport of https://github.com/odoo/odoo/pull/185909 Forward-Port-Of: odoo/odoo#185944 Forward-Port-Of: odoo/odoo#185910

When viewing more than 1 viewable file in the FileViewer, the navigation buttons `<` and `>` are barely visible.

This commit fixes it by putting white icon on dark rounded background for the buttons.

Task-4056907

<img width="2559" alt="Screenshot 2024-10-30 at 17 34 03" src="https://github.com/user-attachments/assets/b26cc55c-d2e0-47f4-8c60-99fd55a46bf2">

Backport of https://github.com/odoo/odoo/pull/185909

Forward-Port-Of: odoo/odoo#185944
Forward-Port-Of: odoo/odoo#185910

Steps to reproduce: - Fleet app > Any vehicle > Drivers History > Attachments - In mobile view > Primary button 'Upload' is not accessible - Primary button 'New' does not do anything This happens because the controller cannot find a form view for ir.attachment in fleet, which is the default view type for record creation (barring quickcreate stuff). Also d-none class hides the display of the 'Upload' button but the dropdown menu arrow is still there which is rather confusing. Seeing how

Steps to reproduce:
- Fleet app > Any vehicle > Drivers History > Attachments
- In mobile view > Primary button 'Upload' is not accessible
- Primary button 'New' does not do anything

This happens because the controller cannot find a form view for ir.attachment in fleet, which is the default view type for record creation (barring quickcreate stuff). Also d-none class hides the display of the 'Upload' button but the dropdown menu arrow is still there which is rather confusing.

Seeing how both buttons serve the same purpose, there is no need to keep 'New' which has no corresponding view.

opw-4229756

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

Forward-Port-Of: odoo/odoo#183904

We revert Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb as it allows to perform button actions on records with invalid datas. Notably because of unset required fields. ### Steps to reproduce: - In the settings enable sbcontracting - Create 2 storable products tracked by SN: Final Product (FP) and COMP - Create a subcontracting BOM for FP with COMP as component - On COMP set the route Resupply Subcontractor on Order - Register 3 SN of COMP in stock: SN01, SN02, SN03 - Create and conf

We revert Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb as it allows to perform button actions on records with invalid datas. Notably because of unset required fields.

### Steps to reproduce:

- In the settings enable sbcontracting
- Create 2 storable products tracked by SN: Final Product (FP) and COMP
- Create a subcontracting BOM for FP with COMP as component
- On COMP set the route Resupply Subcontractor on Order
- Register 3 SN of COMP in stock: SN01, SN02, SN03
- Create and confirm a PO for your subcontractor for 3 units of FP
- Validate the Resupply picking
- Go to the reciept and click "Record components"
- Record your first Final product SN: FP01 (required)
- Continue
- Dont register any SN on the second and third recording
#### > Since you will not be able to edit this required field later on, the registration of such a SN should be required on FP.
#### > This leads to a softlock as the field is readonly afterwards.

### Cause of the Issue:

Since Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb, the `_checkValidity` of the `_save` call do not happen if we are not at record creation or if no change has been applied on the record. However, in our case, we are not at creation of the record and we did not perfom any change on the record form so that  the `_save` call will return `true` rather than the `false` he would return if he performed a `_checkValidity` of the record. This is a drastic difference since the returned value of this `_save` is used by the `formController` when you click a button in order to determine if he should proceed with the action or cancel the call:
https://github.com/odoo/odoo/blob/9b5eed7e215b2601c25b9d81c42dfa1bc1d06fee/addons/web/static/src/views/form/form_controller.js#L497-L510
https://github.com/odoo/odoo/blob/9b5eed7e215b2601c25b9d81c42dfa1bc1d06fee/addons/web/static/src/views/view_button/view_button_hook.js#L49-L60
In particular, in our case, the action will be called even thought the "required onchange" (and associated "websave") was never called. What I mean by "required onchange" is that the "lot_producing_id" is a required field of our form:
https://github.com/odoo/odoo/blob/4d5d270e72fdec49ffc31269642683b68984adca/addons/mrp_subcontracting/views/mrp_production_views.xml#L24-L27
Hence it needs to be set and provoke an onchange that will it self provoke a `web_save` of the new record value in the `_save` before it proceeds with the button action.

### Additional note on Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb:

This commit was initially added to avoid displaying Invalid Field notifications when you open a record with invalid data as a `_save` is also called in the `openRecord` of the `ListController` for instance. To me even in that case, it is usefull even if unnecessary to know that some record data's are currently invalid.

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

Forward-Port-Of: odoo/odoo#185134

* Before this commit, if you have .. image in manifest description like .. image:: image.png (image.png stay in static/description) , it will only work on odoo app store but in module info it isn't * After this commit, make it work in module info of Apps (base module) by replace 'src' (image.png) with static/description resource (/module_name/static/description/image.png) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged

* Before this commit, if you have .. image in manifest description like .. image:: image.png (image.png stay in static/description) , it will only work on odoo app store but in module info it isn't
* After this commit, make it work in module info of Apps (base module) by replace 'src' (image.png) with static/description resource (/module_name/static/description/image.png)

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#184436
Forward-Port-Of: odoo/odoo#182875

### Steps to reproduce the issue: 1. Create a Sale Order with a recurring product and a non-recurring product and Confirm 2. Create a Down Payment Invoice and Confirm It 3. Try creating a new Invoice 4. The Already invoiced and Amount to invoice values are incorrect ### Explanation: When calculating `amount_to_invoice` in `sale.order` with `is_subscription=True`, the calculation of the non-recurring lines is calculated using their `price_total`, `qty_to_invoice` and `product_uom_qty`

### Steps to reproduce the issue:

1. Create a Sale Order with a recurring product and a non-recurring product and Confirm
2. Create a Down Payment Invoice and Confirm It
3. Try creating a new Invoice
4. The Already invoiced and Amount to invoice values are incorrect

### Explanation:

When calculating `amount_to_invoice` in `sale.order` with `is_subscription=True`, the calculation of the non-recurring lines is calculated using their `price_total`, `qty_to_invoice` and `product_uom_qty`. Down Payment lines do not have `price_total`.

### Fix reasoning:

In `odoo/addons/sale`, the calculation of `amount_to_invoice` uses `account.move._get_sale_order_invoiced_amount`.
https://github.com/odoo/odoo/blob/6a5a94b1cc5556371ea94a17624c534086a2a6e1/addons/sale/models/sale_order.py#L643-L647
https://github.com/odoo/odoo/blob/b5d02cc72543b36c7e5e620a3a579f15c88baed6/addons/sale/models/account_move.py#L157-L166
Modifying this code in order to only calculate using non-recurring `order_line` and adapting already existing test to include down payment possibility.

opw-4052417

Forward-Port-Of: odoo/enterprise#72562

This commit adds a new error modal when you clicking on deleted tweets and posts. It was decided to do so in stable as properly handling deleted posts requires a more consistent approach for each social network. This work should instead be done in later versions as such work will require a lot of changes. Which is against our stable version policy. task-3999571 Forward-Port-Of: odoo/enterprise#72934 Forward-Port-Of: odoo/enterprise#69168

This commit adds a new error modal when you clicking on deleted tweets and
posts.
It was decided to do so in stable as properly handling deleted posts requires
a more consistent approach for each social network.
This work should instead be done in later versions as such work will require a
lot of changes. Which is against our stable version policy.

task-3999571

Forward-Port-Of: odoo/enterprise#72934
Forward-Port-Of: odoo/enterprise#69168

Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version. This also correct two errors that were used in the generic SAF-T module: - The accounts codes should be used for AccountID instead of the account database ids - The ValueDate should be the accounting date and not the invoice date. Based on the info from: - Previous version SAF-T description: https://www.skatteetaten

Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version.

This also correct two errors that were used in the generic SAF-T module:
- The accounts codes should be used for AccountID instead of the account database ids
- The ValueDate should be the accounting date and not the invoice date.

Based on the info from:
- Previous version SAF-T description: https://www.skatteetaten.no/globalassets/bedrift-og-organisasjon/starte-og-drive/rutiner-regnskap-og-kassasystem/saf-t-regnskap/oppdateringer-desember-2020/norwegian-saf-t-financial-data---technical-description.pdf
- New version: https://www.skatteetaten.no/globalassets/bedrift-og-organisasjon/starte-og-drive/rutiner-regnskap-og-kassasystem/saf-t-regnskap/oppdateringer-mars-2024/norwegian-saf-t-financial-data---technical-description.pdf

task-3975794

Forward-Port-Of: odoo/enterprise#72232
Forward-Port-Of: odoo/enterprise#65221

With NL Company Open "General Ledger" Hit Save > Select XAF > Click 'Export' Issue: "TypeError: argument should be a bytes-like object or ASCII string, not 'generator'" This occurs because when calling `export_report` we save the attachment and we need the actual file content. opw-3820739 Forward-Port-Of: odoo/enterprise#72294

With NL Company
Open "General Ledger"
Hit Save > Select XAF > Click 'Export'
Issue: "TypeError: argument should be a bytes-like object or ASCII string, not 'generator'"

This occurs because when calling `export_report` we save the attachment and we need the actual file content.

opw-3820739

Forward-Port-Of: odoo/enterprise#72294

Before this commit, when the user horizontally scrolls in the grid view of `My Timesheets` menu, the grid timer button on each row is hidden, only the row title is kept. This commit keeps the grid timer button is kept when the user horizontally scroll in the grid view of `My Timesheets` menu as it is the case for the row title. task-3378510 Forward-Port-Of: odoo/enterprise#54052

Before this commit, when the user horizontally scrolls in the grid view of `My Timesheets` menu, the grid timer button on each row is hidden, only the row title is kept.

This commit keeps the grid timer button is kept when the user horizontally scroll in the grid view of `My Timesheets` menu as it is the case for the row title.

task-3378510

Forward-Port-Of: odoo/enterprise#54052