This fix removes a tax report check that had been unintentionally brought back after it was previously removed. It helps keep accounting report behavior aligned with the intended workflow and avoids unnecessary blocking during tax return handling.

This check got removed by https://github.com/odoo/enterprise/commit/1f66777dc25e55f53338efb7314bb8de69c995a0 , then mistakenly reintroduced by https://github.com/odoo/enterprise/commit/6d53412ed12082d9bd55032def36892401d4b262

This commit adds a new button to the dialog used to connect the IoT Box to a Wi-Fi network, to display/hide the password. Forward-Port-Of: odoo/odoo#207285

This commit adds a new button to the dialog used to connect the IoT Box to a Wi-Fi network, to display/hide the password.

Forward-Port-Of: odoo/odoo#207285

When uninstalling Odoo with the NSIS uninstaller, whole install dir is removed when ngingx is not found which is not the desired behavior. While at it, update the NSIS version. Forward-Port-Of: odoo/odoo#207873 Forward-Port-Of: odoo/odoo#207464

When uninstalling Odoo with the NSIS uninstaller, whole install dir is removed when ngingx is not found which is not the desired behavior.

While at it, update the NSIS version.

Forward-Port-Of: odoo/odoo#207873
Forward-Port-Of: odoo/odoo#207464

Thanks to [1], we can now fix the website page properties tour ensuring that the necessary elements are visible on the page. [1]: https://github.com/odoo/odoo/commit/4e25c13c918382afb34013a6dd30aac4a0ce4e84 runbot-106391 Co-authored-by: Pierre Pulinckx Forward-Port-Of: odoo/odoo#207740

Thanks to [1], we can now fix the website page properties tour ensuring
that the necessary elements are visible on the page.

[1]: https://github.com/odoo/odoo/commit/4e25c13c918382afb34013a6dd30aac4a0ce4e84

runbot-106391

Co-authored-by: Pierre Pulinckx

Forward-Port-Of: odoo/odoo#207740

**Current behavior:** With anglo saxon accounting and real-time valuation, purchasing a kit product with a BoM that has components whose costs add up to the exact price of the kit product and that is invoiced on ordered qty and has avg costing, then billing before receiving will prevent the reception from being validate-able. **Expected behavior:** Can validate **Steps to reproduce:** 1. Create a kit product with avg costing, invoiced on ordered qty, and a BoM with 2 components tha

**Current behavior:**
With anglo saxon accounting and real-time valuation, purchasing
a kit product with a BoM that has components whose costs add up
to the exact price of the kit product and that is invoiced on
ordered qty and has avg costing, then billing before receiving
will prevent the reception from being validate-able.

**Expected behavior:**
Can validate

**Steps to reproduce:**
1. Create a kit product with avg costing, invoiced on ordered
qty, and a BoM with 2 components that have a cumulative cost
equalling that of the final kit product

2. Make a purchase for it, invoice -> post

3. Try to validate the receipt -> can't due to attempted
re-reconicilation

**Cause of the issue:**
When validating the receipt, we end up here:
https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L81-L90
And attempt to reconcile both the original kit product AML from
corresponding to the purchase line as well as the AML for the
component in the stock input account.

But we only will capture 1 exploded component AML in each loop
iteration, so the original kit product AML will not actually be
set `reconciled = True`, so we will also add it to be
reconciled again:
https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L90

The same thing happens in subsequent calls to
`_stock_account_anglo_saxon_reconcile_valuation()`, except on
a final call for the last component line- if the components'
cumulative cost aligns with the total cost of the kit product
(which it should) then the reconciliation attempt will succeed.

Then here: https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L92
`reconcile()` is called on the already-reconciled AML which will
cause the re-reconiliation error.

**Fix**
Reconcile all the resulting kit AMLs (component AMLs + actual
kit product AML from the bill) together.

opw-4668004

Forward-Port-Of: odoo/odoo#207803
Forward-Port-Of: odoo/odoo#205401

