When importing an invoice from a Factur-X format a payment reference is now read from correct field. From the same field where the original payment reference is exported. Description of the issue/feature this PR addresses: Current behavior before PR: When importing an invoice from a Factur-X format a payment reference was imported from wrong field related to a buyer order referenced document. But when the invoice is exported to Factur-X the original payment reference is exported to a spec

When importing an invoice from a Factur-X format a payment reference is now read from correct field. From the same field where the original payment reference is exported.

Description of the issue/feature this PR addresses:

Current behavior before PR:
When importing an invoice from a Factur-X format a payment reference was imported from wrong field related to a buyer order referenced document. But when the invoice is exported to Factur-X the original payment reference is exported to a specific field "PaymentReference" under "SupplyChainTradeTransaction" section.

Desired behavior after PR is merged:
The imported field is the same as exported.

I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/odoo#157811

`compare_list_price` wasn't updated when the user changed the website's currency. Now, it's converted to the website's currency. This change also makes the conversion of `price_extra` and `list_price` safer by fetching both the `from` currency and the `from` amount from the same record. opw-3845887 Forward-Port-Of: odoo/odoo#161428

`compare_list_price` wasn't updated when the user changed the website's currency. Now, it's converted to the website's currency.

This change also makes the conversion of `price_extra` and `list_price` safer by fetching both the `from` currency and the `from` amount from the same record.

opw-3845887

Forward-Port-Of: odoo/odoo#161428

Current behavior: If you change the expected duration of a workorder, then move the workorder to another workcenter, the expected duration is recomputed to but the finish date is not adapted. This leads to an inconsistency in the gannt view. Visually it will look like the duration expected has not changed because the date are still the same. Fix: To fix this we make sure that the finish date is recomputed when the expected duration is modified. This way both date and expected duration are c

Current behavior:
If you change the expected duration of a workorder, then move the workorder to another workcenter, the expected duration is recomputed to but the finish date is not adapted. This leads to an inconsistency in the gannt view. Visually it will look like the duration expected has not changed because the date are still the same.

Fix:
To fix this we make sure that the finish date is recomputed when the expected duration is modified. This way both date and expected duration are consistent.

Steps to reproduce:
- Create a product with a BOM
- The BOM should have at least 1 operations with a duration of 1 hour linked to a workcenter
- Create a manufacturing order for this product, confirm and plan it
- Go to the planning by workcenter
- Change the duration of the workorder by sliding its finishing date
- At this point if you click on it the duration should have changed
- Move the workorder to another workcenter
- The duration has been recomputed, but the finish date is not adapted (You can click on the workorder to see the duration has changed)

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

Forward-Port-Of: odoo/odoo#158141

## Issue: - when creating an accrual plan based on attendance,the duration is not computed accurately when allocating. - the computation is not correct if you select a different start date in the allocation without emptying the field "Allocation" ## Steps To Reproduce: - In the time-off app create an accrual plan: where employee accrue 1h for every hour worked based on attendance. - In the attendance app create a new attendance for 8 hours. - add a new allocation to Mitchell Admin with

## Issue:
- when creating an accrual plan based on attendance,the duration is not computed accurately when allocating.
- the computation is not correct if you select a different start date in the allocation without emptying the field "Allocation"

## Steps To Reproduce:
- In the time-off app create an accrual plan:  where employee accrue 1h for every hour worked based on attendance.
- In the attendance app create a new attendance for 8 hours.
- add a new allocation to Mitchell Admin with the plan you created.
- Change the date on the validity period, new allocation is 8h.
- change the date again and notice the Allocation not computed correctly.

## Solution:
- In `_onchange_date_from` when simulating how many days an accrual plan would give from a certian `date_from` we don't reset `number_of_days` to 0. reseting it to 0 fixes the issue.

opw-3793961

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

Forward-Port-Of: odoo/odoo#160696

-Same behaviour as [1] we should use slug(job) instead of job.id 1: a2c6ddf8158bf40f13b5c5a8b89deb3d2ae8af6b 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#160988 Forward-Port-Of: odoo/odoo#160622

-Same behaviour as [1] we should use slug(job) instead of job.id

1: a2c6ddf8158bf40f13b5c5a8b89deb3d2ae8af6b

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#160988
Forward-Port-Of: odoo/odoo#160622

Odoo implements its own lazy-loading mechanism for the biggest JS bundles that are loaded on the frontend. This mechanism allows the page to appear to the user very fast, at the downside of having some interactive elements (such as buttons) have no effect during the lazy loading. In general, this is not a problem since: - Standard links and buttons work, only those with custom effects (a modal, a custom JS behavior, etc) have no effect. - The full loading should not take long anyway. -

Odoo implements its own lazy-loading mechanism for the biggest JS
bundles that are loaded on the frontend. This mechanism allows the page
to appear to the user very fast, at the downside of having some
interactive elements (such as buttons) have no effect during the lazy
loading. In general, this is not a problem since:
- Standard links and buttons work, only those with custom effects (a
  modal, a custom JS behavior, etc) have no effect.
- The full loading should not take long anyway.
- After the pages have been visited, everything should be in cache.

