Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it - call the function with an empty object to get the database url instead Task: 3903743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193182

Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it

- call the function with an empty object to get the database url instead

Task: 3903743



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

Forward-Port-Of: odoo/odoo#193182

Description of the issue/feature this PR addresses: This PR addresses the issue where the currency column repeats in view_move_line_payment_tree view when there are multiple active currencies. This can lead to confusion and clutter in the user interface. Current behavior before PR: Before this PR, when multiple active currencies are set up, the currency column is duplicated in view_move_line_payment_tree view, displaying the same information multiple times. Desired behavior after PR is m

Description of the issue/feature this PR addresses:
This PR addresses the issue where the currency column repeats in view_move_line_payment_tree view when there are multiple active currencies. This can lead to confusion and clutter in the user interface.

Current behavior before PR:
Before this PR, when multiple active currencies are set up, the currency column is duplicated in view_move_line_payment_tree view, displaying the same information multiple times.

Desired behavior after PR is merged:
After merging this PR, the currency column will appear only once when the optional hide setting is enabled, even with multiple active currencies, resulting in a cleaner and more readable report.

[Video](https://drive.google.com/file/d/1bL8L88y81HomX6Q9MkErmOGVDWHdE4_r/view)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#192784

### Before -When the eFactura status was fetched and there was an invoice content error it was not displayed. This issue was due to both the overlooking of: - ​the 'nok' status (sent back by the Romanian authorities regarding the presence of errors in the invoice content)  - the file provided in the zip that would contain the errors -The error message shown would also only contain the first error even if many were present. ### Now -If the status fetched contains 'nok' and is theref

### Before
-When the eFactura status was fetched and there was an invoice content error it was not displayed. This issue was due to both the overlooking of:
-  ​the 'nok' status (sent back by the Romanian authorities regarding the presence of errors in the invoice content) 
-  the file provided in the zip that would contain the errors

-The error message shown would also only contain the first error even if many were present.

### Now

-If the status fetched contains 'nok' and is therefore signaling the presence of invoice content errors, then the apposite error file is chosen instead of the file with the electronic signature. This allows for following logic to account for errors, to retrieve the error message and to provide the error file as the downloadable document. 

-The pop up shows all the errors with an increased width to account for more content.

task-4306506

Forward-Port-Of: odoo/odoo#190618

**Current behavior:** Having some product with a subcontract BoM and using the unarchived 'Subcontract' picking type and creating a purchase order to the subcontractor for that product: changing the `scheduled_date` of the generated receipt will improperly set the start/end date on the subcontracting MO which was generated alongside the receipt. Specifically, the `scheduled_date` of the receipt should correspond to the `date_finished` of the MO- however currently it is incorrectly modifying

**Current behavior:**
Having some product with a subcontract BoM and using the unarchived 'Subcontract' picking type and creating a purchase order to the subcontractor for that product: changing the `scheduled_date` of the generated receipt will improperly set the start/end date on the subcontracting MO which was generated alongside the receipt.

Specifically, the `scheduled_date` of the receipt should correspond to the `date_finished` of the MO- however currently it is incorrectly modifying the MO `date_start` instead.

**Expected behavior:**
Modifying `scheduled_date` on the receipt will in turn modify the `date_finished` of the MO.

**Steps to reproduce:**
*Unarchive the Subcontract picking type operation*
1. Create a final product with a subcontract type BoM, on the BoM set some positive value for Manuf. Lead Time (in miscellaneous tab)

2. Create a purchase order to the subcontractor for that product

3. Confirm the PO -> observe that on creation, the scheduled date of the receipt matches the end date of the MO

4. Change the scheduled date of the receipt (for example, 10 days in the future) -> observe that after saving, the MO date correspondence is inverted (end date = scheduled date + lead time) instead of the start date being set with respect to the end time (like on creation), the end date gets set with respect to the start date

**Cause of the issue:**
It's an inconsistency with how the fields (start, end) are calculated and when.

**Fix:**
Make this case behave the same as the creation does- that is, end date is informed by the receipt's scheduled date and the start date of the MO is set by subtracting the lead time from there.

opw-4231548

Forward-Port-Of: odoo/odoo#188389

In odoo/odoo#192449, we removed the only code patch we had on the IoT Box. We can then remove the patching logic. Forward-Port-Of: odoo/odoo#193935

In odoo/odoo#192449, we removed the only code patch we had on the IoT Box. We can then remove the patching logic.

Forward-Port-Of: odoo/odoo#193935

Chart.js can be really slow when rendering a large number of datasets. So this commit limits the amount of datasets displayed by default on the graph. However a button is present to display all datasets even if it can take a moment to render them. task-4351783 Forward-Port-Of: odoo/odoo#193814 Forward-Port-Of: odoo/odoo#192892

Chart.js can be really slow when rendering a large number of datasets.
So this commit limits the amount of datasets displayed by default on the graph.
However a button is present to display all datasets even if it can take a moment to render them.

task-4351783

Forward-Port-Of: odoo/odoo#193814
Forward-Port-Of: odoo/odoo#192892

For Belgium, combination of taxes and their deductibility are many. While our system of Distribution lines can be used in many cases, it's not easy or intuitive to configure, even for advanced accountants. This commit aims at making sure: - The most useful taxes are active by default - We provide a few examples of the most commonly used Deductible taxes as well as examples of specific cases (Deductible IntraCom taxes). task-id 4417039 Forward-Port-Of: odoo/odoo#191350

For Belgium, combination of taxes and their deductibility are many. While our system of Distribution lines can be used in many cases, it's not easy or intuitive to configure, even for advanced accountants.

This commit aims at making sure:
- The most useful taxes are active by default
- We provide a few examples of the most commonly used Deductible taxes as well as examples of specific cases (Deductible IntraCom taxes).

task-id 4417039

Forward-Port-Of: odoo/odoo#191350

**Current behavior:** The rounding applied during the cost split of a landed cost's cost computation can yield undesirable/unexpected results. **Expected behavior:** Sensible rounding. **Steps to reproduce:** 1. Create some product with arbitrary cost, with avg and real_time costing and valuation, respectively 2. Create a purchase order with 6 lines, all for that product 3. Confirm order & receive products, create bill and add a landed cost line with cost=6.85 4. Post bill a

**Current behavior:**
The rounding applied during the cost split of a landed cost's
cost computation can yield undesirable/unexpected results.

**Expected behavior:**
Sensible rounding.

**Steps to reproduce:**
1. Create some product with arbitrary cost, with avg and
real_time costing and valuation, respectively

2. Create a purchase order with 6 lines, all for that product

3. Confirm order & receive products, create bill and add a
landed cost line with cost=6.85

4. Post bill and create the landed cost:
* link to the receipt
* set split method to `equal`

5. Validate the LC, see that the val adjustment lines are
rounded unexpectedly- *specifically all the lines are rounded up
(beyond the per-adjustment-line value) which means the final
adjustment line cost-split share will reflect the cumulative
rounding loss of every adjustment line rounded prior*
E.g.,
<pre>
[ 1.15, 1.15, 1.15, 1.15, 1.15, 1.11 ]
                                  ^
</pre>

**Cause of the issue:**
We currently use `rounding_method='UP'`.

**Fix:**
Round HALF-UP. This will minimize the difference between the
true, unrounded split-value and the post-rounding value.

Semi-related fix: try to use consistent `ResCurrency.round()`
methods between `compute_landed_cost()` and `_check_sum()`.

opw-4200916

Forward-Port-Of: odoo/odoo#190449

Peppol migration creates more issues than it solves. A lot of users issue migration requests to move to another SMP but later discover that the SMP they wanted to migrate to does not support migration keys. This creates a state that we need to handle manually. Most SMP do not support migrating away and force users to deregister and reregister again on another one. This commit adds a fix in stable for that issue by removing the button from the res_config_settings_buttons and adding a deprecate

Peppol migration creates more issues than it solves. A lot of users issue migration requests to move to another SMP but later discover that the SMP they wanted to migrate to does not support migration keys. This creates a state that we need to handle manually. Most SMP do not support migrating away and force users to deregister and reregister again on another one.

This commit adds a fix in stable for that issue by removing the button from the res_config_settings_buttons and adding a deprecated warning when the user tries to call the `button_migrate_peppol_registration` method.

task-4394408

Forward-Port-Of: odoo/odoo#193794

Versions -------- - 16.0+ Steps ----- 1. Have a user with only access to "Sales User: Own Documents Only"; 2. open a product variant page; 3. add a comment in the chatter. Issue ----- Access Error Cause ----- Commit 35a07975deb0 added `_mail_post_access = 'read'` to the `product.template` model. This allows users with read-only access to still comment on `product.template` records. This was not done for product variants, leading to an inconsistency where an internal user ca

Versions
--------
- 16.0+

Steps
-----
1. Have a user with only access to "Sales User: Own Documents Only";
2. open a product variant page;
3. add a comment in the chatter.

Issue
-----
Access Error

Cause
-----
Commit 35a07975deb0 added `_mail_post_access = 'read'` to the `product.template` model. This allows users with read-only access to still comment on `product.template` records.

This was not done for product variants, leading to an inconsistency where an internal user can comment on product templates, but not variants.

Solution
--------
Add `_mail_post_access = 'read'` to `product.product` as well.

opw-4189326

Forward-Port-Of: odoo/odoo#194005

When we go to the website preview in the Odoo backend, if the current domain used (to access the backend) is not the same as the one of the previewed website, we redirect the user, and he might have to reconnect. The same is done when using the website switcher. Note: in the first case, the user is warned. We should probably do the same for the second case (?). This is a problem for the Odoo support team. When they connect to a customer database upon user request, the <customer_db_name>.odoo

When we go to the website preview in the Odoo backend, if the current domain used (to access the backend) is not the same as the one of the previewed website, we redirect the user, and he might have to reconnect. The same is done when using the website switcher.
Note: in the first case, the user is warned. We should probably do the same for the second case (?).

This is a problem for the Odoo support team. When they connect to a customer database upon user request, the <customer_db_name>.odoo.com address is used. But as soon as they are using the website app, they are redirected to the real website domains... where they are disconnected and cannot connect themselves.
To fix this issue, we allow setting up a session info parameter to bypass those website redirections. This is not to be done by real users: this will come with bugs (for the support team). Indeed, we are normally redirecting for a reason: many flows rely on using the right domain when visiting a specific website. Depending on what users have in their page, this could also simply make the website preview iframe crash.

task-4069779

Forward-Port-Of: odoo/odoo#193648
Forward-Port-Of: odoo/odoo#193122

Problem: When a manufacturing order with a work order that was not planned is completed, a resource.calendar.leave is created for the work order. During this process the work order’s date_finished field is recalculated. This means that this work order reserves a slot in the work center to be finished in the future even though it has already been completed. Purpose: If the work order already has a date_finished value, then that value should be used instead of it being recalculated based on the

Problem: When a manufacturing order with a work order that was not planned is completed, a resource.calendar.leave is created for the work order. During this process the work order’s date_finished field is recalculated. This means that this work order reserves a slot in the work center to be finished in the future even though it has already been completed.

Purpose: If the work order already has a date_finished value, then that value should be used instead of it being recalculated based on the availability of the work center. This will help ensure that completed work orders are not reserving time in a work center when it has already been completed.

Steps to Reproduce on Runbot:

1. Create a new storable product.
2. Create a BoM for this product and navigate to the Operations tab and add an operation.
3. Create a manufacturing order, confirm it, and then produce all without planning it.
4. Navigate to the completed work order and observe the finished date is in the future.
5. Navigate to the work centers working hours’ time off and find the record associated with the work order.
6. Observe that the end date is in the future.

opw-4393301

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

Forward-Port-Of: odoo/odoo#192393

We now also delete `lib/` directory before deleting/downloading new IoT handlers. In community, this directory does not exist, resulting in Path error while trying to `iterdir()` on it. We now look for files recursively inside `iot_handlers/`, and provide the list to the updated method `unlink_file` that now accepts multiple arguments to avoid excessively switching between rw/ro filesystem modes. Forward-Port-Of: odoo/odoo#193990

We now also delete `lib/` directory before deleting/downloading new IoT handlers.
In community, this directory does not exist, resulting in Path error while trying to `iterdir()` on it.
We now look for files recursively inside `iot_handlers/`, and provide the list to the updated method `unlink_file` that now accepts multiple arguments to avoid excessively switching between rw/ro  filesystem modes.

Forward-Port-Of: odoo/odoo#193990

Apparently in normal mode (and thus the new headless mode) Chrome does not focus the document. The `activeElement` is correctly set, but `document.hasFocus()` always returns `false` and per-element focus events are suppressed. That makes tests testing or needing focus fail in the new headless mode as well as well as impossible (or at least frustrating) to `debug`. Enabling "focus emulation", which corresponds to the "Emulate a focused page" UI option, seems to resolve the issue. Fixes r

Apparently in normal mode (and thus the new headless mode) Chrome does not focus the document. The `activeElement` is correctly set, but `document.hasFocus()` always returns `false` and per-element focus events are suppressed.

That makes tests testing or needing focus fail in the new headless mode as well as well as impossible (or at least frustrating) to `debug`.

Enabling "focus emulation", which corresponds to the "Emulate a focused page" UI option, seems to resolve the issue.

Fixes reliably failing tests

- `/im_livechat:ExternalTestSuite.test_external_livechat`
- `/account:TestUI.test_01_account_tax_groups_tour`
- `/account_accountant:TestBankRecWidget.test_tour_bank_rec_widget`
- `/web_editor:TestOdooEditor.test_odoo_editor_suite`

Backport of: odoo/odoo@0aaf98b77feaa15f5eb30e1c251f5765e8afbfa5

Forward-Port-Of: odoo/odoo#193993

Steps to produce: - Drop 'Text - Image' block - Replace image by illustration - Try to crop image - A notification is displayed - Try saving The issue is ImageCrop is still not opened and we are trying to wait for image_cropper_destroyed to trigger, so here we check if ImageCrop is not opened. task-4246644 Forward-Port-Of: odoo/odoo#188577

Steps to produce:
- Drop 'Text - Image' block
- Replace image by illustration
- Try to crop image
- A notification is displayed
- Try saving

The issue is ImageCrop is still not opened and we are trying to wait for image_cropper_destroyed to trigger,
so here we check if ImageCrop is not opened.

task-4246644

Forward-Port-Of: odoo/odoo#188577

Steps to reproduce: [l10n_dk] - create and confirm a sale order - create an expense for a new employee and use a product set with reinvoice at cost and a tax with multiple repartition lines - confirm and process the expense - post journal entries Issue: Missing required fields on accountable sale order line. Cause: We want to reinvoice the tax line that no product on it opw-4378714 Forward-Port-Of: odoo/odoo#193036 Forward-Port-Of: odoo/odoo#191163

Steps to reproduce:
[l10n_dk]
- create and confirm a sale order
- create an expense for a new employee and use a product set with reinvoice at cost and a tax with multiple repartition lines
- confirm and process the expense
- post journal entries

Issue:
Missing required fields on accountable sale order line.

Cause:
We want to reinvoice the tax line that no product on it

opw-4378714

Forward-Port-Of: odoo/odoo#193036
Forward-Port-Of: odoo/odoo#191163