Before this commit, there was no test to ensure that orders could be validated correctly when using a currency with zero decimal places. This commit adds a test to validate an order with a zero decimal places currency, ensuring that the system handles such cases without errors. opw-4595028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203380 Forward-Port-Of: odoo/odoo#198754

Before this commit, there was no test to ensure that orders could be validated correctly when using a currency with zero decimal places. This commit adds a test to validate an order with a zero decimal places currency, ensuring that the system handles such cases without errors.

opw-4595028

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

Forward-Port-Of: odoo/odoo#203380
Forward-Port-Of: odoo/odoo#198754

Before this commit, retrieving the QR code from the PoS interface would result in an error due to a missing `cliTrxNumber` in the request. This issue occurs because the `structured_communication` is empty when sending from PoS. opw-4599402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200131

Before this commit, retrieving the QR code from the PoS interface would result in an error due to a missing `cliTrxNumber` in the request. This issue occurs because the `structured_communication` is empty when sending from PoS.

opw-4599402

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

Forward-Port-Of: odoo/odoo#200131

When `<attribute name="string" add="something more"` is used to add onto a string in another view, the `"something more"` string isn't translatable. Therefore since there isn't anything else adding onto this string, let's completely replace it with the original string + the "something more" string. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207896

When `<attribute name="string" add="something more"` is used to add onto a string in another view, the `"something more"` string isn't translatable. Therefore since there isn't anything else adding onto this string, let's completely replace it with the original string + the "something more" string.



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

Forward-Port-Of: odoo/odoo#207896

When using an intermediate return location, the delivered qty of a returned kit is incorrect To reproduce the issue: 1. In Settings, enable "Multi-Step Routes" 2. Create a location L: - Parent: WH - Type: Internal - Return location: True 3. Create a route: - Applicable on: Main warehouse - Add one rule: - Action: Push To - Operation Type: Internal - From: L - To: WH/Stock 4. Create a kit K 5. Sell and deliver 1 x K 6. Return it to L - It

When using an intermediate return location, the delivered qty of a 
returned kit is incorrect

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a location L:
   - Parent: WH
   - Type: Internal
   - Return location: True
3. Create a route:
   - Applicable on: Main warehouse
   - Add one rule:
     - Action: Push To
     - Operation Type: Internal
     - From: L
     - To: WH/Stock
4. Create a kit K
5. Sell and deliver 1 x K
6. Return it to L
   - It will create an internal transfer 
7. Process the internal transfer
8. Open the SO

Error: The delivered quantity of the kit is -1 instead of 0

Step 6, when returning the kit, the push rule is applied and create 
the SM from L to WH/Stock. Since we copy the SM from Customer to L, the
new SM also has the field `sale_line_id` defined.

As a result, step 7, since all SM are done, `moves` contain them 
(the delivery, the return and the internal transfer). We then filter 
them based on some criteria:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L67-L73
But, for `outgoing_moves` (which is actually the incoming ones, the 
name is wrong), since we look at the destination location, both the 
return and the internal SM will match. That's why we will decrease 
twice the delivered quantity. Hence, the bug.

A fix could be to avoid copying the `sale_line_id` field. That being 
said, when looking `sale_stock` side (i.e., same flow with a classic 
product), we don't have any issue because the filters are slightly 
different:
https://github.com/odoo/odoo/blob/418dc0cc3b3aa1ee2abbdb4852d9cd24fba7636e/addons/sale_stock/models/sale_order_line.py#L274-L278
(Here, we need to look at the `incoming_moves`. Again: the name is just 
incorrect on mrp side...)
We see that, for `incoming_moves`, we actually look at the source 
location. This explains why we don't have any issue with a non-kit 
product.

Therefore, the best fix would be to use the same filters everywhere. 
Good news, such a method already exist:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L115-L116
However, using this method might lead to some other issues (among them: 
the override in `sale_subscription_stock` reads a field although the 
method is an `api.model` one). So, let's minimize the diff on stable 
version and refactor the code (use the same filters everywhere) on 
master.

