Before this commit, scanning a partner's barcode did not successfully load the partner from the server, leading to functionality issues. opw-3986674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170493

Before this commit, scanning a partner's barcode did not successfully load the partner from the server, leading to functionality issues.

opw-3986674

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

Forward-Port-Of: odoo/odoo#170493

It may happen that user will try to blacklist a number that he already unblacklisted (archived blacklist record). Before that attempt was ignored. With this commit we simply blacklist the number again (so we unarchive existing record) ### [Reproduce] - Install mass_mailing_sms - Open Blacklisted Phone Numbers (Email Marketing / Configuration / **Bla**cklisted Email Addresses) - Blacklist a number N - Unblacklist number N - Go back to Blacklisted Phone Numbers - Blacklist a number N (a

It may happen that user will try to blacklist a number that he already
unblacklisted (archived blacklist record). Before that attempt was ignored. With
this commit we simply blacklist the number again (so we unarchive existing record)

### [Reproduce]
- Install mass_mailing_sms
- Open Blacklisted Phone Numbers (Email Marketing / Configuration / **Bla**cklisted Email Addresses)
- Blacklist a number N
- Unblacklist number N
- Go back to Blacklisted Phone Numbers
- Blacklist a number N (again) -> BUG: no effect

opw-3700268

Forward-Port-Of: odoo/odoo#170297
Forward-Port-Of: odoo/odoo#158923

Current behaviour: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Cause of the issue: --- Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, phone numbers aren't formatted, thus patched metadata not being applied. See format_number in phonenumbers "Early exit for E164 case" Fix: --- Backport of: https://github.com/odoo/odoo/commit/53885e41867653ad45ca3aef5

Current behaviour:
---
Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil.
(Adding a 9 to mobile phone numbers)

Cause of the issue:
---
Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, 
phone numbers aren't formatted, thus patched metadata not being applied.
See format_number in phonenumbers "Early exit for E164 case"

Fix:
---
Backport of: https://github.com/odoo/odoo/commit/53885e41867653ad45ca3aef55886c280240b76a 
In phone_validation, before formatting, phone_parse is called, https://github.com/odoo/odoo/blob/bdfb802293d9a3eebb378a15ed65f48b7c3182b2/addons/phone_validation/tools/phone_validation.py#L72 
old brazilian mobile numbers would be invalid, and raise an error. https://github.com/odoo/odoo/blob/bdfb802293d9a3eebb378a15ed65f48b7c3182b2/addons/phone_validation/tools/phone_validation.py#L51 
Now if the number is invalid, we force format in international, to force apply patched metadata, before re-trying to parse.

opw-3861847

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

Forward-Port-Of: odoo/odoo#170287
Forward-Port-Of: odoo/odoo#169134

Before this PR: The HSN code length validation was applied at the product level, causing issues in multi-company environments where the precision of HSN codes varies based on company turnover (e.g., 4-digits, 6-digits). After this PR: Moved HSN code length validation from the product to the invoice level. Introduced a non-blocking warning banner on the account.move (invoice) when the HSN code does not meet the company's precision requirements. Task Id: 3681519 Forward-Port-Of: odoo/odoo

Before this PR:
The HSN code length validation was applied at the product level, causing issues in multi-company environments where the precision of HSN codes varies based on company turnover (e.g., 4-digits, 6-digits).

After this PR:
Moved HSN code length validation from the product to the invoice level. Introduced a non-blocking warning banner on the account.move (invoice) when the HSN code does not meet the company's precision requirements.

Task Id: 3681519

Forward-Port-Of: odoo/odoo#152995

In 92ed88a770893f57dcceff99d9239f130aa6112d, we added a fix and tests on hr.expense & hr.expense.sheet state fields. This commit forward ports these tests as they are interesting to keep in later versions. 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#169893 Forward-Port-Of: odoo/odoo#164909

In 92ed88a770893f57dcceff99d9239f130aa6112d, we added a fix and tests on hr.expense & hr.expense.sheet state fields. This commit forward ports these tests as they are interesting to keep in later versions.

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#169893
Forward-Port-Of: odoo/odoo#164909

When the CRM module is installed, people can use the /lead command to create a new lead from a conversation. When using that command, the Odoo bot will log a message in the chat with a link to the newly created lead. When people click on that link, they will be redirected to the lead form view and will lose track of the conversation they have with the customer. To avoid that, we will now open a chat window of the active conversation when clicking on the internal link. People will then be able

When the CRM module is installed, people can use the /lead command to create a new lead from a conversation. When using that command, the Odoo bot will log a message in the chat with a link to the newly created lead. When people click on that link, they will be redirected to the lead form view and will lose track of the conversation they have with the customer.

To avoid that, we will now open a chat window of the active conversation when clicking on the internal link. People will then be able to quickly answer the client from the chat window.

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

Forward-Port-Of: odoo/odoo#166293
Forward-Port-Of: odoo/odoo#161265

