Forward-Port-Of: odoo/odoo#140520 Forward-Port-Of: odoo/odoo#140440

Forward-Port-Of: odoo/odoo#140520
Forward-Port-Of: odoo/odoo#140440

A "quantity_done" removal was missed in the MO Overview report, which made it so the report would throw an error when opened for a done MO. Also replace "Reserved" with "Quantity" in the overview so that it is more consistent with pickings + is more intuitive since it is currently confusing that when the qty produced is updated, then it appears that the qty reserved changes (rather than a qty being done) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/

A "quantity_done" removal was missed in the MO Overview report, which made it so the report would throw an error when opened for a done MO.

Also replace "Reserved" with "Quantity" in the overview so that it is more consistent with pickings + is more intuitive since it is currently confusing that when the qty produced is updated, then it appears that the qty reserved changes (rather than a qty being done)




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

Forward-Port-Of: odoo/odoo#140246

…sage formatting With https://github.com/odoo/odoo/pull/139311, we broke the formatting of errors. We need to handle two formats: - one for the raised Error, likely formatted with \n - one for the chatter, likely formatted with html ### Before the fix  ### After the fix  ![image](https://github.com/od

…sage formatting

With https://github.com/odoo/odoo/pull/139311, we broke the formatting of errors. We need to handle two formats:
- one for the raised Error, likely formatted with \n
- one for the chatter, likely formatted with html