About the filter names, the confusion actually comes from:
https://github.com/odoo/odoo/blob/312572c7b8138a4800350cd7a524a37551a348ef/addons/mrp/models/stock_move.py#L624
There, we should rather talk about positive moves and negatives 
moves, since this method can be used either in a SO flow or in a PO 
one. This explains why, for now, SO sode, an "incoming move" is 
actually an outgoing one. So, on master, another commit will be 
added to also clean that part of the code:
\- Improve the expected filter names in `_compute_kit_quantities`
\- Fix the filter names in `_get_incoming_outgoing_moves_filter`

OPW-4625228

Forward-Port-Of: odoo/odoo#207739
Forward-Port-Of: odoo/odoo#206966

With this commit; if a template is selected (need to be added in xml view in 16.0 but already display in 17.2) the body and the subject will be rendered. task-4664784 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#207816 Forward-Port-Of: odoo/odoo#203254

With this commit; if a template is selected (need to be added in xml view in 16.0 but already display in 17.2) the body and the subject will be rendered.

task-4664784

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#207816
Forward-Port-Of: odoo/odoo#203254

Before this commit: ===================== - The combo selection dialog flickered when a combo product had only one choice and was non-configurable, as it opened and closed rapidly. - In self-order mode, a traceback occurred in this scenario, and the auto- selection of the combo choice was missing, unlike in the main POS. After this commit: ============== - The dialog no longer flickers and will not open if there is only one non- configurable choice. It now only opens when multip

Before this commit:
=====================
- The combo selection dialog flickered when a combo product had only one
  choice and was non-configurable, as it opened and closed rapidly.
- In self-order mode, a traceback occurred in this scenario, and the auto-
  selection of the combo choice was missing, unlike in the main POS.

After this commit:
==============
- The dialog no longer flickers and will not open if there is only one non-
  configurable choice. It now only opens when multiple choices are available or
  configuration is required.
- The auto-selection of the combo choice is now consistent between self-order
  mode and the main POS, preventing tracebacks.

Task-4664491

Forward-Port-Of: odoo/odoo#207730
Forward-Port-Of: odoo/odoo#203211

Steps to reproduce the bug: - Create a service product “S1” - Create a repair order: - In the parts: - Click on the catalog Problem: You can select a service product, whereas the products in the repair parts should be restricted to consumable-type products only: https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48 opw-4687472 Forward-Port-Of: odoo/odoo#207596 Forward-Port-Of: odoo/odoo#204527

Steps to reproduce the bug:
- Create a service product “S1”
- Create a repair order:
    - In the parts: - Click on the catalog

Problem:
You can select a service product, whereas the products in the repair parts should be restricted to consumable-type products only:

https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48

opw-4687472

Forward-Port-Of: odoo/odoo#207596
Forward-Port-Of: odoo/odoo#204527

PR #202334 introduced a test in `pos_loyalty` that depends on the field `discount_product_id` that is created in the module `pos_discount`. However, `pos_loyalty` and `pos_discount` does not have dependence, so the fails if `pos_discount` is not installed. This PR only runs it when `pos_discount` is installed. opw-4622428 Forward-Port-Of: odoo/odoo#207758

PR #202334 introduced a test in `pos_loyalty` that depends on the field `discount_product_id` that is created in the module `pos_discount`. However, `pos_loyalty` and `pos_discount` does not have dependence, so the fails if `pos_discount` is not installed.

This PR only runs it when `pos_discount` is installed.

opw-4622428

Forward-Port-Of: odoo/odoo#207758

Build error 162704 Follow-up on other WebSocket fixes, this time for the execution of the WebSocket request inside the same test, but not after a Chrome browser. This case is quite specific and is related to a low timeout set on websocket_connect, leading to the request being randomly executed inside the test. This is a problem for the current test (fixed by increasing the timeout), but also for the next test: if the TestCursor rollback fails, the cursor_stack of the TestCursor is not empt

