Peruvian cash and bank reports now use Odoo's official SUNAT bank code field instead of an older built-in code list. This helps keep reports aligned with current compliance data and reduces the risk of outdated bank codes being used.

Now was added the Odoo field to bank code provided by the SUNNAT, and that field must be used in the bank report.

Now is used and deprecated the dict that has that codes.

An unnecessary internal log message was removed from the spreadsheet chart editing area. This helps keep browser logs cleaner without changing any user-facing spreadsheet behavior.

This update corrects an internal styling value used to control shadows in the Enterprise web interface. It has no visible impact for users, but keeps the underlying stylesheet valid and easier to maintain.

In commit odoo/enterprise@aab87024b9dc901dfbca9a9de9739a698989d3f4 we introduced variables to enable the box-shadows on some bootstrap components.

However the property was set to `0` which is an invalid property value. The correct value is `none`.

This issue doesn't have any visible impact, so it's safe to be fixed in master.

task-3755095

This fix keeps the new message separator appearing correctly in WhatsApp conversations, even after many messages are sent. It also updates the related automated test so it matches the corrected notification behavior.

When sending a lot of messages, it can happen that the new message separator does not appear anymore.

The community counterpart of this PR fixes this issue but modify a notification payload that is asserted in a whatsapp test.

This PR updates this test to match the notification content.


community: https://github.com/odoo/odoo/pull/170601

This update streamlines how automated website tour tests check that page elements are present. It reduces internal complexity for maintaining Odoo tests without changing day-to-day user workflows.

In order to simplify the towers API, it was decided to remove the extra_trigger key from the steps.
To check that an element is in the DOM, simply create a step with a trigger.

task~3974087

Spreadsheet pivot formulas were updated to handle values more consistently after related spreadsheet engine changes. This is an internal cleanup that reduces complexity and helps keep pivot reports reliable without introducing major user-facing changes.

This commit is the counterpart of https://github.com/odoo/o-spreadsheet/pull/4466.
It adapts the code to the changes made in the pivot formulas.

In addition, the handling of positional arguments is simplified.
Before this commit, the positinal arguments were replaced by their
actual values in the `getPivotCellValueAndFormat` and
`getPivotHeaderValueAndFormat`.
Now, this replacement is done before calling these functions. So, these
functions can get rid of the positional arguments.

Task: 3991743

This update modernizes internal list view testing and fixes a few supporting test utilities. It helps Odoo maintain reliable web interface behavior while reducing the risk of future regressions, with no direct change expected for end users.

task-3705027

Spreadsheet formulas now handle values like numbers and true/false choices in a more consistent way. This supports more reliable spreadsheet behavior, especially when using pivot tables and autofill features.

This commit is the counterpart of https://github.com/odoo/odoo/pull/169914.
It adapts the autofill plugin and its tests to the parsing of arguments.

It also adapts the tests to the new formatting of arguments (boolean is
now a boolean in the formula, a number is a number, etc.).

Task: 3991743

The variable `query_results_to_pay` was shadowed inside of the loop, leading to unexpected results as only the last sale/purchase journal was taken into account for amounts to pay. Forward-Port-Of: odoo/odoo#170036

The variable `query_results_to_pay` was shadowed inside of the loop, leading to unexpected results as only the last sale/purchase journal was taken into account for amounts to pay.

Forward-Port-Of: odoo/odoo#170036

A traceback is occurig when the user creating a SO without Qutation date. To reproduce this issue:- 1) Install `Sales` 2) Enable `Sales Credit Limit` in the settings 3) Try to create a `Quotation` by removing the default `Quotation Date` and then add a `Customer` 4) A traceback occurs Error:- ``` AttributeError: 'bool' object has no attribute 'date' ``` When the user removes the `date_order` its value will be false. This leads to the traceback when the `date` is extracte

A traceback is occurig when the user creating a SO without Qutation date.

To reproduce this issue:-

1) Install `Sales`
2) Enable `Sales Credit Limit` in the settings
3) Try to create a `Quotation` by removing the default `Quotation Date`
   and then add a `Customer`
4) A traceback occurs

Error:- 
```
AttributeError: 'bool' object has no attribute 'date'
```

When the user removes the `date_order` its value will be false. 
This leads to the traceback when the `date` is extracted from `date_order`.

https://github.com/odoo/odoo/blob/16e8de01b14ddac69cd706f8f64e762406769542/addons/sale/models/sale_order.py#L385

After applying this commit will resolve this issue by taking the current date if the 'date_order' is false. This makes code more robust.

senrty-5500467446

Forward-Port-Of: odoo/odoo#170355
Forward-Port-Of: odoo/odoo#169911

From the dashboard, we already know in which sequence the gaps are. By filtering the moves based on that information, we can dramatically improve the performance by not querying the whole table. On a test server queries using this condition went from 10s to 5ms. When opening the list view from the dashboard, 2 queries are run for a total of 20s (`web_search_read` and `web_read_group`) Forward-Port-Of: odoo/odoo#170053 Forward-Port-Of: odoo/odoo#167382

From the dashboard, we already know in which sequence the gaps are. By filtering the moves based on that information, we can dramatically improve the performance by not querying the whole table.

On a test server queries using this condition went from 10s to 5ms. When opening the list view from the dashboard, 2 queries are run for a total of 20s (`web_search_read` and `web_read_group`)

Forward-Port-Of: odoo/odoo#170053
Forward-Port-Of: odoo/odoo#167382

## Issue In Course List, After v17.3 + There a topless border in icons where button is disabled. Which looks weird and doesn't make sense as we don't need any border there. ## Technical This issue came from this commit odoo@7d66dcb , where `disabled="1"` was added inside the button. The default `btn.disabled` has button border in [bootstrap](https://github.com/odoo/odoo/blob/51af11c9180fe48ba3492ffd3402a22bde211318/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L3048-L3053) c

## Issue

In Course List, After v17.3 +
There a topless border in icons where button is disabled.
Which looks weird and doesn't make sense as we don't need any border there.

## Technical