Current behavior: --- On the website, when changing the background color to a darker color (ie: black) then starting a survey, the background color for the survey is lighter (ie: gray) Expected behavior: --- The survey colors should be the same as the website theme. Steps to reproduce: --- 1. Go to the website 2. Click on Edit > Theme 3. Change the background color to black 4. Save then go to Survey 5. Select a survey 6. Remove the background image if there is one 7. Click

Current behavior:
---
On the website, when changing the background color to 
a darker color (ie: black) then starting a survey, 
the background color for the survey is lighter (ie: gray)

Expected behavior:
---
The survey colors should be the same as the website theme.

Steps to reproduce:
---
1. Go to the website
2. Click on Edit > Theme
3. Change the background color to black
4. Save then go to Survey
5. Select a survey
6. Remove the background image if there is one
7. Click on Test
8. Survey's background color is grey

Cause of the issue:
---
Introduced by https://github.com/odoo/odoo/blob/90c6e52f15277d44cbecdd5f6a70391551fb72bd/addons/survey/static/src/scss/survey_templates_form.scss#L22 
A box-shadow is used to make a "translucent white overlay" 
Which lighten the background color if there is no image

Fix:
---
Only lighten the background if there is a background image

opw-3834397

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

Forward-Port-Of: odoo/odoo#169903
Forward-Port-Of: odoo/odoo#161942

Current behavior: In the journal items of a PoS session, Debit and Credit mismatch for the bank Steps to reproduce: - Install "Point of Sale", "Accounting" apps - Create a company and set the currency to something different than USD (eg. EUR) - Set the company and go to Accounting settings and set the "Fiscal Localization" to "Configurable Chart Template" - Go back to your company settings and set again the currency (for an unknown reason, it changes back to USD) - Go to Accounting -> C

Current behavior:
In the journal items of a PoS session, Debit and Credit mismatch for the bank

Steps to reproduce:
- Install "Point of Sale", "Accounting" apps
- Create a company and set the currency to something different than USD (eg. EUR)
- Set the company and go to Accounting settings and set the "Fiscal Localization" to "Configurable Chart Template"
- Go back to your company settings and set again the currency (for an unknown reason, it changes back to USD)
- Go to Accounting -> Currencies -> USD -> Add a rate line and set a rate different to 1 Unit per EUR (eg. 1.2)
- In Accounting, go to Journals -> Bank -> set the currency to USD -> do the same for Cash
- Add a Journal named "PoS" -> set its type to "Miscellaneous" -> set the short code to "POS" -> set the currency to USD
- Go to POS -> Payment Methods -> Create "Cash" -> set the journal "Cash (USD)" and the account "<some number> Account Receivable (PoS)"
- Create a "Bank" payment method -> set the journal "Bank (USD)" -> Set the Outstanding Account "<some number> Outstanding Receipts" -> set the Intermediary Account "<some number> Account Receivable (PoS)"
- Create a shop
- In the shop settings, set the default journal to "POS(USD)" then add "Cash" and "Bank to "Payment methods"
- Start a shop session and sell a product paid by bank
- Close the session ->  set the bank count to the price of 2 products
- Go to "Order" -> "Sessions" -> last session -> "Journal Items"
- The "PBNK" line doesn't have Debit and Credit equal

Cause:
The diff_amount used for the line calculation is in USD and not in the company currency

opw-3905691


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

Forward-Port-Of: odoo/odoo#168731

Increased delay between every request to iot_devices. Requests were performed every 10ms, now every minute. Forward-Port-Of: odoo/odoo#170557

Increased delay between every request to iot_devices.
Requests were performed every 10ms, now every minute.

Forward-Port-Of: odoo/odoo#170557

This PR aims to fix an issue with the Facebook snippet not being dynamically responsive for mobile views. Steps to reproduce 1. Drop inner content facebook (dynamic content) anywhere 2. Go to mobile view 3. Try to scroll horizontally. As you can see, facebook iframe is overflowing Before v16, the mechanism for mobile view was different. The switch between mobile and desktop views caused snippets/pages to be re-render because a new dialog for mobile was opened every time. Starting fro

This PR aims to fix an issue with the Facebook snippet not being dynamically responsive for mobile views.

Steps to reproduce
1. Drop inner content facebook (dynamic content) anywhere
2. Go to mobile view
3. Try to scroll horizontally.

As you can see, facebook iframe is overflowing

Before v16, the mechanism for mobile view was different. The switch between mobile and desktop views caused snippets/pages to be re-render because a new dialog for mobile was opened every time. Starting from version 16, we have removed the dialog and introduced a mobile frame. As a result, the rendering now occurs only when the start function is called. Consequently, the params width does not change when we switch to mobile view.