Build error 162704

Follow-up on other WebSocket fixes, this time for the execution of the WebSocket request inside the same test, but not after a Chrome browser.

This case is quite specific and is related to a low timeout set on websocket_connect, leading to the request being randomly executed inside the test. This is a problem for the current test (fixed by increasing the timeout), but also for the next test: if the TestCursor rollback fails, the cursor_stack of the TestCursor is not emptied, leading to a case where an existing read-only test cursor in the stack makes the next TestCursor read-only, causing chain failures.

Forward-Port-Of: odoo/odoo#207974

Currently, since we read most data from cache, if an employee right was changed, it is not reflected in the pos. Steps to reproduce: ------------------- * Enable "Log in with employees" and set some records for each field. * Open session, make a sale, close register * Edit employees configuration, delete one, change rights advanced -> minimal * Reopen the session > Observation: The employee deleted is still visible in the list of cashiers and the employee that has now minimal rights is

Currently, since we read most data from cache, if an employee right was changed, it is not reflected in the pos.

Steps to reproduce:
-------------------
* Enable "Log in with employees" and set some records for each field.
* Open session, make a sale, close register
* Edit employees configuration, delete one, change rights advanced -> minimal
* Reopen the session
> Observation: The employee deleted is still visible in the list of cashiers
and the employee that has now minimal rights is still having advanced rights.

Why the fix:
------------
When removing rights from an employee it is important to have it reflected as soon as possible.

A possible solution would have been to recompute `last_data_change` when making any modification on the employee rights but this would recompute everything and we lose the performance added by the caching feature.

Instead, by adding the model to `uniqueModels` we ensure that anytime we reload the pos, all `hr.employee` records will be dropped from the indexedDB, which ends up using the data loaded.

https://github.com/odoo/odoo/blob/5d52373b4c9d64968316c4e883d6b49c7cd1d048/addons/point_of_sale/static/src/app/services/data_service.js#L246-L251

opw-4699241

Forward-Port-Of: odoo/odoo#206914
Forward-Port-Of: odoo/odoo#206099

Steps to reproduce the bug: - Use Edge browser with zoom set to 150% (default zoom on Windows installations). - On a screen with a resolution of 1920px (and the browser window set to full width). - Install the Website app and go to the homepage. - The page is displayed in desktop view. - Enter edit mode by clicking the "Edit" button. - The page width becomes smaller than the mobile breakpoint. As a result , the page switches to mobile view: the navbar turns into a hamburger menu, and the

Steps to reproduce the bug:

- Use Edge browser with zoom set to 150% (default zoom on Windows installations).
- On a screen with a resolution of 1920px (and the browser window set to full width).
- Install the Website app and go to the homepage.
- The page is displayed in desktop view.
- Enter edit mode by clicking the "Edit" button.
- The page width becomes smaller than the mobile breakpoint. As a result , the page switches to mobile view: the navbar turns into a hamburger menu, and the layout changes to mobile style.

This should not happen, as the edit mode is designed to remain in desktop view with 150% zoom on 1920px wide screens. The issue is caused by Edge adding a few pixels of border around the browser window, which leads to this problem specific to Edge.

To fix this in the stable version, we reduce the sidebar width in edit mode by 5 pixels to ensure the page stays in desktop view. This change is applied only if the browser is Edge and 150% zoom is used. In all other cases, no changes are made.

This fix is temporary. In the next redesign of the edit mode sidebar, the sidebar width will be adjusted accordingly so that this workaround will no longer be necessary.

Note: The Arc browser has the same issue, but we haven’t fixed it because there’s currently no way to reliably detect it in JavaScript. Since Arc is much less popular than Edge, it’s less critical.

task-4587203

Forward-Port-Of: odoo/odoo#207835
Forward-Port-Of: odoo/odoo#205721