This issue came from this commit odoo@7d66dcb , where `disabled="1"` was added inside the button.
The default `btn.disabled` has button border in [bootstrap](https://github.com/odoo/odoo/blob/51af11c9180fe48ba3492ffd3402a22bde211318/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L3048-L3053) code.
That's why the border is appearing there.

## After this PR

There will be no borders where icon buttons are disabled.

Task-3975450

Forward-Port-Of: odoo/odoo#168800

**Steps to reproduce:** - Install Sale and Project modules - Create a project with 1 or 2 stages - Create more than 1 task in this project - Assign those tasks to a Sale order - Go to this sale order and click on tasks smart button **Current behavior before PR:** When clicking on the task smart button in a sale order you will see lots of stages that are not associated with the shown tasks' project. This is happening because the value assigned to default_project_id in the context is

**Steps to reproduce:**
	- Install Sale and Project modules
	- Create a project with 1 or 2 stages
	- Create more than 1 task in this project
	- Assign those tasks to a Sale order
	- Go to this sale order and click on tasks smart button

**Current behavior before PR:**
When clicking on the task smart button in a sale order you will see lots of stages that are not associated with the shown tasks' project. This is happening because the value assigned to default_project_id in the context is False.
https://github.com/odoo/odoo/blob/saas-16.4/addons/sale_project/models/sale_order.py#L166

**Desired behavior after PR is merged:**
We are now just showing the stages associated with the shown tasks' project by assigning those tasks' project id to the default_project_id value in context.

opw-3929012

Forward-Port-Of: odoo/odoo#170111
Forward-Port-Of: odoo/odoo#168035

Since [1], a tooltip indicating "This block cannot be dropped anywhere on this page." appears each time you hover a draggable snippet. This commit addresses the issue by only showing this tooltip in the right circumstances, when a snippet is not draggable (disabled or installable...). [1]: https://github.com/odoo/odoo/commit/91293fe4a8125f65cd7e5f487aacbc62c35c0f74#diff-c971e01f28cfbdec366b6a712c516e3427887fde8a39674e5bb3b5a056cedad0R178 task-3893159 Forward-Port-Of: odoo/odoo#16489

Since [1], a tooltip indicating "This block cannot be dropped anywhere
on this page." appears each time you hover a draggable snippet.

This commit addresses the issue by only showing this tooltip in the
right circumstances, when a snippet is not draggable (disabled or
installable...).

[1]: https://github.com/odoo/odoo/commit/91293fe4a8125f65cd7e5f487aacbc62c35c0f74#diff-c971e01f28cfbdec366b6a712c516e3427887fde8a39674e5bb3b5a056cedad0R178

task-3893159

Forward-Port-Of: odoo/odoo#164898

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

**Steps to reproduce:** - Install Invoicing - Go to "Invoicing / Configuration / Settings" - Deactivate "Document Digitalization" - Create an invoice - Upload a PDF via paperclip button or drag and drop in the chatter **Issue:** The preview box appears but it is empty. **Cause:** In "onUploaded" function of Chatter component, the parent view is not reloaded once the attachment is uploaded because "hasParentReloadOnAttachmentsChanged" property is False. This property depends on "post

**Steps to reproduce:**
- Install Invoicing
- Go to "Invoicing / Configuration / Settings"
- Deactivate "Document Digitalization"
- Create an invoice
- Upload a PDF via paperclip button or drag and drop in the chatter

**Issue:**
The preview box appears but it is empty.

**Cause:**
In "onUploaded" function of Chatter component, the parent view is not reloaded once the attachment is uploaded because "hasParentReloadOnAttachmentsChanged" property is False. This property depends on "post_refresh" option.

**Solution:**
Add "post_refresh" option for "message_ids" field in the view as it is done when "account_invoice_extract" module is installed.

opw-3887671



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

Forward-Port-Of: odoo/odoo#170351
Forward-Port-Of: odoo/odoo#169612

**Current behavior:** Switching from manual to automated valuation on a product that has a negative quantity will create entries in the valuation journal with incorrect debit/credit figures. **Expected behavior:** The lines generated in this manner should look like ones created when the valuation is generated for a product that was already valuated with the automated option. **Steps to reproduce:** 1. Create a product category with the default manual valuation method, create a storable

**Current behavior:**
Switching from manual to automated valuation on a product that has a negative quantity will create entries in the valuation journal with incorrect debit/credit figures.

**Expected behavior:**
The lines generated in this manner should look like ones created when the valuation is generated for a product that was already valuated with the automated option.

**Steps to reproduce:**
1. Create a product category with the default manual valuation method, create a storable product that belongs to it

2. Sell some quantity of the new product without adding any on-hand quantity (so that the qty is negative), confirm the order and generate the invoice

3. Swap to automated valuation in the product category that was created in step 1

4. In the entries for the stock valuation journal, observe that:
     A) the stock valuation account is getting *debited* instead of credited, and

     B) the other entry generated is for the stock input account
          instead of stock output, and

     C) the debit/credit amounts should be swapped here as well

**Cause of the issue:**
The negative quantity case is not considered when we do the empty/replenish sequence on valuation method change.

**Fix:**
Add an explicit check for negative quantity in the replenish step of changing valuation method.

opw-3810779

Forward-Port-Of: odoo/odoo#170428
Forward-Port-Of: odoo/odoo#165179

Steps to reproduce: ------------------- 1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24. 2. Post the move, the deferred entries are created 3. Set the All User Lock Date to 31/12/23 4. Reset the move to draft - The deferral moves of 2024 are deleted. - The deferral moves of 2023 are still linked to the move - The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date) 5. Post

Steps to reproduce:
-------------------
1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24.
2. Post the move, the deferred entries are created
3. Set the All User Lock Date to 31/12/23
4. Reset the move to draft

- The deferral moves of 2024 are deleted.
- The deferral moves of 2023 are still linked to the move
- The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date)

5. Post the move again

A traceback is raised because of an assert that verifies that we shouldn't regenerate deferral entries if a move already has them.

Solution:
---------
1. The generated reversal of the deferrals of 2023 should be linked to the move.
2. Now that this is done, we can remove the assert because all deferral entries will cancel out each other (i.e. the aggregation will result in no deferral entries).
3. When reverting, we will now use the accounting date instead of the first day after the lock date (if there is one)

opw-3861179

https://github.com/odoo/enterprise/pull/61928