However, in some cases (countries with poor internet connections), the
experience can be confusing. Without lazy loading, they would have a
page that appears as a blank white page for a few seconds. With our
custom lazy loading, they get the website very fast... but some buttons
appear buggy (no effect) for a few seconds.

The long term plan is to review our lazy loading:
- Should it be less delayed than it currently is? (at the time, this was
  the minimum delay that made Google give us good page scoring but it
  may not be as impacting as before)
- Should some of the lazy-loaded JS should actually not be?
- Should the assets be split differently?
- Could we be able to remove some code that weighs too much?
- ...?

Meanwhile, this commit improves the behavior this way: during lazy
loading, any click on a button is now ignored but a loading effect is
displayed. Once the JS is fully loaded, the click is then re-played on
the previously clicked button, hopefully triggering its effect. In any
case, this cannot be worse than what we have before... except for:

- **The reasonable risk we take merging this in stable (we considered
  merging in a more recent version but it is needed for some specific
  projects and many websites would benefit from this improvement).**

- Any custom code that added behavior on buttons to be available during
  lazy loading... will just wait for lazy loading with a loading effect
  too now. This should be a good compromise as, again, that lazy loading
  is cached and should not take too long anyway.

Note that this replaces the previous o_wait_lazy_js class behavior (it
has now no effect).

Overall:
- This should not impact (neither improve nor worsen) most websites that
  are currently experienced from good internet connections.
- This should be a big improvement for most websites that are currently
  experienced from bad internet connections.

Related to task-3770362

Forward-Port-Of: odoo/odoo#160223
Forward-Port-Of: odoo/odoo#158661

**Description of the issue/feature this PR addresses:** The logger show "Job done" before the flush. But if during the flush an error appear (sql constraint, validation error during computed field, ...), the log contain "Job done", but is not True. The time to compute the cron is not good because it doesn't contain the flush time (in some case can be very long). @Julien00859 @rco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-

**Description of the issue/feature this PR addresses:**
The logger show "Job done" before the flush. But if during the flush an error appear (sql constraint, validation error during computed field, ...), the log contain "Job done", but is not True.

The time to compute the cron is not good because it doesn't contain the flush time (in some case can be very long).

@Julien00859 @rco-odoo 


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

Forward-Port-Of: odoo/odoo#161204
Forward-Port-Of: odoo/odoo#160895

When editing the login page, most snippets are disabled by default and cannot be dropped because there is no place to drop them. However, if you enable the cookies bar, then all snippets are enabled even on the login page, because they can be dropped within the cookies bar. It then looks like a bug for the users who try to drop blocks on the main page and cannot. To avoid that, this commit also disables the snippets if the only spot available is within a cookies bar. opw-3829660 Forward-P

When editing the login page, most snippets are disabled by default and cannot be dropped because there is no place to drop them. However, if you enable the cookies bar, then all snippets are enabled even on the login page, because they can be dropped within the cookies bar. It then looks like a bug for the users who try to drop blocks on the main page and cannot.

To avoid that, this commit also disables the snippets if the only spot available is within a cookies bar.

opw-3829660

Forward-Port-Of: odoo/odoo#160880

After odoo/odoo#154035 users were unable to upgrade resolves https://github.com/odoo/odoo/issues/160816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161402 Forward-Port-Of: odoo/odoo#161274

After odoo/odoo#154035 users were unable to upgrade

resolves https://github.com/odoo/odoo/issues/160816



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

Forward-Port-Of: odoo/odoo#161402
Forward-Port-Of: odoo/odoo#161274

Before this PR, the chatbot script would hang when redirected to a page where the chatbot is not enabled. When such a scenario occurs, we should restore the chatbot's state to where it stopped, and the script should continue. This PR fixes this issue. Forward-Port-Of: odoo/odoo#161345 Forward-Port-Of: odoo/odoo#161121

Before this PR, the chatbot script would hang when redirected to a
page where the chatbot is not enabled.

When such a scenario occurs, we should restore the chatbot's state to
where it stopped, and the script should continue.

This PR fixes this issue.

Forward-Port-Of: odoo/odoo#161345
Forward-Port-Of: odoo/odoo#161121

## Description Add indexes affecting queries related to `account.analytic.line`. Based on heuristics like domains in `search`/`read_group` that are not really selective, or being an inverse of One2many. Some of these searches are on code-paths that are frequent, like creation of an SO. The goal is to reduce the number of Seq.Scan or non-selective Index Scan. ## Reference task-3724844 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-

## Description
Add indexes affecting queries related to `account.analytic.line`. Based on heuristics like domains in `search`/`read_group` that are not really selective, or being an inverse of One2many. Some of these searches are on code-paths that are frequent, like creation of an SO.
The goal is to reduce the number of Seq.Scan or non-selective Index Scan.

## Reference
task-3724844

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

Forward-Port-Of: odoo/odoo#160472

Description of the issue/feature this PR addresses: Create an invoice with analytic_distribution. Go to account.move.line, select the line with analytic_distribution, click on action 'Move account' validate --> Issue the analytic_distribution is not reversed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160981 Forward-Port-Of: odoo/odoo#159751