* = pos_restaurant In this commit: === - Ensured that when a popup is open and the screensaver appears, the popup no longer overlays the screensaver. - Fixed an issue in the restaurant module is installed, after the screensaver appears on the login screen, clicking would bring back the login screen, but attempting to open a session would trigger the screensaver again. task-4607035 Forward-Port-Of: odoo/odoo#207810 Forward-Port-Of: odoo/odoo#199528

* = pos_restaurant

In this commit:
===
- Ensured that when a popup is open and the screensaver appears, the popup no longer overlays the screensaver.
- Fixed an issue in the restaurant module is installed, after the screensaver appears on the login screen, clicking would bring back the login screen, but attempting to open a session would trigger the screensaver again.

task-4607035

Forward-Port-Of: odoo/odoo#207810
Forward-Port-Of: odoo/odoo#199528

Some languages aren't available on Transifex for saas versions if we do not have a dedicated maintainer for the language or not enough of the language is translated, but they are available for major versoins. As of the time of this commit this included: - Azerbaijani (az), - Bulgarian (bg), - Croatian (hr), - Estonian (et), - Greek (el), - Hebrew (he), - Hungarian (hu), - Latvian (lv), - Mongolian (mn), - Persian (fa), - Portuguese (pt), - Romanian (ro), - Slovak (sk), - Slovenia

Some languages aren't available on Transifex for saas versions if we do not have a dedicated maintainer for the language or not enough of the language is translated, but they are available for major versoins. As of the time of this commit this included:

- Azerbaijani (az),
- Bulgarian (bg),
- Croatian (hr),
- Estonian (et),
- Greek (el),
- Hebrew (he),
- Hungarian (hu),
- Latvian (lv),
- Mongolian (mn),
- Persian (fa),
- Portuguese (pt),
- Romanian (ro),
- Slovak (sk),
- Slovenian (sl),
- Ukranian (uk)

Therefore this commit pulls the current translations from the 18.0 transifex project for these languages. Note that pot file msgmerges were not applied since the end result would have been the same, missing terms from pot files won't have a translation in the po file + extra terms in the po file not in the pot won't be used.

Dates used to be loaded as strings until odoo/odoo#189879 in 18.2. Now they're loaded as luxon DateTime objects and those cannot be passed directly to `t-out`. Task: 4751574 Forward-Port-Of: odoo/enterprise#84096

Dates used to be loaded as strings until odoo/odoo#189879 in 18.2. Now they're loaded as luxon DateTime objects and those
cannot be passed directly to `t-out`.

Task: 4751574

Forward-Port-Of: odoo/enterprise#84096

When `<attribute name="string" add="something more"` is used to add onto a string in another view, the `"something more"` string isn't translatable. Therefore since there isn't anything else adding onto this string, let's completely replace it with the original string + the "something more" string. Forward-Port-Of: odoo/enterprise#84388

When `<attribute name="string" add="something more"` is used to add onto a string in another view, the `"something more"` string isn't translatable. Therefore since there isn't anything else adding onto this string, let's completely replace it with the original string + the "something more" string.

Forward-Port-Of: odoo/enterprise#84388

Forward-Port-Of: odoo/enterprise#84269

Forward-Port-Of: odoo/enterprise#84269

**Problem:** When doing a scrap from the barcode app, the source location field is not accessible. The default source location of the scrap will be the one of the stock move, this could be a problem if the product is located in a child location. For instance if confirming a sale order for product A (which is stored in WH/stock/Shelf 1), the pick generated by the sale order will be from WH/Stock to WH/Output (default pick values). In the barcode app, if doing a scrap from this picking, the

**Problem:**
When doing a scrap from the barcode app, the source location field is not accessible.
The default source location of the scrap will be the one of the stock move, this could be a problem
if the product is located in a child location.
For instance if confirming a sale order for product A (which is stored in WH/stock/Shelf 1), the pick generated by the sale order
will be from WH/Stock to WH/Output (default pick values).
In the barcode app, if doing a scrap from this picking, the source location will be WH/stock and the client will not be able
to change that because the field does not appear.