Forward-Port-Of: odoo/odoo#170454
Forward-Port-Of: odoo/odoo#164316

Before this PR: When loggin into a company, it would simply add the new company in the list of the currently selected/active companies, this made it harder to use or stay in single-company mode. After this PR: Logging into a company will now switch companies if we are in single-company mode, essentially making the user stay in single-company mode. The user can still toggle companies to enter multi-company mode. *This behaviour got lost when adding the branches system in the company s

Before this PR:
When loggin into a company, it would simply add the new company in the
list of the currently selected/active companies, this made it harder
to use or stay in single-company mode.

After this PR:
Logging into a company will now switch companies if we are in single-company
mode, essentially making the user stay in single-company mode. The user
can still toggle companies to enter multi-company mode.

*This behaviour got lost when adding the branches system in the company service.*

Task ID: 3927141

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

Forward-Port-Of: odoo/odoo#170175
Forward-Port-Of: odoo/odoo#165227

Since [^1], string domains are not taken into account for related fields. As a result, pos fields in the `res.config.settings` don't have the correct domains. The user is then shown non-relevant records in the selections for relational fields. We fix this issue by converting the string domains to a valid list or lambda expression domains. Related: https://github.com/odoo/enterprise/pull/64755 **Up to saas-17.2:** <img width="1024" alt="Screenshot 2024-06-18 at 10 32 50" src="https://git

Since [^1], string domains are not taken into account for related fields. As a result, pos fields in the `res.config.settings` don't have the correct domains. The user is then shown non-relevant records in the selections for relational fields. We fix this issue by converting the string domains to a valid list or lambda expression domains.

Related: https://github.com/odoo/enterprise/pull/64755

**Up to saas-17.2:**

<img width="1024" alt="Screenshot 2024-06-18 at 10 32 50" src="https://github.com/odoo/enterprise/assets/3245568/6b4d05d7-b7f8-4e12-8e57-65c9d70bf875">

**Starting saas-17.3:**

<img width="986" alt="Screenshot 2024-06-18 at 10 30 33" src="https://github.com/odoo/enterprise/assets/3245568/9c4964d4-8f81-4b4d-8399-7140927c5dc7">


[^1]: https://github.com/odoo/odoo/commit/f66c9159045b9b63044b6897ecc831cdad57967f

Forward-Port-Of: odoo/odoo#169588

When sending a lot of messages, it can happen that the new message separator does not appear anymore. Steps to reproduce the issue: - Open two browsers: one logged in as admin, and the other as demo. - Send a bunch of messages to demo very quickly. - Send a message to admin. - Notice that the unread message banner does not appear. When the user first accesses the thread, the separator is kept locally and is displayed until the user sends a message. From a technical standpoint, the

When sending a lot of messages, it can happen that the new message
separator does not appear anymore.

Steps to reproduce the issue:
- Open two browsers: one logged in as admin, and the other as demo.
- Send a bunch of messages to demo very quickly.
- Send a message to admin.
- Notice that the unread message banner does not appear.

When the user first accesses the thread, the separator is kept locally
and is displayed until the user sends a message.

From a technical standpoint, the server tells the client when to sync
the separator value when certain actions occur (e.g., message sent,
explicitly marking a message as read).

In this case, the server sends the wrong information, indicating that
the separator should not be synced when it actually should be. This PR
fixes that issue.

Forward-Port-Of: odoo/odoo#170256

enterprise: https://github.com/odoo/enterprise/pull/65394

### Current Behavior: - Go in the project app, click on a project and click on a task - Change the stage of the task The duration spent in the previous stage is displayed in the new stage. Note: if you refresh the page the bug will disappear. ### Cause of the issue: The `duration_tracking` of the `project.task` model is a non stored computed json field. During the computation of this field, the previous trackings of the object are retrieved from `mail.tracking.value` model: https

### Current Behavior:

- Go in the project app, click on a project and click on a task
- Change the stage of the task

The duration spent in the previous stage is displayed in the new stage.

Note: if you refresh the page the bug will disappear.

### Cause of the issue:

The `duration_tracking` of the `project.task` model is a non stored computed json field. During the computation of this field, the previous trackings of the object are retrieved from `mail.tracking.value` model: https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/mail/models/mail_tracking_duration_mixin.py#L45-L60 To be sure that these trackings will be correctly retrieved, the model used by the query are even flushed. However, these mail tracking values are only created at the end of the sql transaction because the `_track_finalize` method is part of the precommit hooks of the transaction and is hence only run during the general sql flush: https://github.com/odoo/odoo/blob/784f90d25614e4816ac3ed26f0643b562071edbd/odoo/sql_db.py#L134-L138 https://github.com/odoo/odoo/blob/784f90d25614e4816ac3ed26f0643b562071edbd/odoo/tools/misc.py#L1215-L1221 As such, the mail tracking values generated by the old value of the stage will only be accessible at the end of the transaction and will not be available during the computation duration_tracking run for the project task in its final stage. Leading to an incorrect computation of the field during onchanges:
https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/mail/models/mail_tracking_duration_mixin.py#L62-L64

### Fix:

In order for the the mail tracking values generated by the old stage to be present during the final computation of our duration_tracking we trigger the `_track_finalize` precommit hook on the records for which it should be run at the end of the transaction before the execution of our query.

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

Forward-Port-Of: odoo/odoo#161688

**Description of the issue/feature this PR addresses:** This PR addresses the orientation of chart labels in survey live session. Previously, chart labels in the survey live session struggled to display longer labels effectively. Labels are now tilted by min 20 degrees for better visibility and display of longer labels in survey live sessions chart. **Task**-3884116 Forward-Port-Of: odoo/odoo#170305 Forward-Port-Of: odoo/odoo#163288

**Description of the issue/feature this PR addresses:**
This PR addresses the orientation of chart labels in survey live session.

Previously, chart labels in the survey live session struggled to display longer labels effectively.
Labels are now tilted by min 20 degrees for better visibility and display of longer labels in survey live sessions chart.

**Task**-3884116

Forward-Port-Of: odoo/odoo#170305
Forward-Port-Of: odoo/odoo#163288