### Before the fix
![image](https://github.com/odoo/odoo/assets/107402834/d6317a85-db6e-41ec-8c8a-4697979f44c4)

### After the fix
![image](https://github.com/odoo/odoo/assets/107402834/e74c99ce-5243-4ac7-9430-a754430ef68b)
![image](https://github.com/odoo/odoo/assets/107402834/d3d680e2-be69-4af3-a69a-9061919a9b5d)

Forward-Port-Of: odoo/odoo#139812

Improved UX and removing unused CSS rule for org chart --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140238

Improved UX and removing unused CSS rule for org chart



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

Forward-Port-Of: odoo/odoo#140238

[FIX] website: prevent circular dependency of duplicated fields Steps to reproduce the bug: - Drop a "Form" snippet on the website. - Add three fields and rename them by "a", "b" and "b". - Change the conditional visibility of the first "b" and make it depend on "a". - Change the conditional visibility of "a" and make it depend on "b". - Save. -> Traceback "Maximum call stack exceeded" appears. A field with a conditional visibility is visible if at at least one field with the dep

[FIX] website: prevent circular dependency of duplicated fields

Steps to reproduce the bug:
- Drop a "Form" snippet on the website.
- Add three fields and rename them by "a", "b" and "b".
- Change the conditional visibility of the first "b" and make it depend
on "a".
- Change the conditional visibility of "a" and make it depend on "b".
- Save.

-> Traceback "Maximum call stack exceeded" appears.

A field with a conditional visibility is visible if at at least one
field with the dependency name is visible. The problem is that in our
case, it exists a circular dependency between "a" and one of the "b"
leading to an infinite loop during this check. Before this commit all
the fields of the form were checked and all the labels of the fields
that do not create a circular dependency were proposed in the file
visibility selector. The problem is that in our case, one of the "b"
field does not create a circular dependency while the other does. To
solve the problem, the `_recursiveFindCircular()` function has been
adapted in order to not propose a label that would create a circular
dependency in the file visibility selector.

task-3291044

-----------------------------------------------------------------------------------------------------------------------------------------------------------

[FIX] website: prevent circular dependency of renamed fields

Steps to reproduce the bug:
- Drop a "Form" snippet on the website.
- Change the "Label" of the first field (and put it to "test" for
example).
- Select the last field and change its visibility so that it depends on
the first field.
- Change the "Label" of the selected field and put it to the same than
the first one ("test").
- Save.

-> Traceback "Maximum call stack exceeded" appears.

At the end of the procedure, the last field visibility depends on itself
and a circular visibility dependency is created. To solve the problem,
this commit checks that the renamed field does not bring a circular
dependency while updating the dependencies. If it is the case, the
problematic dependency is deleted.
To resolve this bug, the `visitedFields` set has been introduced. Its
goal is to register the already visited fields to not enter an infinite
check loop. Let's take an example to illustrate this: Imagine there is a
form of type A->B->C->D. In this form, the field "A" depends on "B" that
depends on "C" that depends on "D". Imagine you rename "D" by "B". You
now have A->B->C->B. The system will check that the renamed field does
not create a circular dependency. To do so, it will apply
`_recursiveFindCircular` with "A" as the `targetFieldEl` and "B" as the
`dependentFieldEl`. Because there is a circular dependency between "C"
and "B", the system would enter in an infinite loop. Note that we do not
notify the system if such indirect circular dependency has been found as
it will be detected as a direct circular dependency  while the system
will apply `_recursiveFindCircular` with `C` as the `targetFieldEl`.

task-3291044

-----------------------------------------------------------------------------------------------------------------------------------------------------------

[FIX] website: re-render the visibility selector on field label change

Steps to reproduce the bug:
- Add a form on the website.
- Add two fields on the form ("A" and "B").
- Change the conditional visibility of "B" and put it to "Visible only
if".
- Change the label of "B" and set it to "A".
- Try to change the dependent field.

-> "A" is still on the list of the eligible dependent fields. It should
not be the case as setting this field as a dependent field would create
a circular dependency.

To solve the problem, the file visibility selector is rerendered after
modifying a field label. Because of the `_findCircular()` check at the
rerendering, the problematic field will not be displayed in the list of
of the eligible dependent fields.

task-3291044

Forward-Port-Of: odoo/odoo#140635
Forward-Port-Of: odoo/odoo#133585

From the backend manufacturing order view, it was no longer possible to specify batches/serial numbers for by-products. Now it is. 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#140446

From the backend manufacturing order view, it was no longer possible to specify batches/serial numbers for by-products. Now it is.

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

This follows [commit 1], which introduced a way to separately reorder columns on mobile and desktop. This commit replaces the custom mobile order classes with the Bootstrap `.order-x` classes. It also ensures those orders are not used for mass mailing in case the editor composes their email on a small window. The reorder would indeed not have any effect for the end users in such a case. [commit 1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba task-3576046

This follows [commit 1], which introduced a way to separately reorder columns on mobile and desktop.
This commit replaces the custom mobile order classes with the Bootstrap `.order-x` classes.
It also ensures those orders are not used for mass mailing in case the editor composes their email on a small window. The reorder would indeed not have any effect for the end users in such a case.

[commit 1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba

task-3576046

Forward-Port-Of: odoo/odoo#140362

The MacroEngine has a stop function that allows to completely disable it. Before this commit, it correctly disconnected the "main" mutation observer, but it didn't disconnect the mutation observer for iframes. In web_tour tests, we mock the MacroEngine to stop it at the end of tests, but this didn't stop the iframe mutation observer. This had an highly undesirable side-effect in tests: the qunit suite stopped during mass_mailing tests, because the iframe mutation observer detected a

The MacroEngine has a stop function that allows to completely
disable it. Before this commit, it correctly disconnected the
"main" mutation observer, but it didn't disconnect the mutation
observer for iframes.

In web_tour tests, we mock the MacroEngine to stop it at the end
of tests, but this didn't stop the iframe mutation observer.

This had an highly undesirable side-effect in tests: the qunit
suite stopped during mass_mailing tests, because the iframe
mutation observer detected a change which produced the log of
"test successful", which ended the whole suite. Some tests were
thus never run anymore (fortunately, we're only talking about a
few qunit modules).

Forward-Port-Of: odoo/odoo#141143

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

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

Befre this commit: timesheets are not being generated when validating time off After this commit: leave type form: in the absence of a company, we display the 'generate timesheets' boolean (in debug mode) and hide the project/task fields When generating timesheets from leave validation, we refer to the project/task set in the company of the employee if no company is set in the leave type Forward-Port-Of: odoo/odoo#140383

Befre this commit:
timesheets are not being generated when validating time off

After this commit:
leave type form: in the absence of a company, we display the 'generate timesheets' boolean (in debug mode) and hide the project/task fields

When generating timesheets from leave validation, we refer to the project/task set in the company of the employee if no company is set in the leave type

Forward-Port-Of: odoo/odoo#140383

When generating serial numbers or importing them, the old lines are still present and the quantity done gets raised by the quantity of the added lines. This forces the user to manually remove each old line one by one. This ensures that old lines are removed by the amount of newly created lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140618

When generating serial numbers or importing them, the old lines are still present and the quantity done gets raised by the quantity of the added lines. This forces the user to manually remove each old line one by one.

This ensures that old lines are removed by the amount of newly created lines.


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

Forward-Port-Of: odoo/odoo#140618

Prior to this commit, the patched setup functions of Order did not match the original signature. Forward-Port-Of: odoo/odoo#140893

Prior to this commit, the patched setup functions of Order did not match the original signature.

Forward-Port-Of: odoo/odoo#140893

Steps: - Install Field Service - Open the Field Service module - Click on the configuration - Go to the Worksheet Template - Now go to the kanban view - In view, Click on dropdown menu of any card Issue: - In kanban view, when we are viewing in dropdown menu colors are not correctly centered. Fix: - Added in kanban color picker mb-0 & ms-3 for margin space from bottom & left. Task-3508241 Forward-Port-Of: odoo/odoo#140807 Forward-Port-Of: odoo/odoo#135644

Steps:
- Install Field Service
- Open the Field Service module
- Click on the configuration
- Go to the Worksheet Template
- Now go to the kanban view
- In view, Click on dropdown menu of any card

Issue:
- In kanban view, when we are viewing in dropdown menu colors are not correctly centered.

Fix:
- Added in kanban color picker mb-0 & ms-3 for margin space from bottom & left.

Task-3508241

Forward-Port-Of: odoo/odoo#140807
Forward-Port-Of: odoo/odoo#135644

When we're exiting the import view, we need to have ids of the imported records to confirm that the import was successful and to filter on import records if needed. This commit adds an optional resIds parameter. task-3549609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140969 Forward-Port-Of: odoo/odoo#138364

When we're exiting the import view, we need to have ids of the imported records
to confirm that the import was successful and to filter on import records if
needed.
This commit adds an optional resIds parameter.

task-3549609

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

Forward-Port-Of: odoo/odoo#140969
Forward-Port-Of: odoo/odoo#138364

- It is necessary to extend the BaseImportModel to properly update `name_create_enabled_fields` in importOptions, instead of doing it in the import action. When the import is executed, the options are retrieved from the model and the `name_create_enabled_fields` thus remains empty, preventing a smooth import. - `this.current === "imported"` is no longer relevant for the import, so we need another solution to check the import state. task-3549609 Forward-Port-Of: odoo/enterprise#50141 Forwar

- It is necessary to extend the BaseImportModel to properly update `name_create_enabled_fields` in importOptions, instead of doing it in the import action.
When the import is executed, the options are retrieved from the model and the `name_create_enabled_fields` thus remains empty, preventing a smooth import.
- `this.current === "imported"` is no longer relevant for the import, so we need another solution to check the import state.

task-3549609

Forward-Port-Of: odoo/enterprise#50141
Forward-Port-Of: odoo/enterprise#48786

Before this commit, during the "Share you availabilities" action, when you select a time-window, the trash can overlay which suggests the time-window deletion was not shown. After this commit, the trash can overlay is back suggesting this deletion. Task-id: 3570053 Forward-Port-Of: odoo/enterprise#49570

Before this commit, during the "Share you availabilities" action, when you select a time-window, the trash can overlay which suggests the time-window deletion was not shown. After this commit, the trash can overlay is back suggesting this deletion.

Task-id: 3570053

Forward-Port-Of: odoo/enterprise#49570

**Before this PR:** When a user tries to post a new post with demo data of LinkedIn, the chatter is also logged twice. **Reason:** The state is updated twice (in the _post_linkedin and _post_demo methods) and due to that, the _check_post_completion method is called twice. We have solved this issue by removing the state update in the _post_linkedin method. **After this PR:** The Chatter will be only logged once. **Task**-3459739 Forward-Port-Of: odoo/enterprise#49047

**Before this PR:**
When a user tries to post a new post with demo data of LinkedIn, the chatter is also logged twice.

**Reason:**
The state is updated twice (in the _post_linkedin and _post_demo methods) and due to that, the _check_post_completion method is called twice. We have solved this issue by removing the state update in the _post_linkedin method.

**After this PR:**
The Chatter will be only logged once.

**Task**-3459739

Forward-Port-Of: odoo/enterprise#49047

Steps: - Open Field service - Select All task - Create task from kanban view - The partner_id field is missing and - Task isn't being created in the selected stage Issue: - When trying to create a task from the Kanban view using quick create, the 'partner_id' field is missing in the Kanban box - In quickcreate the task isn't being created in the selected stage Cause: - In the QuickCreate form view, replace the project_id field with regard to the raised issues Fix: - The partner

Steps:
- Open Field service
- Select All task
- Create task from kanban view
- The partner_id field is missing and
- Task isn't being created in the selected stage

Issue:
- When trying to create a task from the Kanban view using quick create, the 'partner_id' field is missing in the Kanban box
- In quickcreate the task isn't being created in the selected stage

Cause:
- In the QuickCreate form view, replace the project_id field with regard to the raised issues

Fix:
- The partner_id field is already mentioned in the parent view, but project_id replaced that field in this view. After removing project_id, the parent view will be restored, and the partner_id will be visible

- Before that the project_id is replaced from form view, it means we skip that field from the form view,it will not be considered as the project_id. But, we need the project_id for setting the default_stage_id in the Kanban view, But We don't need it to be visible in the form view, That's why project_id is invisible.

task-3522178

Forward-Port-Of: odoo/enterprise#48653

To reproduce the issue: 1) On a Spanish company, create a customer invoice, so that: - it has a line at 100, and another negative one at -42. - it uses the default Spanish sales tax of 21% on both lines - in is made on a non-Spanish European partner - it defines a value in mod 349 type; E, for example => the total of the invoice is hence 70.18€ 2) Post the invoice 3) Open mod 349 for the period corresponding to the invoice date. ===> The invoice is report

To reproduce the issue:

1) On a Spanish company, create a customer invoice, so that:
    - it has a line at 100, and another negative one at -42.
    - it uses the default Spanish sales tax of 21% on both lines
    - in is made on a non-Spanish European partner
    - it defines a value in mod 349 type; E, for example
    => the total of the invoice is hence 70.18€

2) Post the invoice