![2024-04-29_14-34](https://github.com/odoo/odoo/assets/157009134/75a5fb69-8a46-4908-8814-0673084ed1d0)

After this PR, the snippet will be re-render every time the window resizes, ensuring that the width adjustment is responsive. This enhancement also allows parameters to be provided at the time of rendering.

![2024-04-29_14-35](https://github.com/odoo/odoo/assets/157009134/30a5c2f9-1e47-4902-a7c1-89506a541a26)

Task-2736174

Forward-Port-Of: odoo/odoo#170292
Forward-Port-Of: odoo/odoo#163739

Prior to this PR, if the words inside the grid were too long (ex: german), they were overflowing under the other elements of the grid. In worst cases scenario, words may be truncated. task-3815487 **Before**  **After**  --- I confir

Prior to this PR, if the words inside the grid were too long (ex: german), they were overflowing under the other elements of the grid.
In worst cases scenario, words may be truncated.

task-3815487

**Before**  
 
![Screenshot 2024-05-28 at 17 19 58](https://github.com/odoo/odoo/assets/108661430/ad6c82b5-7ac7-4393-9081-55146d07ec98)

**After** 
![Screenshot 2024-05-29 at 10 01 19](https://github.com/odoo/odoo/assets/108661430/27f0ad9f-5999-4335-a45a-4492e79bdeb5)




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

Forward-Port-Of: odoo/odoo#158066

### [FIX] calendar: public user no attachment When public user will create an appointment, the attachments attached to the related mail template will filtered out by a `_process_attachments_for_post` method (ref.1) I happens because attachment's `res_model` is not set to `mail.compose.message`. Instead it's set to `mail.template` also `create_uid` isn't set to public user, but to the user creating the template). With this commit attachments will get copied on send with corrected `res_mode

### [FIX] calendar: public user no attachment
When public user will create an appointment, the attachments
attached to the related mail template will filtered out by
a `_process_attachments_for_post` method (ref.1)
I happens because attachment's `res_model` is not set to `mail.compose.message`.
Instead it's set to `mail.template` also `create_uid` isn't set to public user,
but to the user creating the template). With this commit attachments will
get copied on send with corrected `res_model`.

### [Reproduce]
- Install modules: appointment,website
- Add an attachment A to email templates: (in Settings/Email_Templates):
	- "Appointment Booked"
- On Website/Appointment: book an appointment (from an incognito window)
- BUG: no attachments are added to the emails (Settings/ Technical/ Email/ Emails)
	- no .ics attachment
	- no A attachment

(ref.1)
https://github.com/odoo/odoo/blob/312b0365e26e1578c5995d55f357b8aec14e5a5b/addons/mail/models/mail_thread.py#L2207C1-L2210

opw-[3685871](https://www.odoo.com/web#id=3685871&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#160518

Steps: - Install sale and razopay app. - Set-up razorpay provider. - Create quotation. - Pay that quotation via razorpay and save payment details. - Duplicate that quote and pay it via already saved method. Issue: - Creating duplicate token when paying via token. Cause: - Since [PR] we are creating token in odoo when razorpay give token_id in notification_data and tokenization is enabled on razorpay and in some case when we pay quote via token it return token in notification_data an

Steps:
- Install sale and razopay app.
- Set-up razorpay provider.
- Create quotation.
- Pay that quotation via razorpay and save payment details.
- Duplicate that quote and pay it via already saved method.

Issue:
- Creating duplicate token when paying via token.

Cause:
- Since [PR] we are creating token in odoo when razorpay give token_id in notification_data and tokenization is enabled on razorpay and in some case when we pay quote via token it return token in notification_data and since we forgot to check if transaction is already connected to token or not it always create new token :(

Fix:
- Add condition to check if transaction is connected to token or not and only create token if transaction is not connected to token. Additionally pass entity_data in token creation method so it pass proper data when we don't find `id` in `notification_data`.

[PR]: https://github.com/odoo/odoo/pull/159250

Forward-Port-Of: odoo/odoo#170370
Forward-Port-Of: odoo/odoo#170112

Purpose ======= Fix the display of the quiz comment line: - the trash icon is displayed under the line instead of next to it. - the comment input is too large and should be aligned with the answers inputs. Specification ============= The comment input is too large because the "form-control" class has a "width: 100%" style that overwrites the "width: 66.66666667%" one applied by the "col-8" class. The good fix would be to create a new parent for the input and apply the "col-8" class

Purpose
=======
Fix the display of the quiz comment line:
- the trash icon is displayed under the line instead of next to it.
- the comment input is too large and should be aligned with the answers inputs.

Specification
=============
The comment input is too large because the "form-control" class has a "width: 100%"
style that overwrites the "width: 66.66666667%" one applied by the "col-8" class.

The good fix would be to create a new parent for the input and apply the "col-8" class
to limit its width accordingly while still keeping the good row gutters and margins.
However as changing the xml structure is not recommended in stable, the fix is to add
the "col-8" on the current "row" parent and forcing the trash icon to be next to by
using the "flex-nowrap" class.

Task-3986982

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

Forward-Port-Of: odoo/odoo#169237

This commit fixes an issue introduced by https://github.com/odoo/odoo/pull/170159. forEach is not available for mapIterator on non-chromium based browser. opw-4008053 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#170702

This commit fixes an issue introduced by https://github.com/odoo/odoo/pull/170159. forEach is not available for mapIterator on non-chromium based browser.

opw-4008053

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

the fix replaces the `\xa0` with ` ` for html translated values and keeps the consistent logic as odoo/odoo#110148 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#170692

the fix replaces the `\xa0` with ` ` for html translated values and keeps the consistent logic as odoo/odoo#110148

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

In 76d328624fecaed5167b0e4fc1210014309d59a9, the underscore methods were removed. Following this change, a traceback occurs because concat is supposed to be used on an Array. When no element is in existing tags, addedTags is null, and if there is a single tag, it is not an array but an object. In order to fix this, we format properly the addedTags to have an array, allowing the use of the concat method. Task-3527175 Forward-Port-Of: odoo/odoo#170947 Forward-Port-Of: odoo/odoo#170856

In 76d328624fecaed5167b0e4fc1210014309d59a9, the underscore methods were removed. Following this change, a traceback occurs because concat is supposed to be used on an Array. When no element is in existing tags, addedTags is null, and if there is a single tag, it is not an array but an object.

In order to fix this, we format properly the addedTags to have an array, allowing the use of the concat method.

Task-3527175

Forward-Port-Of: odoo/odoo#170947
Forward-Port-Of: odoo/odoo#170856

Steps to reproduce the issue: - Create a storable product “P1” with a BoM: - Component: Select any component - Work order: OP1: 60 minutes in workcenter “Assembly Line 1” - Go to workcenter “Assembly Line 1”: - Specific capacities: P1, capacity: 1, setup: 10 minutes - Alternative workcenter: “Assembly Line 2”: - Specific capacities: P1, capacity: 1, setup: 5 minutes - Create a manufacturing order “MO1” to produce 1 unit: - Date: May 10, 2024, 08:00:00 -

Steps to reproduce the issue:
- Create a storable product “P1” with a BoM:
    - Component: Select any component
    - Work order: OP1: 60 minutes in workcenter “Assembly Line 1”

- Go to workcenter “Assembly Line 1”:
    - Specific capacities: P1, capacity: 1, setup: 10 minutes
    - Alternative workcenter: “Assembly Line 2”:
        - Specific capacities: P1, capacity: 1, setup: 5 minutes

- Create a manufacturing order “MO1” to produce 1 unit:
    - Date: May 10, 2024, 08:00:00
- Create a manufacturing order “MO2” to produce 1 unit:
    - Date: May 10, 2024, 08:00:00

Issue:
- After confirming and planning MO1, the expected duration is 70 minutes.
- After confirming and planning MO2, the expected duration is 75 minutes
instead of 65.

The setup time of workcenter Assembly Line 1 for specific product is not
reduced from the expected time.

opw-3904023

Forward-Port-Of: odoo/odoo#170353
Forward-Port-Of: odoo/odoo#165128

backport of: https://github.com/odoo/odoo/pull/128821/commits/733eccd37a2f303aa8a6f894625f3ae73a6a1cc3 Steps to reproduce the bug: - Create a storable product “P1” with BoM - Operation: OP1 - Component: C1, consumed in: OP1 - Navigate to Mrp > Configuration > Operations - Select OP1 and select another BoM - return to the BoM of “P1” Problem: The BoM line for component "P1" is still linked to OP1, And a traceback when attempting to duplicate the BoM. Solution: Remove t

backport of: https://github.com/odoo/odoo/pull/128821/commits/733eccd37a2f303aa8a6f894625f3ae73a6a1cc3

Steps to reproduce the bug:
- Create a storable product “P1” with BoM
    - Operation: OP1
    - Component: C1, consumed in: OP1

- Navigate to Mrp > Configuration > Operations
- Select OP1 and select another BoM
- return to the BoM of “P1”

Problem:
The BoM line for component "P1" is still linked to OP1,
And a traceback when attempting to duplicate the BoM.

Solution:
Remove the operation from the initial BOM lines

opw-3948817

Forward-Port-Of: odoo/odoo#170265
Forward-Port-Of: odoo/odoo#166884

Linked enterprise PR: https://github.com/odoo/enterprise/pull/63589 ### Steps to reproduce: - Create a company and a branch - Create a contact and assign him to the company created - Switch to the branch and go to the Contact app - You can't see the contact created ### Cause: The rule 'res.partner company' does not allow branches to see partners from the parent company. ### Solution: Change the rule to make partners accessible to branches. This solution implies changing access ru

Linked enterprise PR: https://github.com/odoo/enterprise/pull/63589

### Steps to reproduce:
- Create a company and a branch
- Create a contact and assign him to the company created
- Switch to the branch and go to the Contact app
- You can't see the contact created

### Cause:
The rule 'res.partner company' does not allow branches to see partners from the parent company.

### Solution:
Change the rule to make partners accessible to branches.
This solution implies changing access rules defined in base to use the 'parent_of' operator. By changing it, I removed a performance improvement introduced in this commit: https://github.com/odoo/odoo/commit/c18b9f44be3d666ca1e082807a2fdfc7ef2049d2. So I needed to change performance tests counting queries to make them pass.

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

Forward-Port-Of: odoo/odoo#166965

Steps to reproduce the bug: - Go to the "/partners" page. - Click on the first partner to go to their page. - Enter "edit mode". - Drag and drop a "Dynamic products" snippet into the right column of the page. - Save the page. - Bug: the "Dynamic products" snippet is not visible on the page. The problem is not specific to the "Dynamic products" snippet. The issue occurs with all snippets. When the "website description" field is saved, all HTML attributes are removed (except the "cla

Steps to reproduce the bug:

- Go to the "/partners" page.
- Click on the first partner to go to their page.
- Enter "edit mode".
- Drag and drop a "Dynamic products" snippet into the right column of
the page.
- Save the page.
- Bug: the "Dynamic products" snippet is not visible on the page.

The problem is not specific to the "Dynamic products" snippet. The issue
occurs with all snippets. When the "website description" field is saved,
all HTML attributes are removed (except the "class" attribute). This
causes many bugs, which vary depending on the snippets dropped into the
field.

This commit adds the parameter "sanitize_overridable=True" to the
"website_description" field of "website_partner". It means that the
description can now be properly edited as an user with enough rights,
while keeping the same level of protection for other users editing this
field. Still buggy, below version 15.0, for a restricted editor editing
that description but should be rare.

opw-3908218

Forward-Port-Of: odoo/odoo#165482

[IMP] l10n_pk: improve pakistan's tax structure - Restructure the tax and tax group. - Adding new taxes - Adding tax tags to all the taxes - Create two new tax report Reason: Enhance the user-experience in pakistan Task-3871597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170808 Forward-Port-Of: odoo/odoo#164128

[IMP] l10n_pk: improve pakistan's tax structure

- Restructure the tax and tax group.
- Adding new taxes
- Adding tax tags to all the taxes
- Create two new tax report

Reason: Enhance the user-experience in pakistan

Task-3871597

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

Forward-Port-Of: odoo/odoo#170808
Forward-Port-Of: odoo/odoo#164128

We assert a hardcoded string with the name of the base.partner_root data inside test_onchange_one2many_default(). Without mail this name is "System", with the mail module it becomes "OdooBot". Then the test works if we have mail installed Forward-Port-Of: odoo/odoo#170777

We assert a hardcoded string with the name of the base.partner_root data inside test_onchange_one2many_default(). Without mail this name is "System", with the mail module it becomes "OdooBot". Then the test works if we have mail installed

Forward-Port-Of: odoo/odoo#170777

Before this commit, when images are added to an Image Wall or to an Image Gallery, they remained in their original format. After this commit, images added to an Image Wall or an Image Gallery are converted to webp. Thanks to [1], the Image Gallery dataset entries related to the conversion are preserved. [1]: https://github.com/odoo/odoo/commit/e73a1a96dcf8786c01205ae0a97b10e38ab9afeb task-3666894 Forward-Port-Of: odoo/odoo#170192 Forward-Port-Of: odoo/odoo#148068

Before this commit, when images are added to an Image Wall or to an
Image Gallery, they remained in their original format.

After this commit, images added to an Image Wall or an Image Gallery
are converted to webp.

Thanks to [1], the Image Gallery dataset entries related to the
conversion are preserved.

[1]: https://github.com/odoo/odoo/commit/e73a1a96dcf8786c01205ae0a97b10e38ab9afeb

task-3666894

Forward-Port-Of: odoo/odoo#170192
Forward-Port-Of: odoo/odoo#148068

Steps: - Install the Project module > Create a new project - Open Project > Create task stage(s) - Delete all task stages Issue: - If all the stages are deleted then blank screen appears instead of shadow data(example data). Cause: - Incorrect active_model was passed. Fix: - Issue is been fixed by removing active_model. task-3744319 Forward-Port-Of: odoo/odoo#170711 Forward-Port-Of: odoo/odoo#154682

Steps:
- Install the Project module > Create a new project
- Open Project > Create task stage(s)
- Delete all task stages

Issue:
- If all the stages are deleted then blank screen appears instead of shadow data(example data).

Cause:
- Incorrect active_model was passed.

Fix:
- Issue is been fixed by removing active_model.

task-3744319

Forward-Port-Of: odoo/odoo#170711
Forward-Port-Of: odoo/odoo#154682

Before commit: To reproduce the error: A device may send non-JSON data to the IoT controller, or the CDN might return an error in a non-JSON format. We just get a very non-explicit error: "Expecting value: line 1 column 1 (char 0)". After commit: We add a catch for non-JSON data and log the error along with the incorrect data to have more information. opw-3876631 Forward-Port-Of: odoo/odoo#170132 Forward-Port-Of: odoo/odoo#169938

Before commit:

To reproduce the error: A device may send non-JSON data to the IoT controller, or the CDN might return an error in a non-JSON format.

We just get a very non-explicit error: "Expecting value: line 1 column 1 (char 0)".

After commit:

We add a catch for non-JSON data and log the error along with the incorrect data to have more information.

opw-3876631

Forward-Port-Of: odoo/odoo#170132
Forward-Port-Of: odoo/odoo#169938

In Switzerland's demo data, the BIC is from a Belgian bank which is wrong. Removing BIC in this case as it's useless. task-3961609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167726

In Switzerland's demo data, the BIC is from a Belgian bank which is wrong. Removing BIC in this case as it's useless.

task-3961609

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

Forward-Port-Of: odoo/odoo#167726

**Steps to reproduce:** - Install Accounting, website_sale_subscription and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Install a payment provider (e.g. Demo) - Create a 1-year recurring service product - Go to the Shop page as a public user - Add the recurring service to the cart - Process checkout without entering a VAT number - Process payment **Issue:** An Internal server error is raised while trying to generate Facturae EDI because no VAT has been ente

**Steps to reproduce:**
- Install Accounting, website_sale_subscription and l10n_es_edi_facturae
- Switch to a Spanish company (e.g. ES Company)
- Install a payment provider (e.g. Demo)
- Create a 1-year recurring service product
- Go to the Shop page as a public user
- Add the recurring service to the cart
- Process checkout without entering a VAT number
- Process payment

**Issue:**
An Internal server error is raised while trying to generate Facturae EDI because no VAT has been entered.

**Cause:**
After a transaction is done for a subscription, an invoice is created and sent automatically.
As "l10n_es_edi_facturae" module is installed, it tries to generate the EDI document when sending the invoice, but it fails because the partner has no VAT.

**Solution:**
The Facturae EDI xml is not a mandatory document.
It should not block any flow when not generated manually.
Just ignore any UserError from the generation of Facturae EDI when the invoice has been forced-created.

opw-936227


Linked enterprise PR: https://github.com/odoo/enterprise/pull/65086

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

Forward-Port-Of: odoo/odoo#170144

Steps: - Install l10n_fr and make sure fr company has tax id filled - Go to bank journal and set a bank account number - Go to Customer invoice journal and check `Factur-X` in the Advenced Settings tab - Create a french customer F with an email address - Open a pos session, and make an invoice forF for a product with tax, select Bank payment method and confirm - Go to invoices and select the newly created invoice -> "Error occured while creating the EDI document" Cause: The field `partner

Steps:

- Install l10n_fr and make sure fr company has tax id filled
- Go to bank journal and set a bank account number
- Go to Customer invoice journal and check `Factur-X` in the
  Advenced Settings tab
- Create a french customer F with an email address
- Open a pos session, and make an invoice forF for a product with tax,
  select Bank payment method and confirm
- Go to invoices and select the newly created invoice
-> "Error occured while creating the EDI document"

Cause:

The field `partner_bank_id` is not set from the pos order to the invoice

cbe1cf5b1044827a058a4cde5d0492a545ac6da4 added a condition specifically
for swiss localisation.

Fix:

Movr the condition to a bridge module for swiss localisation

opw-3992498

Forward-Port-Of: odoo/odoo#170762

PURPOSE One-click unsubscribe headers are becoming required in order to avoid having marketing emails being qualified as spam. This change adds those headers in various modules: digest (backport of changes done for v17), mailing lists (mail_group module) and improve unsubscribe in mass mailing by supporting one-click unsubscribe (as current portal page is not one-click available). Modules * mass mailing * digest * mail group SUMMARY To ease the way people can unsubscribe from

PURPOSE

One-click unsubscribe headers are becoming required in order to avoid having
marketing emails being qualified as spam. This change adds those headers
in various modules: digest (backport of changes done for v17), mailing
lists (mail_group module) and improve unsubscribe in mass mailing by supporting
one-click unsubscribe (as current portal page is not one-click available).

Modules
* mass mailing
* digest
* mail group

SUMMARY

To ease the way people can unsubscribe from a digest, we have followed the
advice of RFC8058 by adding the following header to the email:
* List-Unsubscribe: unsubscribe route;
* List-Unsubscribe-Post: List-Unsubscribe=One-Click

The unsubscribe route
* must work with the POST method but not the GET. The GET version is disabled
to avoid unintended unsubscrbe that could be triggered by an anti-spam
accessing the URLs in the headers. Email readers are supposed to do
POST requests as described in the RFC;
* must unsubscribe the user without any additional steps (one click)
* should contain an opaque identifier hard-to-forge to identify the list and
the user (our token fulfills that goal). The goal is to avoid that someone
is allowed to unregister someone else easily.
* must fulfill other conditions like no cookie, no redirection, ... hence those
routes return a 200 status.

MISC

Also fix various issues in digest, notably improve tone down computation and
fix issues when computing the new timespan.

Task-3741195 (Digest: Make It Quality Spam)
Task-3717213 (Mail: Ensure Unsubscribe Headers)
Task-3741203 (Digest: Investigate tone down / reminder)

Forward-Port-Of: odoo/odoo#170825
Forward-Port-Of: odoo/odoo#153864

This data is possible to be modified by users. Marking it as noupdate also avoids possible errors during upgrades, as if some values get updated (eg: product.product.type) it can [trigger validation errors](https://github.com/odoo/odoo/blob/16.0/addons/stock/models/product.py#L890). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169882 Forward-Port-Of: odoo/odoo#169623

This data is possible to be modified by users.
Marking it as noupdate also avoids possible errors during upgrades, as if some values get updated (eg: product.product.type) it can [trigger validation errors](https://github.com/odoo/odoo/blob/16.0/addons/stock/models/product.py#L890).




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

Forward-Port-Of: odoo/odoo#169882
Forward-Port-Of: odoo/odoo#169623

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

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

Methods from l10n_cl_edi has been moved from l10n_cl_edi (enterprise) as part of https://github.com/odoo/enterprise/pull/46593. This includes _l10n_cl_get_amounts and _float_repr_float_round on the account move model, as well as the method _l10n_cl_get_line_amounts on the account move line model. They can therefore be removed in this commit. The VAT section for the electronic ticket document is also being transferred in the same manner, and can thus be removed in the template here. As par

Methods from l10n_cl_edi has been moved from l10n_cl_edi (enterprise) as part of https://github.com/odoo/enterprise/pull/46593. This includes
_l10n_cl_get_amounts and _float_repr_float_round on the account move model, as well as the method _l10n_cl_get_line_amounts on the account move line model. They can therefore be removed in this commit.

The VAT section for the electronic ticket document is also being transferred in the same manner, and can thus be removed in the template here.

As part of the same refactor, methods _l10n_cl_get_invoice_totals_for_report and _l10n_cl_prices_and_taxes had been deprecated, and additionally there is a new exclusive qweb totals widget for chilean invoices. This will allow showing in PDF reports, invoices that had been generated in a foreign currencies or in UF index.

X-original-commit: 7d22eaaf135e20b5c94e8419b8b6418483f1a139

[FIX] l10n_cl: replace t-esc with t-out

(cherry picked from commit 27f592e49b381cf3344b808db8358c677a528489)

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#164062
Forward-Port-Of: odoo/odoo#162147

Since [1] cover images are implicitly converted to webp. Those converted images were stored related to their record (e.g. a given blog post). Because of this, the created attachment was not made public, and therefore not available for visitors. This commit fixes this by linking the cover image to the general concept of `ir.ui.view` - as it was the case before images were converted. Doing this makes the image attachments public. Steps to reproduce: - Upload a JPG image as a published blog

Since [1] cover images are implicitly converted to webp. Those converted images were stored related to their record (e.g. a given blog post). Because of this, the created attachment was not made public, and therefore not available for visitors.

This commit fixes this by linking the cover image to the general concept of `ir.ui.view` - as it was the case before images were converted. Doing this makes the image attachments public.

Steps to reproduce:
- Upload a JPG image as a published blog post cover.
- Save => a WEBP version of the image is uploaded.

=> Visitors could not see the image when viewing the blog post.

[1]: https://github.com/odoo/odoo/commit/068dcc27e417d52b51d274c44497f4388fed780a

opw-4009916

Forward-Port-Of: odoo/odoo#170849

Before this commit, when is_gcc_country was false, a colon followed by a number would appear in the receipt, which was confusing. This commit removes this misleading information for receipts in non-GCC countries. opw-3992612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170620

Before this commit, when is_gcc_country was false, a colon followed by a number would appear in the receipt, which was confusing. This commit removes this misleading information for receipts in non-GCC countries.

opw-3992612

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

Forward-Port-Of: odoo/odoo#170620

The keyboard shortcut for the `Check Sending` action was the same as the one used to create a new record. Ticket [link](https://www.odoo.com/web#model=project.task&id=3970056) opw-3970056 Forward-Port-Of: odoo/odoo#168160

The keyboard shortcut for the `Check Sending` action
was the same as the one used to create a new record.

Ticket [link](https://www.odoo.com/web#model=project.task&id=3970056)
opw-3970056

Forward-Port-Of: odoo/odoo#168160

With restriction imposed by Colombian EDI, the PoS is not 100% compatible and usable as such features are not adapted for such restrictions. --- Description of the issue this commit addresses: When trying to issue a credit note via the POS (refund with invoice) and the colombian EDI module is installed, a traceback shows up as it is required to have a description code on the the credit note invoice but nothing in the UI makes it possible to add such data. --- Steps to reproduce:

With restriction imposed by Colombian EDI, the PoS is not 100% compatible and usable as such features are not adapted for such restrictions.

---

Description of the issue this commit addresses:

When trying to issue a credit note via the POS (refund with invoice) and the colombian EDI module is installed, a traceback shows up as it is required to have a description code on the the credit note invoice but nothing in the UI makes it possible to add such data.

---

Steps to reproduce:

1-Install l10n_co_pos and l10n_co_edi
2-Setup all the fun stuff for the edi to work (credentials, VAT, journals, ...) 3-Go in the POS and post an order
4-Now refund that order and make sure to make an invoice with that refund, post 5-An error message shows up to inform that some data is missing.

---

Desired behavior after the commit is merged:

This commit makes it so that when a credit note is created from the PoS, if it is linked to Colombia, the description code is set to 1 if no code is already set.

---

Note on the fix:

It is currently not possible to already have a description code when the invoice is created so the default could be replaced by an assignation but I figured that if we add the possibility in the future, it would be great not to override it.

---

task-3977188

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

Forward-Port-Of: odoo/odoo#170867
Forward-Port-Of: odoo/odoo#170739

**Cause:** In version 17.0, new fields (repeat_unit, repeat_type, repeat_until) [ref](https://github.com/odoo/odoo/blob/d7cfef9c51461a595f3f46c7b91e5c56241d4af3/addons/maintenance/models/maintenance.py#L265) were introduced in the maintenance module. These fields are set as required in the view 'maintenance.hr_equipment_request_view_form', but they are only visible if the request is a recurrent maintenance request, which causes a validation error when changing the status. **Solution:** Change

**Cause:** In version 17.0, new fields (repeat_unit, repeat_type, repeat_until) [ref](https://github.com/odoo/odoo/blob/d7cfef9c51461a595f3f46c7b91e5c56241d4af3/addons/maintenance/models/maintenance.py#L265) were introduced in the maintenance module. These fields are set as required in the view 'maintenance.hr_equipment_request_view_form', but they are only visible if the request is a recurrent maintenance request, which causes a validation error when changing the status.

**Solution:** Change the required condition 'True' to recurring_maintenance == True, as the field is only visible for recurring maintenance requests. Making it required for all cases is not feasible.

**Note:** This is not a bug in the general version of 17.0; it is introduced after an upgrade from version 16.0 to 17.0.

for more detail:  odoo/upgrade#6147

**opw-3983692**

**Current behavior before PR:**
 when migrating from 16.0 to 17.0, getting validation error on changing the state of maintenance request
![image](https://github.com/odoo/odoo/assets/145324071/5af78939-933e-41a6-8ab5-f4ba5f69984d)


**Desired behavior after PR is merged:**
able to change the state of maintenance request
![image](https://github.com/odoo/odoo/assets/145324071/e72de3f3-6787-4761-9151-3f7f2fdbd78b)


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

Forward-Port-Of: odoo/odoo#169169

Ensure that _setup_main_restaurant_defaults is only called when the main restaurant does not have an active session. This prevents potential errors that could occur if the method is called while a session is active. E.g: https://runbot.odoo.com/runbot/build/64372543 opw-3937178 Forward-Port-Of: odoo/odoo#170936 Forward-Port-Of: odoo/odoo#170507

Ensure that _setup_main_restaurant_defaults is only called when the main restaurant does not have an active session. This prevents potential errors that could occur if the method is called while a session is active. E.g: https://runbot.odoo.com/runbot/build/64372543

opw-3937178

Forward-Port-Of: odoo/odoo#170936
Forward-Port-Of: odoo/odoo#170507

This commit moves a call to `_loadMissingPricelistItems` within the `computeProductPricelistCache` method of `PosStore` outside of a for loop. This is done because it only needs to be called once for the products, not once for each product. `_loadMissingPricelistItems` calls `pos.session/get_pos_ui_product_pricelist_item_by_product`, which can be an expensive call. This commit minimizes how many times it's called. opw-3928634 Forward-Port-Of: odoo/odoo#170962

This commit moves a call to `_loadMissingPricelistItems` within the `computeProductPricelistCache` method of `PosStore` outside of a for loop. This is done because it only needs to be called once for the products, not once for each product.

`_loadMissingPricelistItems` calls `pos.session/get_pos_ui_product_pricelist_item_by_product`, which can be an expensive call. This commit minimizes how many times it's called.

opw-3928634

Forward-Port-Of: odoo/odoo#170962

Steps to reproduce: - Install Calendar - Go to next week for example - Click on an event -> edit - In the breadcrumb return to the calendar view Issues: The calendar show the current week and not the previous one. Even though we export the state we don't restore the date from the previous ones. opw-3946022 Forward-Port-Of: odoo/odoo#170103

Steps to reproduce:
- Install Calendar
- Go to next week for example
- Click on an event -> edit
- In the breadcrumb return to the calendar view

Issues:
The calendar show the current week and not the previous one. Even though we export the state we don't restore the date from the previous ones.

opw-3946022

Forward-Port-Of: odoo/odoo#170103

Use case to reproduce: - Install stock and accounting without demo data - Load demo data Current behavior: RuntimeError: Module operations inside tests are not transactional and thus forbidden... It happens due to commit [1]. However, when loading the demo data the current thread has the attribute 'testing' set to True and prevent the installation of new modules. The solution would be to prevent the installation of l10n when loading demo data as before the patch [1] 0d4fac7fe0a356

Use case to reproduce:
- Install stock and accounting without demo data
- Load demo data

Current behavior:
RuntimeError: Module operations inside tests are not transactional and thus forbidden...

It happens due to commit [1]. However, when loading the demo data the current thread has the attribute 'testing' set to True and prevent the installation of new modules.

The solution would be to prevent the installation of l10n when loading demo data as before the patch

[1] 0d4fac7fe0a356cbaf40f71587c78765ce50fc1e

Forward-Port-Of: odoo/odoo#170748

This update adjusts internal test expectations to account for an extra database check when deleting an accounting move. It helps keep automated validation accurate for document accounting behavior without changing the user experience.

One additionnal query is made to check if we need to set the marker for a gap created when unlinking the move.