**Reproduce issue:** - Drop and drop a form snippet - Set a field as a multiple checkbox - Toggle on option 1 - Set a space at the end of option 1 so "option 1 " - Blur the input **Result:** You will find, Option 1 is no more selected. The root cause of this issue appears to be the unexpected trimming of the HTML input box. By default, HTML trims leading and trailing spaces, as well as considers multiple inner spaces as a single space. Consequently, inconsistencies arise between

**Reproduce issue:**

- Drop and drop a form snippet
- Set a field as a multiple checkbox
- Toggle on option 1
- Set a space at the end of option 1 so "option 1 "
- Blur the input

**Result:** You will find, Option 1 is no more selected.

The root cause of this issue appears to be the unexpected trimming of the HTML
input box. By default, HTML trims leading and trailing spaces, as well as
considers multiple inner spaces as a single space. Consequently, inconsistencies
arise between the input value, ID, and display name. This commit trims the value
from the initial to maintain consistency.

As a result, `option 1`, `option 1   `, `  option 1`, and `option     1` will
all be trimmed and considered the same.

task-3254884

Forward-Port-Of: odoo/odoo#170365
Forward-Port-Of: odoo/odoo#128692

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#170208
Forward-Port-Of: odoo/odoo#161942

Following #156437, the mechanism to handle negative procurements was removed as it wasn't applicable with the new push flow. This was a mistakes, as : - The old pull flow is still available, so we still need to be able to propagate a negative quantity. - Even with the new push flow, this introduced a regression as we couldn't process negative quantity PO/SO anymore. The main issue was that with the new push flow, the whole picking chain might not exist yet by the time a negative quantity pr

Following #156437, the mechanism to handle negative procurements was removed as it wasn't applicable with the new push flow. This was a mistakes, as :
- The old pull flow is still available, so we still need to be able to propagate a negative quantity.
- Even with the new push flow, this introduced a regression as we couldn't process negative quantity PO/SO anymore.

The main issue was that with the new push flow, the whole picking chain might not exist yet by the time a negative quantity procurement is generated.
Let's take the following case, in 3 step delivery
- Stock -> Packing: qty = 5, status = 'done'
- Packing -> Output: qty = 5, status = 'assigned'

Here, we have the first step that was already processed, so the move from Packing -> Output has been created, while the one from Output -> Customer isn't yet (i.e. it will be when Packing -> Output is done). That means that if we were to create a procurement of -1 qty, we'd want:
- New: Packing -> Stock: qty = 1 (move back the excess qty)
- Packing -> Output: qty = 4 (merge the quantity into the existing move)
- NO Customer -> Output move, as the delivery move hasn't yet been created.

To achieve this, in the case of negative procurements, we instead generate the whole push chain of negative move then try to merge them. Then, we remove moves that shouldn't have been created.

Note: Also restores some tests that were disabled by the pull&push refactor now that it works again :roll_eyes: 

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

Forward-Port-Of: odoo/odoo#170425
Forward-Port-Of: odoo/odoo#165100

The field `max_tax_lock_date` is not always computed correctly. This is since the compute function does not depend on the `tax_lock_date` field. It should not happen in production since the `tax_lock_date` and the check of `max_tax_lock_date` should not happen in the same transaction. But it can still cause issues in tests. The missing dependency is added in this commit. enterprise PR (fixing a test): https://github.com/odoo/enterprise/pull/65262 Forward-Port-Of: odoo/odoo#170475

The field `max_tax_lock_date` is not always computed correctly. This is since the compute function does not depend on the `tax_lock_date` field.

It should not happen in production since the `tax_lock_date` and the check of `max_tax_lock_date` should not happen in the same transaction. But it can still cause issues in tests.

The missing dependency is added in this commit.

enterprise PR (fixing a test): https://github.com/odoo/enterprise/pull/65262

Forward-Port-Of: odoo/odoo#170475

Steps: - Install the project - Enable use custom enable server from general settings. Set an alias domain - Create a new project - Wizard pops up Issue: - Default value of alias domain is not set. Cause: - alias_domain_id is related to alias_id and it is not present in the view. Fix: - Issue is been fixed by adding a field in wizard view as alias domain was getting fetched on that field. - Additionally the same field is been to added to form view as well. task-3744319 Forwar

Steps:
- Install the project
- Enable use custom enable server from general settings. Set an alias domain
- Create a new project
- Wizard pops up

Issue:
- Default value of alias domain is not set.

Cause:
- alias_domain_id is related to alias_id and it is not present in the view.

Fix:
- Issue is been fixed by adding a field in wizard view as alias domain was getting fetched on that field.
- Additionally the same field is been to added to form view as well.

task-3744319

Forward-Port-Of: odoo/odoo#154681

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

Steps to reproduce: ------------------- - Install `website_event` module - Create an event with name `Test Event` and enable `Website Submenu` option - Click on `Go to Website` stat button - Edit the `Introduction` page by adding a new block under the event name for example - Save it and go back to backend - Create a new event with same name `Test Event` and enable `Website Submenu` option - Click on `Go to Website` stat button Issue: ------ The second event will have the edited

Steps to reproduce:
-------------------

- Install `website_event` module
- Create an event with name `Test Event` and enable `Website Submenu` option
- Click on `Go to Website` stat button
- Edit the `Introduction` page by adding a new block under the event name for example
- Save it and go back to backend
- Create a new event with same name `Test Event` and enable `Website Submenu` option
- Click on `Go to Website` stat button

Issue:
------

The second event will have the edited
`Introduction` page from the first event.

Cause:
------

When creating the menu, since we do not create a
page, the URL retrieved in the process will be
always the same and therefore redirect to the
edited page of the first event (since the last
part of the URL is used to retrieve the right
view).

Solution:
---------

Ensure the URL is unique by using the view key
(who is unique) as last part of the URL.

opw-3945840

Forward-Port-Of: odoo/odoo#170478
Forward-Port-Of: odoo/odoo#169770

**Current behavior:** Having a storage location with a storage category that has a max quantity acting on some productA, and a putaway rule that will move product from an intermediary location to the location with the category: Creating a move for productA into the intermediary location that won't hit the cap applied on the second location, then creating an additional move (separate picking) with a demand that exceeds the cap will result in the cap not getting respected during the quant move