3) Open mod 349 for the period corresponding to the invoice date.

    ===> The invoice is reported with an amount of 112.18€, which is wrong.

This happens because the domains of the report line include lines that have debit>0. In our example, two lines are debit:
    - 70.18, on the receivable account
    - 42, corresponding to the negative line

For these lines, we want to use the total of the invoices/refunds, so instead of just counting on selecting one side of the move (and ignoring the case of the negative lines), we should consider the payable/receivable lines only.

OPW 3559094

Forward-Port-Of: odoo/enterprise#49975
Forward-Port-Of: odoo/enterprise#49622

With https://github.com/odoo/odoo/pull/139311, we broke the formatting of errors. We need to handle two formats: - one for the raised Error, likely formatted with \n - one for the chatter, likely formatted with html Forward-Port-Of: odoo/enterprise#49614

With https://github.com/odoo/odoo/pull/139311, we broke the formatting of errors. We need to handle two formats:
- one for the raised Error, likely formatted with \n
- one for the chatter, likely formatted with html

Forward-Port-Of: odoo/enterprise#49614

This commit removes call to cleanDomFromBootstrap as it is removed in community. task id: 3439226 backport of https://github.com/odoo/enterprise/pull/49604 Forward-Port-Of: odoo/enterprise#49812

This commit removes call to cleanDomFromBootstrap as it is removed in community.

task id: 3439226

backport of https://github.com/odoo/enterprise/pull/49604

Forward-Port-Of: odoo/enterprise#49812