Monday, March 3, 2025
26 changes · saas-17.4
Resolved issues and error corrections
Messages that include special mentions such as @everyone now show them as clickable links instead of raw HTML text. This improves readability and makes group notifications clearer for users.
Original PR description
**Current behavior before PR:** Special mentions (@ everyone) appeared as raw HTML instead of links because when message content is not `markup()`, it is rendered as text instead of HTML when using `t-out`. **Desired behavior after PR is merged:** This commit ensures that special mentions are correctly rendered as links. Before / After   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Currently, using the tax '12% agri' on a Vendor Bill makes the document impossible to validate because of the error `1166 - Valor del campo Tipoimpositivo no está incluido en la lista de valores permitidos` Steps to reproduce: - Have l10n_es_edi_sii module installed and have a tax agency selected. - Make a Bill using '12% agri' tax Issue: When sending the bill for validation the error is raised. This occurs because the field "ClaveRegimenEspecialOTrascendencia" is set to "01", whe
Original PR description
Currently, using the tax '12% agri' on a Vendor Bill makes the document impossible to validate because of the error `1166 - Valor del campo Tipoimpositivo no está incluido en la lista de valores…
Currently, using the tax '12% agri' on a Vendor Bill makes the document impossible to validate because of the error `1166 - Valor del campo Tipoimpositivo no está incluido en la lista de valores permitidos` Steps to reproduce: - Have l10n_es_edi_sii module installed and have a tax agency selected. - Make a Bill using '12% agri' tax Issue: When sending the bill for validation the error is raised. This occurs because the field "ClaveRegimenEspecialOTrascendencia" is set to "01", when it should be "02" for exempt taxes. Also, in this case TipoImpositivo and CuotaSoportada should be replaced by PorcentCompensacionREAGYP and ImporteCompensacionREAGYP https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca/que-consiste-regimen-especial-agricultura-pesca.html https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/Validaciones_ErroresSII_v1.1.pdf opw-4486190 Forward-Port-Of: odoo/odoo#198345 Forward-Port-Of: odoo/odoo#196017
When signed in or when the guest checkout is allowed as we don't want guest to skip the sign in process. opw-4388568 Forward-Port-Of: odoo/odoo#199540
Original PR description
When signed in or when the guest checkout is allowed as we don't want guest to skip the sign in process. opw-4388568 Forward-Port-Of: odoo/odoo#199540
We recently enabled recaptcha on the registration form in [1] Turnstile can be implemented on top of it by just invoking the turnstile script in js. As it's implicitly checked when recaptcha is checked, this also avoids any issue with the form potentially not working if turnstile is enabled. [1]: bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e task-4335141 Forward-Port-Of: odoo/odoo#192827
Original PR description
We recently enabled recaptcha on the registration form in [1] Turnstile can be implemented on top of it by just invoking the turnstile script in js. As it's implicitly checked when recaptcha is checked, this also avoids any issue with the form potentially not working if turnstile is enabled. [1]: bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e task-4335141 Forward-Port-Of: odoo/odoo#192827
*FPOS - Fiscal Position *POS - Place of Supply - Before this commit: The fiscal position was determined based on the partner's shipping address (`partner_shipping_id`) in sales orders, which did not align with Indian tax regulations. - After this commit: The fiscal position is now computed based on the place of supply, ensuring compliance with Indian tax requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo
Original PR description
*FPOS - Fiscal Position *POS - Place of Supply - Before this commit: The fiscal position was determined based on the partner's shipping address (`partner_shipping_id`) in sales orders, which did not align with Indian tax regulations. - After this commit: The fiscal position is now computed based on the place of supply, ensuring compliance with Indian tax requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197433
Steps to Reproduce: - Log in with a user having no special access right in Employees. - Install point_of_sale and hr modules. - Try to download the "User Labels" from the "My Profile" section. Cause: - In the report barcode field has been used which is accessible only to users having "group_hr_user" group. Fix: - Added a check before accessing the barcode field, to ensure the user has the appropriate access right. task-4497441 --- I confirm I have signed the CLA and read the PR
Original PR description
Steps to Reproduce: - Log in with a user having no special access right in Employees. - Install point_of_sale and hr modules. - Try to download the "User Labels" from the "My Profile" section. Cause: - In the report barcode field has been used which is accessible only to users having "group_hr_user" group. Fix: - Added a check before accessing the barcode field, to ensure the user has the appropriate access right. task-4497441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199592 Forward-Port-Of: odoo/odoo#196912
Description of the issue/feature this PR addresses: Task: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - Wrong names for certain accounts Desired behavior after PR is merged: - Fix names for accounts --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190705
Original PR description
Description of the issue/feature this PR addresses: Task: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - Wrong names for certain accounts Desired behavior after PR is merged: - Fix names for accounts --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190705
Some "True"/"False" terms were incorrectly untranslated back into "True"/"False" in German. This cases a test to fail and was incorrect in these contexts. Revert it. Note: Some inconsistency reverts may have been applied, but should have no effect on code. More thorough revert will be done later on by translator. 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
Original PR description
Some "True"/"False" terms were incorrectly untranslated back into "True"/"False" in German. This cases a test to fail and was incorrect in these contexts. Revert it. Note: Some inconsistency reverts may have been applied, but should have no effect on code. More thorough revert will be done later on by translator. 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
**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time, milestone reached: 0 days after allocation start date, carry over: all accrued time carried over. - Create an allocation using this accrual plan. Set the start date a few years in the past (e.g. 3 years ago). Save the allocation. - Manually set the number of days of the allocation to 0. - Validate
Original PR description
**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time,…
**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time, milestone reached: 0 days after allocation start date, carry over: all accrued time carried over. - Create an allocation using this accrual plan. Set the start date a few years in the past (e.g. 3 years ago). Save the allocation. - Manually set the number of days of the allocation to 0. - Validate the allocation. - Time Off Dashboard > Check the number of days accrued on the 2nd day of next year. Actual: 20 days. Expected: 10 days (gained on the 1st of next year, 0 days before that as the allocation has been set to 0). **Cause** 0 days allocations (using an acrcual plan with gain time at start) are considered as not already accrued, even if they are marked as `already_accrued`. https://github.com/odoo/odoo/blob/8b339fdde161e81e1a00cecd3b1fd280de51fd08/addons/hr_holidays/models/hr_leave_allocation.py#L460 In this case, we process the accrual plans when changing the date, which triggers the `_onchange_date_from` and marks the allocation as `already_accrued`. opw-4340521 Forward-Port-Of: odoo/odoo#198110
This commit e35b3b088584b45b0278174da355d09e7e47633b was a fix for wrong calculation of base_url but the old calculation still there This was not detected because the test was not imported in __init__ file now it is removed and the test is imported in `__init__.py` opw-4235176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199268
Original PR description
This commit e35b3b088584b45b0278174da355d09e7e47633b was a fix for wrong calculation of base_url but the old calculation still there This was not detected because the test was not imported in __init__ file now it is removed and the test is imported in `__init__.py` opw-4235176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199268
## Versions: 17.0+ ## Issue: Multi-checkboxes attributes are displayed as filters in the shop view but are not displayed in mobile view. ## Steps to reproduce: 1. Create a `Multi-checkbox (option)` attribute called "Extra" via `Sales / Configuration / Products / Attributes`; 2. Add 1 attribute value; 3. Go to any product available on the shop (e.g. Acoustic Bloc Screens); 4. Via its `Attributes & Variants` tab, add the newly created attributes and select the value; 5. Go to the shop
Original PR description
## Versions:
17.0+
## Issue:
Multi-checkboxes attributes are displayed as filters in the shop view but are not displayed in mobile view.
## Steps to reproduce:
1. Create a `Multi-checkbox (option)` attribute called "Extra" via `Sales / Configuration / Products / Attributes`;
2. Add 1 attribute value;
3. Go to any product available on the shop (e.g. Acoustic Bloc Screens);
4. Via its `Attributes & Variants` tab, add the newly created attributes and select the value;
5. Go to the shop via the `Website` app;
- *In normal web view, the filter is available on the left*
6. Change view to mobile mode and open the filters;
7. Open the "Extra filter and see no filter under it.
## Cause:
Mobile displayed filters are restricted to avoid color attributes but didn't expand to allow multi-checkboxes.
opw-4383970
Forward-Port-Of: odoo/odoo#198087Steps to reproduce: 1) Install loca spanish 2) Create and post an invoice using the tax 4% G (goods) then create and post a related credit note 3) Check the Tax return report (Modelo 303): Issue: In Odoo 16, the base en cuota are negative (For box 14 and 15) In Odoo17 and 18, the base en cuota are positive (For box 14 and 15) Cause: The sign for the tax tags on the refund was wrong opw-4546566 Forward-Port-Of: odoo/odoo#197376
Original PR description
Steps to reproduce: 1) Install loca spanish 2) Create and post an invoice using the tax 4% G (goods) then create and post a related credit note 3) Check the Tax return report (Modelo 303): Issue: In Odoo 16, the base en cuota are negative (For box 14 and 15) In Odoo17 and 18, the base en cuota are positive (For box 14 and 15) Cause: The sign for the tax tags on the refund was wrong opw-4546566 Forward-Port-Of: odoo/odoo#197376
steps to reproduce: ------------------- - Install the module pos_restaurant - Open PoS - Open a table and add some products on it - Go back to the floor plan (this is to make sure the order is saved on the server) - Go offline with the chrome devtools - Pay the order - Go back online - Click on the table where you made the order > Observation: The order is still there even if you already paid it why the fix: ------------ When clicking on the table we will fetch all the orders from
Original PR description
steps to reproduce: ------------------- - Install the module pos_restaurant - Open PoS - Open a table and add some products on it - Go back to the floor plan (this is to make sure the order is saved on the server) - Go offline with the chrome devtools - Pay the order - Go back online - Click on the table where you made the order > Observation: The order is still there even if you already paid it why the fix: ------------ When clicking on the table we will fetch all the orders from the server and because you were offline the version of the order that comes from the server is the one that is not paid. So we need to push the order to the server before fetching the orders. opw-4591204 Forward-Port-Of: odoo/odoo#199457
This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. - Cause an issue for MX and EC country code - VAT field is removed from mandatory fields - No need to remove the vat field manually, when the country changes the mandatory field list will be changed accordingly. Runbot Errors: 111328, 111329 Related: https://github.com/odoo/enterprise/pull/79646 --- I confirm I have signed the CLA and read the PR guide
Original PR description
This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. - Cause an issue for MX and EC country code - VAT field is removed from mandatory fields - No need to remove the vat field manually, when the country changes the mandatory field list will be changed accordingly. Runbot Errors: 111328, 111329 Related: https://github.com/odoo/enterprise/pull/79646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198506
Description of the issue/feature this PR addresses: While payment links do not allow association with more than one invoice, there are possibilities through the ORM and third-party modules. The commit https://github.com/odoo/odoo/commit/b9abe46c1492b09e369434e76ec8196c6b02dd19 improved the behavior of early discounts in payment transactions, but payment transactions related to more than one invoice fail during the execution of the `_create_payment` method. Current behavior before PR: Tr
Original PR description
Description of the issue/feature this PR addresses: While payment links do not allow association with more than one invoice, there are possibilities through the ORM and third-party modules. The commit https://github.com/odoo/odoo/commit/b9abe46c1492b09e369434e76ec8196c6b02dd19 improved the behavior of early discounts in payment transactions, but payment transactions related to more than one invoice fail during the execution of the `_create_payment` method. Current behavior before PR: Transactions related to more than one invoice can be created and validated, but they fail during the execution of the _reconcile_after_done method. Desired behavior after PR is merged: Transactions related to more than one invoice can be created, validated, and completed successfully without errors in _reconcile_after_done. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199578
This issue is not directly an Odoo issue, but it can create an issue if a custom module adds a field called journal_id to the account.payment model. There are no knock-on effects of this, because anyway the original developer should have specified the table. Additionally, it seems that there was a mild typo in the line before it that didn't affect anything. I see no harm in fixing it. Description of the issue/feature this PR addresses: Current behavior before PR: No change in behavior.
Original PR description
This issue is not directly an Odoo issue, but it can create an issue if a custom module adds a field called journal_id to the account.payment model. There are no knock-on effects of this, because anyway the original developer should have specified the table. Additionally, it seems that there was a mild typo in the line before it that didn't affect anything. I see no harm in fixing it. Description of the issue/feature this PR addresses: Current behavior before PR: No change in behavior. Desired behavior after PR is merged: No change in behavior. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195494
**Issue:** The formula of the cross report line for the 2024 variant of the balance sheet report is referencing a report line from the main profit and loss report instead of its 2024 variant. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80551
Original PR description
**Issue:** The formula of the cross report line for the 2024 variant of the balance sheet report is referencing a report line from the main profit and loss report instead of its 2024 variant. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80551
The way the queries were formatted was prone to create injections (though it didn't in this case). This commit makes proper use of the SQL formatter to avoid that and make the code more robust. Forward-Port-Of: odoo/enterprise#80493
Original PR description
The way the queries were formatted was prone to create injections (though it didn't in this case). This commit makes proper use of the SQL formatter to avoid that and make the code more robust. Forward-Port-Of: odoo/enterprise#80493
We're adding support for recaptcha in appointment forms to prevent bots from easily filling up slots. In 17.0 cloudflare turnstile is added as an alternative and/or fallback for recaptcha. We adapt the js code to call the cloudflare client API which gives us support of this feature "for free" as all of the logic is already implemented for the check. task-4335141 Forward-Port-Of: odoo/enterprise#76672
Original PR description
We're adding support for recaptcha in appointment forms to prevent bots from easily filling up slots. In 17.0 cloudflare turnstile is added as an alternative and/or fallback for recaptcha. We adapt the js code to call the cloudflare client API which gives us support of this feature "for free" as all of the logic is already implemented for the check. task-4335141 Forward-Port-Of: odoo/enterprise#76672
This commit improves the tool tip and the presentation of the quality control random view. When you set a quality point to "random" with a percentage of 20% and process a transfer of 100 units, it does not mean that exactly 20% of the transfer will be inspected. Instead, each unit has a 20% probability of being checked. For example, if you process ten transfers of 100 units each, you might get 18 quality checks in one transfer, 10 in another, 25 in the next, and so on. The key point is tha
Original PR description
This commit improves the tool tip and the presentation of the quality control random view. When you set a quality point to "random" with a percentage of 20% and process a transfer of 100 units, it does not mean that exactly 20% of the transfer will be inspected. Instead, each unit has a 20% probability of being checked. For example, if you process ten transfers of 100 units each, you might get 18 quality checks in one transfer, 10 in another, 25 in the next, and so on. The key point is that, statistically, approximately 20% of your total quantities will be inspected over multiple transfers. opw-4527413 Forward-Port-Of: odoo/enterprise#80482
Mod349 tax report in Spanish localization should report the total number of intra-community operators and a following details of each operation type Currently if the user decide to unset the field l10n_es_reports_mod349_invoice_type on an intra-community invoice (because of a mistake or an exception) the Mod349 will still report the invoice in the total number of intra community operators but no operation will be reported in the following section Steps to reproduce: - With an ES company se
Original PR description
Mod349 tax report in Spanish localization should report the total number of intra-community operators and a following details of each operation type Currently if the user decide to unset the field l10n_es_reports_mod349_invoice_type on an intra-community invoice (because of a mistake or an exception) the Mod349 will still report the invoice in the total number of intra community operators but no operation will be reported in the following section Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is unset - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Total number of intra-community operators is 1, but no operation is shown opw-4403287 Forward-Port-Of: odoo/enterprise#80458 Forward-Port-Of: odoo/enterprise#80253
__Steps to reproduce:__ 1. Create a project (billable). 2. Give the user access to Company A + B, while the default is A 3. Add a task with a customer belonging to company B 4. Create a task and add products to it. __Description of the issue:__ - The **"Decrease"** button is disabled, with raised error message that the amount is delivered. - This happens because the domain fetching `stock.move` uses user’s default company instead of SO’s company which leads to the wrong default WH _
Original PR description
__Steps to reproduce:__ 1. Create a project (billable). 2. Give the user access to Company A + B, while the default is A 3. Add a task with a customer belonging to company B 4. Create a task and add products to it. __Description of the issue:__ - The **"Decrease"** button is disabled, with raised error message that the amount is delivered. - This happens because the domain fetching `stock.move` uses user’s default company instead of SO’s company which leads to the wrong default WH __Description of the solution:__ - Update warehouse logic to fetch the default warehouse using the SO’s company context, ensuring `stock.move` domain aligns with the sale order’s company - opw-4471366 Forward-Port-Of: odoo/enterprise#80007
- update upper and lower limits for nssf parameter Task: 4599150 Forward-Port-Of: odoo/enterprise#80016
Original PR description
- update upper and lower limits for nssf parameter Task: 4599150 Forward-Port-Of: odoo/enterprise#80016
**Current behavior:** If a picking has two moves with move lines for the same lot-tracked product, they will be grouped under one parent line in the barcode app. Then, if the parent line is selected and a lot for their product is scanned, it will keep adding the quantity to the first subline even after it's completed. **Expected behavior:** Move lines for the same lot shouldn't be grouped under one parent if they are for different moves. **Steps to reproduce:** 1. Create a lot-trac
Original PR description
**Current behavior:** If a picking has two moves with move lines for the same lot-tracked product, they will be grouped under one parent line in the barcode app. Then, if the parent line is selected…
**Current behavior:**
If a picking has two moves with move lines for the same
lot-tracked product, they will be grouped under one parent line
in the barcode app. Then, if the parent line is selected and a
lot for their product is scanned, it will keep adding the
quantity to the first subline even after it's completed.
**Expected behavior:**
Move lines for the same lot shouldn't be grouped under one
parent if they are for different moves.
**Steps to reproduce:**
1. Create a lot-tracked product and some quant for it
2. Create a new delivery picking and add 1 move to it for the
lot product -> assign the picking
3. Add another move to the picking, again for the lot product
4. Open the picking in barcode, without expanding the sublines,
scan the lot created with the quant
5. When the parent line is complete, expand it to see that one
of the sublines has no quantity
6. Furthermore, validating the transfer at this point will
create a backorder despite it being technically completed
**Cause of the issue:**
The group key for sublines doesn't take into account the line's
move id.
**Fix:**
Add `line.move_id` to the group key for sublines.
Then, ensure when checking whether to merge some new lot scan
qty with an existing line in `_getNewLineDefaultValues()`, take
into account the lot details (not done prior to this commit).
Additionally, check all available barcode lines for a merge-able
line if there is not one currently selected.
Similarly, check that two barcode lines belong to the same
picking when in a batched context before allowing their
quantities to comingle.
opw-4185767
Forward-Port-Of: odoo/enterprise#77522
Forward-Port-Of: odoo/enterprise#70539This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. Runbot Errors: 111328, 111329 Related: https://github.com/odoo/odoo/pull/198506 Forward-Port-Of: odoo/enterprise#79646
Original PR description
This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. Runbot Errors: 111328, 111329 Related: https://github.com/odoo/odoo/pull/198506 Forward-Port-Of: odoo/enterprise#79646
**Current behavior:** If a picking has two moves with move lines for the same lot-tracked product, they will be grouped under one parent line in the barcode app. Then, if the parent line is selected and a lot for their product is scanned, it will keep adding the quantity to the first subline even after it's completed. **Expected behavior:** Move lines for the same lot shouldn't be grouped under one parent if they are for different moves. **Steps to reproduce:** 1. Create a lot-trac
Original PR description
**Current behavior:** If a picking has two moves with move lines for the same lot-tracked product, they will be grouped under one parent line in the barcode app. Then, if the parent line is selected…
**Current behavior:**
If a picking has two moves with move lines for the same
lot-tracked product, they will be grouped under one parent line
in the barcode app. Then, if the parent line is selected and a
lot for their product is scanned, it will keep adding the
quantity to the first subline even after it's completed.
**Expected behavior:**
Move lines for the same lot shouldn't be grouped under one
parent if they are for different moves.
**Steps to reproduce:**
1. Create a lot-tracked product and some quant for it
2. Create a new delivery picking and add 1 move to it for the
lot product -> assign the picking
3. Add another move to the picking, again for the lot product
4. Open the picking in barcode, without expanding the sublines,
scan the lot created with the quant
5. When the parent line is complete, expand it to see that one
of the sublines has no quantity
6. Furthermore, validating the transfer at this point will
create a backorder despite it being technically completed
**Cause of the issue:**
The group key for sublines doesn't take into account the line's
move id.
**Fix:**
Add `line.move_id` to the group key for sublines.
Then, ensure when checking whether to merge some new lot scan
qty with an existing line in `_getNewLineDefaultValues()`, take
into account the lot details (not done prior to this commit).
Additionally, check all available barcode lines for a merge-able
line if there is not one currently selected.
Similarly, check that two barcode lines belong to the same
picking when in a batched context before allowing their
quantities to comingle.
opw-4185767
Forward-Port-Of: odoo/enterprise#70539