**Steps to reproduce:**
- From the inventory app dashboard select "internal transfer"
- Create a new internal transfer
- Enter a storable product
- Set a demand quantity
- Click on "Mark as Todo"
- Open the barcode app
- Click on operations
- Select "Internal Operations"
- Select the transfer you just created
- Click on the gear icon on the top right and select "scrap"

**Current Behavior:**
The source location field is not visible

**Expected Behavior:**
The source location field should be visible and editable

**Cause of the issue:**
The source location field is not in the view
https://github.com/odoo/enterprise/blob/a9334bb551606d0151d8fc7a8f3393c3a6e312b9/stock_barcode/views/stock_scrap_views.xml#L68

**Fix:**
I added the source location field in the view

opw-4489401

Forward-Port-Of: odoo/enterprise#83546
Forward-Port-Of: odoo/enterprise#82174

- If the payslip sturct has `use_worked_day_lines = False` the printed payslip shoud not have worked_days_table Task: 4720429 Forward-Port-Of: odoo/enterprise#84248

- If the payslip sturct has `use_worked_day_lines = False`  the printed payslip shoud not have worked_days_table

Task: 4720429

Forward-Port-Of: odoo/enterprise#84248

### Steps to reproduce: - Accounting > Reporting > Partner Ledger - Select multiple partners - Select "Customer Statements" as report - Click "Send" - Go to the one of the partner in question and open the generated PDF - The address is not the one of the company, the footer doesn't show the right company, etc ### Cause: When sending to multiple partners, the action is dispatched with cron so a new `env` is created. This `env` has all companies active and the first one as main company.

### Steps to reproduce:
- Accounting > Reporting > Partner Ledger
- Select multiple partners
- Select "Customer Statements" as report
- Click "Send"
- Go to the one of the partner in question and open the generated PDF
- The address is not the one of the company, the footer doesn't show the right company, etc

### Cause:
When sending to multiple partners, the action is dispatched with cron so a new `env` is created. This `env` has all companies active and the first one as main company. So in the end the wrong company is used to generate the report.

### Solution:
In the cron when calling `_process_send_and_print` we give `report.with_company(company)` to make sure that the value the report will us are the one from the correct company.