Description of the issue/feature this PR addresses:
Create an invoice with analytic_distribution.
Go to account.move.line, select the line with analytic_distribution, click on action 'Move account' validate
--> Issue the analytic_distribution is not reversed




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

Forward-Port-Of: odoo/odoo#160981
Forward-Port-Of: odoo/odoo#159751

[FIX] web_editor: make the drag towards the bottom in grid mode smoother Since commit [1], we can now drag and drop an image by dragging it directly, and not only by the move handle. Commit [2] allowed the image to be dragged from anywhere and not only from the top middle. In grid mode, in order for the column to stay well inside the grid when dragging, its computed position was originally bound horizontally, to the left and the right of the row. With commit [2], it is now also bound verti

[FIX] web_editor: make the drag towards the bottom in grid mode smoother

Since commit [1], we can now drag and drop an image by dragging it directly, and not only by the move handle. Commit [2] allowed the image to be dragged from anywhere and not only from the top middle.

In grid mode, in order for the column to stay well inside the grid when dragging, its computed position was originally bound horizontally, to the left and the right of the row. With commit [2], it is now also bound vertically, to the top and the bottom of the row.

While it makes sense for the top, because we need to take into account from where we dragged the image, it should not have been the case for the bottom, as we need to overflow in order to add new rows. This resulted in the drag towards the bottom becoming jumpy, because it locks on the bottom of the grid until a new row is added, when the mouse pointer is down enough.

This commit removes this bottom bound, in order for the drag towards the bottom to be smooth again.

Steps to reproduce:
- Drop the "Text-Image" snippet and toggle the grid mode.
- Drag a column towards the bottom in order to add new rows. 
=> It is not smooth: it locks on the bottom of the grid.