**Current behavior:**
Having a storage location with a storage category that has a max quantity acting on some productA, and a putaway rule that will move product from an intermediary location to the location with the category:

Creating a move for productA into the intermediary location that won't hit the cap applied on the second location, then creating an additional move (separate picking) with a demand that exceeds the cap will result in the cap not getting respected during the quant move process.

**Expected behavior:**
The second move will not get assigned via putaway rule to the second location, as its quantity is too large.

**Steps to reproduce:**
1. Create a storage category with a capacity: `product: productA` `quantity: 5`

2. Create an internal location: `parent location: WH/STOCK` `storage category: from step 1`

3. Create a putaway rule: `product: productA` `src location: WH/STOCK` `dest location: from step 2` `storage category: from step1`

4. Create a receipt picking with a move for productA that will not exceed the storage categ. cap -> confirm the picking

5. Create another receipt picking with a move for productA that exceeds the storage categ. cap -> confirm -> fill out the quantity -> validate

6. Go to the storage location and view its quants, see it's more than the max capacity

**Cause of the issue:**
During the picking assignment, the current/pending quantity of the proposed location gets calculated. Prior to the 7dda6bb refactor on the `qty_done` field, this current/pending quantity was stored in the method in a local variable, coincidentally also called qty_done. It got changed to quantity in this commit, which is also the name of one of the method arguments that represents the quantity value of the current move line which is being validated.

Thus, the incoming quantity becomes the current quantity in the location which, of course, does not validate the defined cap.

**Fix:**
Rename the local variable.

opw-3926597

Forward-Port-Of: odoo/odoo#170422
Forward-Port-Of: odoo/odoo#169746

Previously, the floating icon wasn't an OWL component and has been refactored into an OWL component. When refactored he lost the auto move up top logic that came with the css classes 'o_bottom_fixed_element' and 'o_bottom_fixed_element_move_up' This commit reintroduce this auto move up behavior by default within the OWL component by listening to the scroll event of the document and identifying whenever we reach the end of the document. It is useful so we ensure the users can click all l

Previously, the floating icon wasn't an OWL component and has been
refactored into an OWL component. When refactored he lost the auto
move up top logic that came with the css classes 'o_bottom_fixed_element'
and 'o_bottom_fixed_element_move_up'

This commit reintroduce this auto move up behavior by default within the
OWL component by listening to the scroll event of the document and
identifying whenever we reach the end of the document. It is useful
so we ensure the users can click all links potentially present in the
footer. If the icon is dragged and moved elsewhere, we prevent this
smart behavior from happening until next refresh of the state.

Commit introducing the drag & drop feature :
https://github.com/odoo/odoo/commit/d9f07235484

Commit of the OWL refactoring :
https://github.com/odoo/odoo/commit/20c1772d

Steps to reproduce :

- Install LiveChat
- Toggle Mobile display
- Scroll down to the bottom of page
-> The livechat floating icon doesn't go up as it was before

task-3946855

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

Forward-Port-Of: odoo/odoo#169831
Forward-Port-Of: odoo/odoo#169383

Since [1], `opacity` needs to be a number as defined in ColorPlaette's props definition. However, in the ColorpickerUserValueWidget, when the props is passed to the ColorPalette component, it is given from the dataAttributes, which are strings. This leads to a crash in debug mode as the types are miss-matching. This commit fixes that by parsing the dataAttribute to float. [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997#diff-c4e4c8cbbe59c3e61eba1cdcfd8f2380

Since [1], `opacity` needs to be a number as defined in ColorPlaette's props definition. However, in the ColorpickerUserValueWidget, when the props is passed to the ColorPalette component, it is given from the dataAttributes, which are strings. This leads to a crash in debug mode as the types are miss-matching.

This commit fixes that by parsing the dataAttribute to float.