Also revert the small [fix](https://github.com/odoo/enterprise/pull/82320/files) that was made before, which is no longer needed.

opw-4635283

Forward-Port-Of: odoo/enterprise#84408

Following 002df5f10d2378bab139ea5d59af7be3d6b40358 which made an error. When creating a new model, the feature that make a record specific to a company (ie: "use_company" -- just adds a field "company_id" on a model) should not be available when in single company mode, but should be available when in multicompany mode opw-4752832 Forward-Port-Of: odoo/enterprise#84225

Following 002df5f10d2378bab139ea5d59af7be3d6b40358 which made an error. When creating a new model, the feature that make a record specific to a company (ie: "use_company" -- just adds a field "company_id" on a model) should not be available when in single company mode, but should be available when in multicompany mode

opw-4752832

Forward-Port-Of: odoo/enterprise#84225

Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible parent_line_id Actually this is not the case, different upsell order can have a line that have the same parent. Upsell order A can have line 1 with the same parent as the line 2 of Upsell order B. Before this commit if the parent line of both order were computed at the same time one of them would end up

Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible parent_line_id

Actually this is not the case, different upsell order can have a line that have the same parent.

Upsell order A can have line 1 with the same parent as the line 2 of Upsell order B.

Before this commit if the parent line of both order were computed at the same time one of them would end up without parent.

This situation is getting worse since odoo@42008de (saas-18.1) were all the parent_line_id are recomputed on every upsell order (even already confirmed one) as soon as line on the parent order are touched

The follow use case lead to duplicate line on the parent

A parent subscription A with 1 product Z
Create an upsell B with a line that upsell 1 product Z Create an upsell C with a line that upsell 1 product Z On both upsell the parent line is set properly

Confirm Upsell B, the parent line on Upsell C is set to false Confirm Upsell B, the parent subscription ends up with a two line for the product Z

After this commit,
parent_line_id are computed per order, so one order cannot have two lines with the same parent_line_id but two (or more) different order can have each one line with the same parent_line_id even if their parent_line_id are computed at the same time.

Forward-Port-Of: odoo/enterprise#84340
Forward-Port-Of: odoo/enterprise#84255

Open Trial Balance report in debug mode Access report options In Column tab, check 'Blank if Zero' for all columns Go back to report Issue: If Initial/End Balance columns are blank, also the total line will be blank. This occurs since f3c230817087d452f810b8473f813add0ead30d0 were the formatting of values has been delayed to improve performances but the exception on 'blank_if_zero' was lost opw-4624006 Forward-Port-Of: odoo/enterprise#84070 Forward-Port-Of: odoo/enterprise#83493

Open Trial Balance report in debug mode
Access report options
In Column tab, check 'Blank if Zero' for all columns Go back to report

Issue: If Initial/End Balance columns are blank, also the total line will be blank.
This occurs since f3c230817087d452f810b8473f813add0ead30d0 were the formatting of values has been delayed to improve performances but the exception on 'blank_if_zero' was lost

opw-4624006

Forward-Port-Of: odoo/enterprise#84070
Forward-Port-Of: odoo/enterprise#83493

…terms Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner with the payment term "30% Now, Balance 60 Days" - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Amount shown on lines "Total amount of intra-community operations" and "E. Intra-community sales" is doubled. This occurs because each installment of the payment terms will be a payment term line, an

…terms

Steps to reproduce:
 - With an ES company setup
 - Create 1 invoice to an EU partner with the payment term "30% Now, Balance 60 Days"
 - Make sure Mod349 Invoice Type is set
 - Go to Accounting / Reporting / Statement Reports / Tax Report
 - Select Tax Report (Mod 349) (ES)

Issue: Amount shown on lines "Total amount of intra-community operations" and "E. Intra-community sales" is doubled.
This occurs because each installment of the payment terms will be a payment term line, and the query retrieving values to compose MOD349 will take the whole move amount for each payment term line.

opw-4637439

Forward-Port-Of: odoo/enterprise#84085
Forward-Port-Of: odoo/enterprise#82435

task-4751862 Forward-Port-Of: odoo/enterprise#84094

task-4751862

Forward-Port-Of: odoo/enterprise#84094

Steps to Reproduce: 1. A document with a long title 2. Upload document 3. Preview the document When a document had a long title, the action buttons in the DocumentsFileViewer The header became misaligned. After this commit: No misalignment on action buttons. Task-4600177 Forward-Port-Of: odoo/enterprise#84375

Steps to Reproduce:
1. A document with a long title
2. Upload document
3. Preview the document

When a document had a long title, the action buttons in the DocumentsFileViewer The header became misaligned.

After this commit:
No misalignment on action buttons.

Task-4600177

Forward-Port-Of: odoo/enterprise#84375

This PR adds a validation check for a company's GST token before making GST API calls via cron. These validations already exist when making GST API calls through the GST return period but were missing in the cron execution. This ensures that no unnecessary cron execution and api call takes place. task-4350780 Forward-Port-Of: odoo/enterprise#84179 Forward-Port-Of: odoo/enterprise#81974

This PR adds a validation check for a company's GST token before making GST API calls via cron.
These validations already exist when making GST API calls through the GST
return period but were missing in the cron execution.
This ensures that no unnecessary cron execution and api call takes place.

task-4350780

Forward-Port-Of: odoo/enterprise#84179
Forward-Port-Of: odoo/enterprise#81974