[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9

task-3601336

---
[FIX] web_editor: fix dragging a column from the bottom in a grid

Since commit [1], we can now drag and drop an image column by dragging it directly, and not only by the move handle. Commit [2] allowed the image to be dragged from anywhere and not only from the top middle. However, since commit [2], it is really difficult to drag a column downwards in a grid, if the drag started from the bottom move handle or near the bottom of the column if it contains an image, because we easily get out of the dropzone.

Indeed, since the positioning of the column now takes into account the mouse position on the column where the drag started, the mouse cursor is therefore located under the column (or almost under in the second case). This is why it gets out of the dropzone before a new row could be added. For the second case, new rows can be added, but only if the drag is slow enough, which is not convenient.

This commit bounds the vertical position of the mouse when dragging, in order for it to always be considered inside the column, so it cannot escape the dropzone anymore. A safety margin of one grid row is considered, to not escape when dragging rapidly.

Steps to reproduce:
- Drop enough snippets to have a scrollbar or select the "Sidebar"
  header template.
- Drop a "Text-Image" snippet
  - at the top of the page if the header was changed at the previous step, or
  - at a place where the top of the snippet can be hidden with a scroll.
- Toggle it to grid mode.
- Start dragging any column with the bottom move handle or drag the image column by clicking near the bottom of the column.
- Go over the grid dropzone if the move handle is used.
- Drag towards the bottom of the grid.
=> The mouse easily gets out of the dropzone, making it impossible to add new rows and drag further down the grid.

[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9

task-3601336

Forward-Port-Of: odoo/odoo#144427

Description of the issue/feature this PR addresses: In odoo V17 if a user is creating a holiday request for a time of type that requires no validation, the confirm button is visible during the creation process due to this line https://github.com/odoo/odoo/blob/2876b8300d1f9a740deb0faa02399df2426df402/addons/hr_holidays/views/hr_leave_views.xml#L248 in prior versions this was not the case https://github.com/odoo/odoo/blob/391a427620b6aec690481fe7c7d0b0326b95ee8c/addons/hr_holidays/views/hr

Description of the issue/feature this PR addresses:
In odoo V17 if a user is creating a holiday request for a time of type that requires no validation, the confirm button is visible during the creation process due to this line https://github.com/odoo/odoo/blob/2876b8300d1f9a740deb0faa02399df2426df402/addons/hr_holidays/views/hr_leave_views.xml#L248

in prior versions this was not the case

https://github.com/odoo/odoo/blob/391a427620b6aec690481fe7c7d0b0326b95ee8c/addons/hr_holidays/views/hr_leave_views.xml#L238


So due to this change in Odoo V17 the confirm button is visible to the user while creating (before saving) so if the user clicks on the confirm button the behavior is it will save the record then set its state to confirm then will call action validate (all in the create function) after the execution of the create is finished it will call `action_confirm` which in turn will raise the user error.

I added a check in the action confirm function to check if the time off requires no validation.
alternatively I can revert the changes and add the `id == False` in the condition for the `action_confirm` button action. 

Current behavior before PR:
A user error message is raised if the user clicks on the confirm button. see issue #160831 

Desired behavior after PR is merged:
No user error message that happens if the user clicks on the confirm button.


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

Forward-Port-Of: odoo/odoo#161186
Forward-Port-Of: odoo/odoo#160839

Steps to reproduce the bug: - Install e-commerce. - Open a product page in edit mode. - Click on the "product.description_ecommerce" field. - Bug: an infinite loop starts. The "selectionchange" event is triggered in an endless loop, causing various issues such as the page freezing after a while. This issue was introduced by this commit [1]. Since this other commit [2], when a selection itself is the main container of the editable area, we replace this selection to only include the

Steps to reproduce the bug:

- Install e-commerce.
- Open a product page in edit mode.
- Click on the "product.description_ecommerce" field.
- Bug: an infinite loop starts. The "selectionchange" event is triggered in an endless loop, causing various issues such as the page freezing after a while.

This issue was introduced by this commit [1].

Since this other commit [2], when a selection itself is the main
container of the editable area, we replace this selection to only
include the content of it. With commit [1], this has been modified to
take into account "oe_structure" and "[contenteditable]" elements. As
these elements can be empty, clicking on them would reselect them,
creating an endless loop since we'd never leave the condition that
replaces the selection.

[1]: https://github.com/odoo/odoo/commit/e93fa23c29421ffe8917d9650330585d6dad210f
[2]: https://github.com/odoo/odoo/commit/10c5a16cd44b8d8e54082df90166f2309dfa788d

task-3830033

Forward-Port-Of: odoo/odoo#160535

Add missing indexes on stock.move and mrp.workorder to speed up search_read on mrp.production. That's mostly useful at the opening of the Shop Floor app. This turns Seq scans into Index scan, leading to an overall speedup. ENT PR: https://github.com/odoo/enterprise/pull/59998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160349

Add missing indexes on stock.move and mrp.workorder to speed up search_read on mrp.production. That's mostly useful at the opening of the Shop Floor app. This turns Seq scans into Index scan, leading to an overall speedup.

ENT PR: https://github.com/odoo/enterprise/pull/59998

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

Forward-Port-Of: odoo/odoo#160349

Only delivery carriers that can communicate with the outside should be deactivated. Every time a database is neutralized, all delivery carriers are deactivated. In staging or test databases this should not be the case, only delivery carriers with an external connection, i.e. delivery carriers with an external provider should be deactivated. Delivery carriers with fixed price or based on rules should not be deactivated with every neutralization. This way Odoo can continue to operate with shipping

Only delivery carriers that can communicate with the outside should be deactivated. Every time a database is neutralized, all delivery carriers are deactivated. In staging or test databases this should not be the case, only delivery carriers with an external connection, i.e. delivery carriers with an external provider should be deactivated. Delivery carriers with fixed price or based on rules should not be deactivated with every neutralization. This way Odoo can continue to operate with shipping methods without prejudice to the users in neutralized databases.

@moduon @yajo @Shide MT-5612

Description of the issue/feature this PR addresses:

Current behavior before PR:

Deactivated every delivery carriers.

Desired behavior after PR is merged:

Deactivated only delivery carriers with external provider.


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

Forward-Port-Of: odoo/odoo#160443

### Steps to reproduce: - Go to Accounting > Accounting > Actions > Lock Dates - Set a Tax Return Lock Date to a date of the previous month - Create and confirm vendor Bill with a taxed line of positive price - Go to Accounting > Reporting > Audit Reports > Journal Report - Hover over the Vendor Bills and click on "journal items" - Add the optional vehicle field to the record - Select your expense line and try to add a vehicle #### > Invalid Operation "You cannot modify the taxes rel

### Steps to reproduce:

- Go to Accounting > Accounting > Actions > Lock Dates
- Set a Tax Return Lock Date to a date of the previous month
- Create and confirm vendor Bill with a taxed line of positive price
- Go to Accounting > Reporting > Audit Reports > Journal Report
- Hover over the Vendor Bills and click on "journal items"
- Add the optional vehicle field to the record
- Select your expense line and try to add a vehicle

#### > Invalid Operation "You cannot modify the taxes related to a posted journal item..."

### Cause of the issue:

Modifying the "vehicle_id" of the account move line will trigger a call of the `_sync_dynamic_line` method in order to modify other account move line linked to the same account move:
https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move.py#L2285-L2287 During the call of this write method, the account move line that we did not directly modified will not be excluded:
https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move_line.py#L1571 as `..._field_will_change(line, vals,"vehicule_id")` will be `True`. The error will therefore be raised two lines later because a 'tax_id' is present in vals as a 'tax_id' was set on our related account move line.

### Expected behaviour:

Since the 'tax_id' present in vals is the same as the one already set on our account move line, we are not modifying the taxes related to a posted journal item and we should not raise the error.

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

Forward-Port-Of: odoo/odoo#159919

This PR fixes an issue about the search panel content being cut in some accounting interfaces. This is due to the fact that the searchpanel with a specific class would get an arbitrary width value in px. To avoid this issue, we set a `w-auto` to the searchpanel, allowing it to adapt its width to its content. task-3560617 | saas-16.4 | saas-16.4-accounting-searchpanel-width-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/ac479776-76f1-47

This PR fixes an issue about the search panel content being cut in some accounting interfaces. This is due to the fact that the searchpanel with a specific class would get an arbitrary width value in px.

To avoid this issue, we set a `w-auto` to the searchpanel, allowing it to adapt its width to its content.

task-3560617

| saas-16.4 | saas-16.4-accounting-searchpanel-width-chgo |
|--------|--------|
| <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/ac479776-76f1-471b-b20b-927abf2fef2f"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/a683f0fd-16b1-49a5-9621-315288c6d186"> |

Forward-Port-Of: odoo/odoo#143803

See https://github.com/odoo/odoo/pull/151989#issuecomment-2041952639 The test test_tz_legacy will fail if the taget does not exist on the operating system. This is breaking in some versions of the tz-data package. Don't make this test fail if the target is missing. Forward-Port-Of: odoo/odoo#160868

See https://github.com/odoo/odoo/pull/151989#issuecomment-2041952639

The test test_tz_legacy will fail if the taget does not exist on the operating system. 
This is breaking in some versions of the tz-data package. 

Don't make this test fail if the target is missing.

Forward-Port-Of: odoo/odoo#160868

Previously, saving an order would fail with a trusted PoS config. This issue arose because other PoS configurations would not load, resulting in 'trusted_config_ids' being undefined in the config model. opw-3854554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161100

Previously, saving an order would fail with a trusted PoS config. This issue arose because other PoS configurations would not load, resulting in 'trusted_config_ids' being undefined in the config model.

opw-3854554

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

Forward-Port-Of: odoo/odoo#161100

Before ====== In E-invoice Value is pass as other values After ==== No RC value is pass to the E-invoice because not required to pass RC value. 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#161125

Before
======
In E-invoice Value is pass as other values

After
====
No RC value is pass to the E-invoice because not required to pass RC value.

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

Add support for the Malaysian Peppol PINT specialization, allowing to generate the related XML file. This also adds a few additional features that are in the specifications: - SST registration number, needed in the xml and on the invoice. - TTx registration number, needed on the invoice. Both numbers are optional, but if the business is registered in any of them they are required to display these on the invoices and they are required to enforce some rules. (cannot send taxes that are n

Add support for the Malaysian Peppol PINT specialization, allowing to generate the related XML file.

This also adds a few additional features that are in the specifications:

- SST registration number, needed in the xml and on the invoice.
- TTx registration number, needed on the invoice.

Both numbers are optional, but if the business is registered in any of them they are required to display these on the invoices and they are required to enforce some rules. (cannot send taxes that are not 0% "Out of scope" if not registered with SST, ..)

Task id # 3647922

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

Forward-Port-Of: odoo/odoo#159407

This module was introduced in saas-16.4. In that version the sale order report and portal template displayed both price_subtotal and price_total for each sale order line. 655d375af83dd49bbbd5f5818e319c3b0e9778c1 removed price_total. Because this module removes price_subtotal we end up with no line total at all on the default Brazilian quotation PDF and portal view (just 3 columns: description, quantity and unit price). Loosely inspired by l10n_cl [1], this commit changes our approach to t

This module was introduced in saas-16.4. In that version the sale order report and portal template displayed both price_subtotal and price_total for each sale order
line. 655d375af83dd49bbbd5f5818e319c3b0e9778c1 removed price_total.

Because this module removes price_subtotal we end up with no line total at all on the default Brazilian quotation PDF and portal view (just 3 columns: description, quantity and unit price).

Loosely inspired by l10n_cl [1], this commit changes our approach to turn the two places where we use price_subtotal into price_total. The aforementioned commit also changed the heading of this column from "Subtotal" to a more generic "Amount", so there's no inconsistency there. Although this is a bit of a mess, I can't think of a better solution.

[1] https://github.com/odoo/odoo/blob/655d375af83dd49bbbd5f5818e319c3b0e9778c1/addons/l10n_cl/views/report_invoice.xml#L173-L175

Forward-Port-Of: odoo/odoo#159794

Before this commit, when the user clicks on `Copy Previous` in the gantt view of `planning.slot`, a filter will be added to highlight the shifts added by the action executed. However, if the user clicks on `Auto Plan` to plan the open shifts automatically, the filter is disappeared and no shifts are highlighted as before. The reason is because we toggle the filter without checking if that filter is already there in the search view. This commit checks if the filter is already there before togg

Before this commit, when the user clicks on `Copy Previous` in the gantt view of `planning.slot`, a filter will be added to highlight the shifts added by the action executed. However, if the user clicks on `Auto Plan` to plan the open shifts automatically, the filter is disappeared and no shifts are highlighted as before. The reason is because we toggle the filter without checking if that filter is already there in the search view.

This commit checks if the filter is already there before toggle it. If yes, then we notify the model instead of toggling the facet in the search view.

runbot-55489
runbot-58209
runbot-56675
runbot-58149

Forward-Port-Of: odoo/enterprise#60341

The module `account_reports_tax_reminder` does not exist anymore, but is still in the .tx/config file, causing the sync script to fail. We remove the entry from the config file, so the script works again.

The module `account_reports_tax_reminder` does not exist anymore, but is still in the .tx/config file, causing the sync script to fail.

We remove the entry from the config file, so the script works again.

Purpose ======= Fix the unnecessary horizontal and vertical scrollbars appearing in the inspector when a document name is too long. Specifications ============== In the inspector, when the value of the fields of type model (like the Journal Entry or Signature fields) is too long, the value is styled so that its width takes the max-width. However the field max-width is incorrectly computed. It is missing the table-sm class horizontal padding. The field is thus too big to fit in the ins

Purpose
=======
Fix the unnecessary horizontal and vertical scrollbars appearing in the
inspector when a document name is too long.

Specifications
==============
In the inspector, when the value of the fields of type model (like the Journal Entry
or Signature fields) is too long, the value is styled so that its width takes the max-width.
However the field max-width is incorrectly computed. It is missing the table-sm class
horizontal padding. The field is thus too big to fit in the inspector and scrollbars appear.

Taking into account the table-sm paddings while computing the field value max-width.
As the field label left padding is set to 0, the table-sm padding is multiplied by 3
(right padding of label, left and right padding of value).
Also adding the "overflow-hidden" class on the inspector so that scrollbars never appear.

Task-3829716

Forward-Port-Of: odoo/enterprise#60430
Forward-Port-Of: odoo/enterprise#59652

At the moment, the Unaffected Earnings and Current Year Earnings lines are expressed using domains. We change them to use cross-report formulas to the Profit & Loss. This ensures that the Balance Sheet is balanced. taskid: 3060790 Forward-Port-Of: odoo/enterprise#59132

At the moment, the Unaffected Earnings and Current Year Earnings lines are expressed using domains. We change them to use cross-report formulas to the Profit & Loss.

This ensures that the Balance Sheet is balanced.

taskid: 3060790

Forward-Port-Of: odoo/enterprise#59132

This commit adds various changes to the codebase to fix issues with the leaderboard system, issues such as the leaderboard being displayed even though the current employee has no billable time rate, billing rate target not having the fa-building icon next to it, theorical working hours being incorrect, visual issues and many more. task-3570302 Forward-Port-Of: odoo/enterprise#60290 Forward-Port-Of: odoo/enterprise#50307

This commit adds various changes to the codebase to fix issues with the leaderboard system, issues such as the leaderboard being displayed even though the current employee has no billable time rate, billing rate target not having the fa-building icon next to it, theorical working hours being incorrect, visual issues and many more.

task-3570302

Forward-Port-Of: odoo/enterprise#60290
Forward-Port-Of: odoo/enterprise#50307

In My Timesheets grid view if you have more than 26 lines, the last ones will display a border only Tweaked some conditions in the grid_timer_button_cell.xml Task-3670682 Forward-Port-Of: odoo/enterprise#60277 Forward-Port-Of: odoo/enterprise#53749

In My Timesheets grid view if you have more than 26 lines, the last ones will display a border only 
Tweaked some conditions in the grid_timer_button_cell.xml

Task-3670682

Forward-Port-Of: odoo/enterprise#60277
Forward-Port-Of: odoo/enterprise#53749

This commit fixes an issue where readonly users are able to access and restore an old version of an article via the history dialog but it didn't affect the DB as no write could be done by this user. The change was only visible and functionnally didn't change the body field. Now when a user accesses to an article where he can only read, the history dialog button is hidden. task-3836201 Forward-Port-Of: odoo/enterprise#59609

This commit fixes an issue where readonly users are able to access and restore
an old version of an article via the history dialog but it didn't affect the DB
as no write could be done by this user.
The change was only visible and functionnally didn't change the body field.

Now when a user accesses to an article where he can only read, the history
dialog button is hidden.

task-3836201

Forward-Port-Of: odoo/enterprise#59609

The tax closing in France did an override of `_postprocess_vat_closing_entry_results` to be able to compute and compensate (by creating a move) difference from rounding taxes. As this functionality starts to be needed in other countries, we extract that method to `account_generic_tax_report` and made it generic. task-3691312 Forward-Port-Of: odoo/enterprise#59738 Forward-Port-Of: odoo/enterprise#56510

The tax closing in France did an override of `_postprocess_vat_closing_entry_results` to be able to compute and compensate (by creating a move) difference from rounding taxes.

As this functionality starts to be needed in other countries, we extract that method to `account_generic_tax_report` and made it generic.

task-3691312

Forward-Port-Of: odoo/enterprise#59738
Forward-Port-Of: odoo/enterprise#56510

The declining method, even though its name doesn't tell it explicitly, implies a comparison with the output of a linear depreciation of the depreciable value on the remaining duration of the asset's lifecycle. task-3734735 Forward-Port-Of: odoo/enterprise#60352 Forward-Port-Of: odoo/enterprise#56601

The declining method, even though its name doesn't tell it explicitly,
implies a comparison with the output of a linear depreciation of the
depreciable value on the remaining duration of the asset's lifecycle.

task-3734735

Forward-Port-Of: odoo/enterprise#60352
Forward-Port-Of: odoo/enterprise#56601

Basically, the following fields are only defined in private employee, and not on public employee. Thus we need to put group on them Forward-Port-Of: odoo/enterprise#60396

Basically, the following fields are only defined in private employee, and not on public employee. Thus we need to put group on them

Forward-Port-Of: odoo/enterprise#60396

Add missing indexes on quality_check. This speeds up search_read on mrp.production when the quality/quality_mrp modules are installed. It's mostly useful at the opening of the Shop Floor App to turn Seq Scans into Index Scans. COM PR: https://github.com/odoo/odoo/pull/160349 Forward-Port-Of: odoo/enterprise#59998

Add missing indexes on quality_check. This speeds up search_read on mrp.production when the quality/quality_mrp modules are installed. It's mostly useful at the opening of the Shop Floor App to turn Seq Scans into Index Scans.

COM PR: https://github.com/odoo/odoo/pull/160349

Forward-Port-Of: odoo/enterprise#59998

Forward-Port-Of: odoo/enterprise#60316 Forward-Port-Of: odoo/enterprise#60166

Forward-Port-Of: odoo/enterprise#60316
Forward-Port-Of: odoo/enterprise#60166

In this https://github.com/odoo/enterprise/commit/76caf5f5675f97128b88fbcffedaf1e85da516d5, it was decided to remove the report. But we received a lot of feedbacks about users missing the report, especially from anglo-saxon countries, where this report is often used in Audit processes to report on the differences between the Accounting and Bank reported amounts on bank accounts. In this pr we decided to put it back and improve it. What has been improved: - The display of the report is now co

In this https://github.com/odoo/enterprise/commit/76caf5f5675f97128b88fbcffedaf1e85da516d5, it was decided to remove the report. But we received a lot of feedbacks about users missing the report, especially from anglo-saxon countries, where this report is often used in Audit processes to report on the differences between the Accounting and Bank reported amounts on bank accounts.

In this pr we decided to put it back and improve it. What has been improved:
- The display of the report is now consistent with the different reports
- Use of custom engine
- New sections added
- Rework of the warnings

task: 3756179

Forward-Port-Of: odoo/enterprise#60169
Forward-Port-Of: odoo/enterprise#58640

This commit adds some of the missing information in the commercial invoice for international shipments in `delivery_ups` and `delivery_ups_rest` modules. opw-3668875 Forward-Port-Of: odoo/enterprise#60043 Forward-Port-Of: odoo/enterprise#58861

This commit adds some of the missing information in the commercial invoice for international shipments in `delivery_ups` and `delivery_ups_rest` modules.

opw-3668875

Forward-Port-Of: odoo/enterprise#60043
Forward-Port-Of: odoo/enterprise#58861

The module uses the field `stock_picking.carrier_tracking_url`, defined in module `stock_delivery`, which is not listed as dependency. Although it is auto-installed, if it gets uninstalled before `whatsapp_delivery` is installed, it will trigger an error as the field is missing. Steps to reproduce: - On a fresh 17.0 db, install `stock` and `delivery`, `stock_delivery` will be auto-installed. - Uninstall `stock_delivery`. - Install `whatsapp_delivery` or just `whatsapp`. Forward-Port-

The module uses the field `stock_picking.carrier_tracking_url`, defined in module `stock_delivery`, which is not listed as dependency.

Although it is auto-installed, if it gets uninstalled before `whatsapp_delivery` is installed, it will trigger an error as the field is missing.

Steps to reproduce:

- On a fresh 17.0 db, install `stock` and `delivery`, `stock_delivery` will be auto-installed.
- Uninstall `stock_delivery`.
- Install `whatsapp_delivery` or just `whatsapp`.

Forward-Port-Of: odoo/enterprise#60322

With this commit on approval request's form view: * You have the same padding for dates * The primary button is "attached documents" if you don't linked a document or "confirm","approve" if you have already send a document. task : 3724860 Forward-Port-Of: odoo/enterprise#59988 Forward-Port-Of: odoo/enterprise#58863

With this commit on approval request's form view:
    * You have the same padding for dates
    * The primary button is "attached documents" if you don't linked a
document or "confirm","approve" if you have already send a document.

task : 3724860

Forward-Port-Of: odoo/enterprise#59988
Forward-Port-Of: odoo/enterprise#58863

The tax brackets have been updated since 01-01-2024 https://impotsdirects.public.lu/dam-assets/fr/baremes/baremes-impot-20240101-fr.pdf https://impotsdirects.public.lu/fr/baremes.html#Ex Add new parameter values to reflect the change. task-3748852 Forward-Port-Of: odoo/enterprise#58163

The tax brackets have been updated since 01-01-2024

https://impotsdirects.public.lu/dam-assets/fr/baremes/baremes-impot-20240101-fr.pdf https://impotsdirects.public.lu/fr/baremes.html#Ex

Add new parameter values to reflect the change.

task-3748852

Forward-Port-Of: odoo/enterprise#58163

Fix the document name which was renamed to "(remaining pages.pdf" when exiting the split tool by gathering in one page. Missing the initial name and missing the closing parenthesis. The document name by gathering in one page is now structured as: "name (remaining pages).pdf" Technical point: Using sprintf so that users will have an entry with %s in the translation file allowing them to choose the file name position. related: https://github.com/odoo/enterprise/pull/40454 Task-384

Fix the document name which was renamed to "(remaining pages.pdf"
when exiting the split tool by gathering in one page.
Missing the initial name and missing the closing parenthesis.

The document name by gathering in one page is now structured as:
"name (remaining pages).pdf"

Technical point:
Using sprintf so that users will have an entry with %s in the
translation file allowing them to choose the file name position.

related: https://github.com/odoo/enterprise/pull/40454

Task-3847395

Forward-Port-Of: odoo/enterprise#60414
Forward-Port-Of: odoo/enterprise#59979

4755b82fa40df50362e72ccc3e08f6ce5383dde3 changed the portal template used for subscriptions by overriding `_get_name_portal_content_view()`. Because of this, the override in `l10n_br_sales` no longer applies and we end up with the standard subscription portal view instead of the customized one for Brazil. Although not very nice, the only way around it I could think of was to create this new module so we can override again with a new portal template that inherits from sale_subscription.subscr

4755b82fa40df50362e72ccc3e08f6ce5383dde3 changed the portal template used for subscriptions by overriding
`_get_name_portal_content_view()`. Because of this, the override in `l10n_br_sales` no longer applies and we end up with the standard subscription portal view instead of the customized one for Brazil.

Although not very nice, the only way around it I could think of was to create this new module so we can override again with a new portal template that inherits from sale_subscription.subscription_portal_content.

Forward-Port-Of: odoo/enterprise#59703

Before when we create an expense report paid by company with multiple expenses of different dates then we posted the expense report. The journal entries had all the same date. Now journal entries will match the date of the expense when it is an expense paid by company. Signed, Logan Staelens lost@odoo.com https://github.com/lost-odoo Forward-Port-Of: odoo/odoo#160990 Forward-Port-Of: odoo/odoo#159083

Before when we create an expense report paid by company with multiple expenses of different dates then we posted the expense report. The journal entries had all the same date.

Now journal entries will match the date of the expense when it is an expense paid by company.

Signed,

Logan Staelens lost@odoo.com https://github.com/lost-odoo

Forward-Port-Of: odoo/odoo#160990
Forward-Port-Of: odoo/odoo#159083

This pr will add an id on a div to be able to do a xpath on it. task: 3756179 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160725 Forward-Port-Of: odoo/odoo#157648

This pr will add an id on a div to be able to do a xpath on it.

task: 3756179

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

Forward-Port-Of: odoo/odoo#160725
Forward-Port-Of: odoo/odoo#157648

Nested gettexts aren't exported. This commit solves the problem by moving the inner gettext outside of the arguments of the first gettext. Forward-Port-Of: odoo/odoo#150303 Forward-Port-Of: odoo/odoo#149921

Nested gettexts aren't exported. This commit solves the problem by moving the inner gettext outside of the arguments of the first gettext.

Forward-Port-Of: odoo/odoo#150303
Forward-Port-Of: odoo/odoo#149921

Currently, there is an access right problem concerning timesheet. The module mrp gives write access to portal user on analytic line, but it is not something we want for the project app. step to reproduce: - install hr_timesheet on a saas-16.3 db - go to project app, open office design - select any task, and add a subtask to it - go the the view form of the subtask - create a new timesheet for this subtask - go back to the view form of the parent task a button 'subtask timesheet' is now

Currently, there is an access right problem concerning timesheet. The module mrp gives write access to portal user on analytic line, but it is not something we want for the project app.

step to reproduce:
- install hr_timesheet on a saas-16.3 db
- go to project app, open office design
- select any task, and add a subtask to it
- go the the view form of the subtask
- create a new timesheet for this subtask
- go back to the view form of the parent task a button 'subtask timesheet' is now visible
- share the project in edit mode with a portal user
- connect with that portal user
- open the office design project
- go to the view form of the parent task and click on the button
- the user is redirected to a view tree with the timesheet of the subtask
this view tree is editable

Source of the problem:
in the mrp module, the access rights of the analytic line is overwritten to give write access to it to portal user.
Soluce:
We have to make the view in readonly mode for timesheet when the connected user is a portal one. Unfortunately, it is not 100% possible because setting the field to readonly still gives the user the opportunity to click on those fields (which triggers access errors). So we have to create new views and specifically open those views when the user is a portal one.

affected version: saas-16.3 - master
task - 3751315

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#160959
Forward-Port-Of: odoo/odoo#155768

Previously, if a product had an attribute with two values and different prices were set for each product variant in a pricelist, both variants would incorrectly display the same price in the Point of Sale. This commit corrects the pricelist computation to accurately reflect the distinct prices of each product variant. opw-3854957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160973

Previously, if a product had an attribute with two values and different prices were set for each product variant in a pricelist, both variants would incorrectly display the same price in the Point of Sale. This commit corrects the pricelist computation to accurately reflect the distinct prices of each product variant.

opw-3854957

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

Forward-Port-Of: odoo/odoo#160973

Steps to reproduce: - Open the 'project.milestone' form view. Issue: - Excessive space exists between quantity and unit of measure in the 'project.milestone' form view, impacting the layout. Solution: - Reduce the space between elements to improve the layout and enhance the user experience. task: 3549267 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 t

Steps to reproduce:
- Open the 'project.milestone' form view.

Issue:
- Excessive space exists between quantity and unit of measure in the 'project.milestone' form view, impacting the layout.

Solution:
- Reduce the space between elements to improve the layout and enhance the user experience.

task: 3549267

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