[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997#diff-c4e4c8cbbe59c3e61eba1cdcfd8f23809818a0b78c118d84606a1ab5d7bf1203

task-4001189

Forward-Port-Of: odoo/odoo#170092

Before this commit, when creating a company and directly installing a chart template without putting a country first, the installation of the chart template was giving a traceback. By updating the country of the company by the one of the chart template, the issues will not happen again. task: 3945833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170617 Forward-Port-Of: odoo/odoo#166896

Before this commit, when creating a company and directly installing a chart template without putting a country first, the installation of the chart template was giving a traceback.
By updating the country of the company by the one of the chart template, the issues will not happen again.

task: 3945833




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

Forward-Port-Of: odoo/odoo#170617
Forward-Port-Of: odoo/odoo#166896

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

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: --- See community commit Adding extra tests in test_whatsapp opw-3861847

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:
---
See community commit
Adding extra tests in test_whatsapp

opw-3861847

Forward-Port-Of: odoo/enterprise#65336

### Issue: The VAT lines in tax reports do not populate correctly. ### Steps to reproduce: - Activate l10n_es module - Go to Accounting > Reporting > Statement Reports > Tax Report - Select a 'Generic Tax Report' and click on 'VAT Record Books (XLSX)' - In the report, only Spain and partners without countries have a NIF number ### Cause: A line of code is only populating the NIF field in the report if the partner has no country or if the country is Spain. In addition, other lines

### Issue:
The VAT lines in tax reports do not populate correctly.

### Steps to reproduce:
- Activate l10n_es module
- Go to Accounting > Reporting > Statement Reports > Tax Report
- Select a 'Generic Tax Report' and click on 'VAT Record Books (XLSX)'
- In the report, only Spain and partners without countries have a NIF number

### Cause:
A line of code is only populating the NIF field in the report if the partner has no country or if the country is Spain.

In addition, other lines related to the NIF are not populated as they should.

### Solution:
Add conditions to populate the NIF lines as the specs demands it.
Specs: https://sede.agenciatributaria.gob.es/static_files/AEAT/LSI.xlsx (second point)

opw-3918623

Forward-Port-Of: odoo/enterprise#63923

At component record creation, the sequence is based on `mps.mps_sequence`. However, mps can contain multiple records. This PR extract the sequence of the parent record to calculate the sequence of its components. Forward-Port-Of: odoo/enterprise#65064

At component record creation, the sequence is based on `mps.mps_sequence`. However, mps can contain multiple records.
This PR extract the sequence of the parent record to calculate the sequence of its components.

Forward-Port-Of: odoo/enterprise#65064

This will add an input type: gratification for the luxembourg payslips. If there is a gratification in the other inputs, the rules will be added to the payslip and the gratification is computed in the same way as the 13th month. Task: 3794333 Forward-Port-Of: odoo/enterprise#64830 Forward-Port-Of: odoo/enterprise#63800

This will add an input type: gratification for the luxembourg payslips. If there is a gratification in the other inputs,
the rules will be added to the payslip and
the gratification is computed in the same way as the 13th month.

Task: 3794333

Forward-Port-Of: odoo/enterprise#64830
Forward-Port-Of: odoo/enterprise#63800

This PR fixes a contrast issue on a primary button within the sign module due to a `text-white` class applied. The default button utility classes already provide a good contrast, meaning that adding extra class is not useful. To fix the issue, we simply remove the class from the button. task-3692048 | Light mode (`:focus` state) | Dark mode | |--------|--------| | <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/b73a2fe7-f802-4461-9015-16a2f4b46d92"> | <img al

This PR fixes a contrast issue on a primary button within the sign module due to a `text-white` class applied.

The default button utility classes already provide a good contrast, meaning that adding extra class is not useful. To fix the issue, we simply remove the class from the button.

task-3692048

| Light mode (`:focus` state) | Dark mode |
|--------|--------|
| <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/b73a2fe7-f802-4461-9015-16a2f4b46d92"> | <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/8354c78f-6525-4aef-9057-fdb706b3cd0d"> |

Forward-Port-Of: odoo/enterprise#64801

Steps to reproduce: - Install Helpdesk - Create two internal user with admin access to Helpdesk - Log as the first user and create a ticket for the second user with empty phone Issues: An access error is shown as we do not have the rights to write on the partner phone. To fix this issue a sudo was added as well as a filter in the inverse to make sure we skip ticket without a partner phone in the inverse. opw-3989614 Forward-Port-Of: odoo/enterprise#65289 Forward-Port-Of: odoo/enterpri

Steps to reproduce:
- Install Helpdesk
- Create two internal user with admin access to Helpdesk
- Log as the first user and create a ticket for the second user with empty phone

Issues:
An access error is shown as we do not have the rights to write on the partner phone. To fix this issue a sudo was added as well as a filter in the inverse to make sure we skip ticket without a partner phone in the inverse.

opw-3989614

Forward-Port-Of: odoo/enterprise#65289
Forward-Port-Of: odoo/enterprise#64860

We are unable to update the 'create date' and 'write date' through the ORM method. Therefore, I used a patch. task-4004191 Forward-Port-Of: odoo/enterprise#65151

We are unable to update the 'create date' and 'write date' through the ORM method.
Therefore, I used a patch.

task-4004191

Forward-Port-Of: odoo/enterprise#65151

Currently the tax lock date is not checked correctly in a test when posting a move. This problem is solved in the related community PR. This commit ensures the test does not fail after the community fix. To do this we just remove and re-introduce the tax lock date. community PR: https://github.com/odoo/odoo/pull/170475 Forward-Port-Of: odoo/enterprise#65262

Currently the tax lock date is not checked correctly in a test when posting a move.

This problem is solved in the related community PR.

This commit ensures the test does not fail after the community fix. To do this we just remove and re-introduce the tax lock date.

community PR: https://github.com/odoo/odoo/pull/170475

Forward-Port-Of: odoo/enterprise#65262

Adapt the tests to match the changes done community-side to properly handle negative procurements. Community PR: odoo/odoo#165100 Forward-Port-Of: odoo/enterprise#65237 Forward-Port-Of: odoo/enterprise#64575

Adapt the tests to match the changes done community-side to properly handle negative procurements.

Community PR: odoo/odoo#165100

Forward-Port-Of: odoo/enterprise#65237
Forward-Port-Of: odoo/enterprise#64575

…ter its parent web_enterprise modifies the js template for the list_renderer by introducing an upsell point for Studio in the optional columns dropdown. That inheritance spec was not at any particular place in the inheritance hierarchy. On some views (e.g. account invoices) this feature was not available. This commit fixes the issue by manually forcing the extension in web_enterprise to go just after list_renderer.xml from the web module. After this commit, the upsell feature is ava

…ter its parent

web_enterprise modifies the js template for the list_renderer by introducing an upsell point for Studio in the optional columns dropdown.

That inheritance spec was not at any particular place in the inheritance hierarchy. On some views (e.g. account invoices) this feature was not available.

This commit fixes the issue by manually forcing the extension in web_enterprise to go just after list_renderer.xml from the web module.

After this commit, the upsell feature is available on the views that did not have it before.

Forward-Port-Of: odoo/enterprise#64942
Forward-Port-Of: odoo/enterprise#64776

**Steps to reproduce:** - Install Rental module - Check gantt view in Rental > Schedule **Current behavior before PR:** We are just showing the products that has orders. This is happening because in those commit https://github.com/odoo/enterprise/pull/37757/commits/0c2f235d4876467df287f30ab3cb09785603cd7f https://github.com/odoo/enterprise/pull/37757/commits/836909419893b522890776d3ec2f16476ae21108 we introduced the group limit and get_gantt_data and rental_schedule has not get adapted w

**Steps to reproduce:**
	- Install Rental module
	- Check gantt view in Rental > Schedule

**Current behavior before PR:**
We are just showing the products that has orders. This is happening because in those commit https://github.com/odoo/enterprise/pull/37757/commits/0c2f235d4876467df287f30ab3cb09785603cd7f https://github.com/odoo/enterprise/pull/37757/commits/836909419893b522890776d3ec2f16476ae21108 we introduced the group limit and get_gantt_data and rental_schedule has not get adapted with this new behaviour.

So what is happening is that '_read_group_product_ids'
https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule.py#L20
is not called as there is a limit so https://github.com/odoo/enterprise/blob/17.0/web_gantt/models/models.py#L76 This computes to be False so https://github.com/odoo/odoo/blob/17.0/odoo/models.py#L2745:L2754 '_read_group_fill_results' will not get called to call '_read_group_product_ids'

**Desired behavior after PR is merged:**
After override 'get_gantt_data' we are now checking if all products count is more than the limit we just return the products that already have orders.

**Other solution:**
We might just remove the group_limit https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule_views.xml#L54 and just go with the '_read_group_product_ids'.

opw-3959031

Forward-Port-Of: odoo/enterprise#65232
Forward-Port-Of: odoo/enterprise#63720

Forward-Port-Of: odoo/enterprise#65297

Forward-Port-Of: odoo/enterprise#65297

Some fields introduced in the pos_iot has string domains that are no longer valid since [^1]. As a result, the user sees all the related records when selecting the values for those fields from the `res.config.settings` form. In this commit, we are converting the domains from string to lambda expressions for it to work in the new restriction introduced in [^1]. Related: https://github.com/odoo/odoo/pull/169588 **Up to saas-17.2:** <img width="1024" alt="Screenshot 2024-06-18 at 10 32

Some fields introduced in the pos_iot has string domains that are no longer valid since [^1]. As a result, the user sees all the related records when selecting the values for those fields from the `res.config.settings` form.

In this commit, we are converting the domains from string to lambda expressions for it to work in the new restriction introduced in [^1].

Related: https://github.com/odoo/odoo/pull/169588

**Up to saas-17.2:**

<img width="1024" alt="Screenshot 2024-06-18 at 10 32 50" src="https://github.com/odoo/enterprise/assets/3245568/6b4d05d7-b7f8-4e12-8e57-65c9d70bf875">

**Starting saas-17.3:**

<img width="986" alt="Screenshot 2024-06-18 at 10 30 33" src="https://github.com/odoo/enterprise/assets/3245568/9c4964d4-8f81-4b4d-8399-7140927c5dc7">


[^1]: https://github.com/odoo/odoo/commit/f66c9159045b9b63044b6897ecc831cdad57967f

Forward-Port-Of: odoo/enterprise#64755

Steps to reproduce ================== 1. Go to the Accounting module 2. Open Vendor Bills 3. Click on the Scan button with debugger mode ON => Hence gives traceback Cause of the issue ================== The Issue was due to the `BillQrScan` component doing the props validation same as the `Dialog` component, the `slots` object is a mandatory prop for Dialog component but not needed for `BillQrScan`. This commit solves the traceback generating due to props validation on `BillQrScan

Steps to reproduce
==================
1. Go to the Accounting module
2. Open Vendor Bills
3. Click on the Scan button with debugger mode ON

=> Hence gives traceback

Cause of the issue
==================
The Issue was due to the `BillQrScan` component doing the props validation same as the `Dialog` component, the `slots` object is a mandatory prop for Dialog component but not needed for `BillQrScan`.

This commit solves the traceback generating due to props validation on `BillQrScan` component.

Forward-Port-Of: odoo/enterprise#65047

Following the doc https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2023-11/EPC132-08%20SCT%20C2PSP%20IG%202023%20V1.1.pdf , InitgPty/Id is not required in the XML file. We used to block the generation if we had no value to put in it; not anymore. opw-3985622 Forward-Port-Of: odoo/enterprise#65255 Forward-Port-Of: odoo/enterprise#65214

Following the doc https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2023-11/EPC132-08%20SCT%20C2PSP%20IG%202023%20V1.1.pdf , InitgPty/Id is not required in the XML file. We used to block the generation if we had no value to put in it; not anymore.

opw-3985622

Forward-Port-Of: odoo/enterprise#65255
Forward-Port-Of: odoo/enterprise#65214

When we introduced dynamic templates in Knowledge, we merged the models `knowledge.article` and `knowledge.article.template` and introduced a new field `is_template` in the `knowledge.article` model to distinguish the templates from the regular articles. In the `website_helpdesk_knowledge` module, we forgot to exclude the templates from the search domains. As a result, the helpdesk frontend view can list and search within templates. Steps to reproduce the issue: 1. Log in as "Admin". 2

When we introduced dynamic templates in Knowledge, we merged the models `knowledge.article` and `knowledge.article.template` and introduced a new field `is_template` in the `knowledge.article` model to distinguish the templates from the regular articles.

In the `website_helpdesk_knowledge` module, we forgot to exclude the templates from the search domains. As a result, the helpdesk frontend view can list and search within templates.

Steps to reproduce the issue:

1. Log in as "Admin".
2. Install `website_helpdesk_knowledge` module.
3. Go on the Helpdesk module.
4. On the helpdesk overview, click on the vertical dots of the "Customer Care" team card.
5. On the dropdown menu, click on the "Settings" option.
6. On the "Help Center" section, click on the "Knowledge" option.
7. On the "Visibility & Assignment" section, click on "Invited portal users and all internal users" option.
8. Save the changes.
9. Go on the Website module.
10. On the website navbar, click on "Customer Care" nav bar.
11. The interface should list article templates.

=> TO BE: The system should not list any templates.

To fix that issue, we will simplify the search domains and exclude the templates from the search results using the `is_template` field.

Reference: https://github.com/odoo/enterprise/pull/48691

task-3987469

Forward-Port-Of: odoo/enterprise#64468

Steps to reproduce: 1. Open the split tool, select a few pages, and create an expense for instance 2. Once the pages are gone, navigate with the keyboard 3: Traceback occurred Technical reason: When we navigated using the left arrow, it couldn't find the documents we were targeting. In the '_focusNextPage' function, inside 'PdfManager' it was attempting to access elements like 'arr[-2]', which resulted in an 'undefined' value. After this commit: No traceback will occur and if it can't

Steps to reproduce:
1. Open the split tool, select a few pages, and create an expense for instance
2. Once the pages are gone, navigate with the keyboard 3: Traceback occurred

Technical reason:
When we navigated using the left arrow, it couldn't find the documents we were targeting. In the '_focusNextPage' function, inside 'PdfManager' it was attempting to access elements like 'arr[-2]', which resulted in an 'undefined' value.

After this commit:
No traceback will occur and if it can't find the previous or next selected
page, it focuses on the first page by default.

Task-3874151

Forward-Port-Of: odoo/enterprise#62244

Steps to reproduce: ------------------- 1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24. 2. Post the move, the deferred entries are created 3. Set the All User Lock Date to 31/12/23 4. Reset the move to draft - The deferral moves of 2024 are deleted. - The deferral moves of 2023 are still linked to the move - The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date) 5. Post

Steps to reproduce:
-------------------
1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24.
2. Post the move, the deferred entries are created
3. Set the All User Lock Date to 31/12/23
4. Reset the move to draft

- The deferral moves of 2024 are deleted.
- The deferral moves of 2023 are still linked to the move
- The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date)

5. Post the move again

A traceback is raised because of an assert that verifies that we shouldn't regenerate deferral entries if a move already has them.

Solution:
---------
1. The generated reversal of the deferrals of 2023 should be linked to the move.
2. Now that this is done, we can remove the assert because all deferral entries will cancel out each other (i.e. the aggregation will result in no deferral entries).
3. When reverting, we will now use the accounting date instead of the first day after the lock date (if there is one)

opw-3861179

https://github.com/odoo/odoo/pull/164316

Forward-Port-Of: odoo/enterprise#65252
Forward-Port-Of: odoo/enterprise#61928

**Steps to reproduce:** - Install l10n_es_reports - Switch to a Spanish company (e.g. ES Company) - Create some invoices/bills and credit notes using different types of taxes - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "Generic Tax Report" - Click on "VAT Record Books (XLSX)" to download the report **Issues:** 1) Credit notes appear as positive in the report 2) Withholding taxes (having type "Retencion") are not handled. They should appear in the dedica

**Steps to reproduce:**
- Install l10n_es_reports
- Switch to a Spanish company (e.g. ES Company)
- Create some invoices/bills and credit notes using different types of taxes
- Go to "Accounting / Reporting / Statement Reports / Tax Report"
- Select "Generic Tax Report"
- Click on "VAT Record Books (XLSX)" to download the report

**Issues:**
1) Credit notes appear as positive in the report
2) Withholding taxes (having type "Retencion") are not handled.
They should appear in the dedicated column.
3) Intra-European bills have a tax that is reverted. So the tax amount
should be 0, but it is not reverted in the report.
4) If an invoice has 2 lines that use 2 different taxes of type
"Recargo de Equivalencia", one of them will not appear in the report.
5) Advanced combinations of taxes on several invoice lines are not supported.

**Solution:**
This fix changes the way of generating the Libros Registro de IVA report.
Before this fix, the report was generated based on the tax lines.
One line of the report was corresponding to a regular tax line, which didn't
support advanced combinations of taxes on several invoice lines.
This fix analyzes the taxes repartition on the invoice lines and tries to respect it when generating the report.
A line of the report corresponds to a combination of taxes of different type:
(IVA + surcharge tax + withholding tax)

**Limitation:**
Having 2 taxes of the same type on the same invoice line is not supported.
The total and the tax amount will be correct but not the tax rate because
a report line has only one column to display each type of tax.

opw-3844967

Forward-Port-Of: odoo/enterprise#65230
Forward-Port-Of: odoo/enterprise#64681

**Current behavior:** Excess lines which are created during a barcode picking flow do not get the o_faulty class which distinguishes them as not being planned during the picking's creation. **Expected behavior:** These extra lines will get the o_faulty class. **Steps to reproduce:** 1. Create a picking in the Inventory app, mark it as to-do 2. In the Barcode app, go to the picking and scan the product 3. After scanning the original demand quantity, scan it again 4. See that it

**Current behavior:**
Excess lines which are created during a barcode picking flow do not get the o_faulty class which distinguishes them as not being planned during the picking's creation.

**Expected behavior:**
These extra lines will get the o_faulty class.

**Steps to reproduce:**
1. Create a picking in the Inventory app, mark it as to-do

2. In the Barcode app, go to the picking and scan the product

3. After scanning the original demand quantity, scan it again

4. See that it doesn't get the o_faulty class

**Cause of the issue:**
The lineIsFaulty() method is checking defunct properties to determine whether they should get this css class.

**Fix:**
Update the check so it uses an existing property.

opw-3904661

Forward-Port-Of: odoo/enterprise#65200
Forward-Port-Of: odoo/enterprise#63285

During an upgrade, if the user has used the record and modified its type, it will [trigger](https://github.com/odoo/odoo/blob/17.0/addons/stock/models/product.py#L890) the `UserError`: `You can not change the type of a product that was already used.` Forward-Port-Of: odoo/enterprise#64757

During an upgrade, if the user has used the record and modified its type, it will [trigger](https://github.com/odoo/odoo/blob/17.0/addons/stock/models/product.py#L890) the `UserError`:
 `You can not change the type of a product that was already used.`

Forward-Port-Of: odoo/enterprise#64757

This PR fixes the mobile responsiveness inside the reconciliation in `account_accountant`. The width of the elements was too small and the `overflow` value broke the layout on mobile view. The point is to make the data at least readable on mobile, but this could be improved in the near future (eg. less data shown to user, displayed another way like a list-group, etc). If barcode is installed, the buttons are half-hidden under the control-panel. This is fixed in this [Enterprise/#63271](ht

This PR fixes the mobile responsiveness inside the reconciliation in `account_accountant`.

The width of the elements was too small and the `overflow` value broke the layout on mobile view.
The point is to make the data at least readable on mobile, but this could be improved in the near future (eg. less data shown to user, displayed another way like a list-group, etc).

If barcode is installed, the buttons are half-hidden under the control-panel. This is fixed in this [Enterprise/#63271](https://github.com/odoo/enterprise/pull/63271).

task-3358275
Related to task-3326263

| Before | After |
|--------|--------|
| <img width="408" alt="Screenshot 2024-05-27 at 14 19 32" src="https://github.com/odoo/enterprise/assets/108661430/56ac88f0-22e4-498c-a5f2-ea9ef9316a80"> | <img width="407" alt="Screenshot 2024-05-27 at 14 31 49" src="https://github.com/odoo/enterprise/assets/108661430/be2bdb9a-c1de-4280-bf07-2d5257d74c3d"> |
| | <img width="408" alt="Screenshot 2024-05-27 at 14 32 00" src="https://github.com/odoo/enterprise/assets/108661430/fecb7a25-04c3-48d0-a555-67c2a4aa45d4"> |

Forward-Port-Of: odoo/enterprise#45256