Friday, August 2, 2024
14 changes · 17.0
Resolved issues and error corrections
This fixes an internal Spanish electronic invoicing test that could fail when CRM demo data was installed. The test now uses its own customer details, making validation more reliable without changing user-facing behavior.
Original PR description
__Current behavior before commit:__ If `crm` is installed `test_import_multiple_invoices` will fail because the crm demo data are changing the email of the partner `base.res_partner_12` (i.e. Azure…
__Current behavior before commit:__
If `crm` is installed `test_import_multiple_invoices` will fail because the crm demo data are changing the email of the partner `base.res_partner_12` (i.e. Azure Interior)(see [crm_lead_demo.xml][1]). `partner` will therefore be `False`.
__Description of the fix:__
Getting `partner` from the `base.res_partner_12` external id so this test does not depend on modifications from other modules.
__Steps to reproduce the issue:__
Run:
```sh
./odoo/odoo-bin -d test-17 -i crm,l10n_es --test-tags .test_import_multiple_invoices --addons-path=./enterprise,./odoo/addons
```
You will get:
```log
odoo.addons.l10n_es_edi_facturae.tests.test_edi_xml: FAIL: TestEdiFacturaeXmls.test_import_multiple_invoices
Traceback (most recent call last):
File "/home/odoo/src/odoo/addons/l10n_es_edi_facturae/tests/test_edi_xml.py", line 283, in test_import_multiple_invoices
self.assertRecordValues(moves, [
File "/home/odoo/src/odoo/odoo/tests/common.py", line 659, in assertRecordValues
self.fail('\n'.join(errors))
AssertionError: The records and expected_values do not match.
==== Differences at index 0 ====
---
+++
@@ -1 +1 @@
-partner_id:14
+partner_id:False
==== Differences at index 1 ====
---
+++
@@ -1 +1 @@
-partner_id:14
+partner_id:False
```
opw-4009379
[1]: https://github.com/odoo/odoo/blob/1c8e2555366fe6e6b0d74d6db71a29d09bd5f06a/addons/crm/data/crm_lead_demo.xml#L606This fix prevents manufacturing cost account settings from being automatically recalculated when they are being edited directly. It helps avoid unintended changes to accounting configuration during manufacturing-related updates.
Original PR description
Adding a condition in _get_stock_account_property_field_names to avoid recomputing the property_stock_account_production_cost_id value. task-id: 3646156 enterprise: https://github.com/odoo/enterprise/pull/65904/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves logging around device websocket activity so support teams can more easily see when device actions complete and how long they take. Detailed message information is kept at a lower debug level, reducing noise in normal logs while preserving troubleshooting detail when needed.
Original PR description
Add some logs to log relevant information in various websocket scenarios. Like odoo logs for HTTP request, the completion of the operation is logged in INFO level with the execution time. e.g: `2024-08-02 09:32:20,542 1821 INFO ? odoo.addons.hw_drivers.websocket_client: device 'Virtual_Braille_BRF_Printer' action finished - 0.077` Detailed logs of the websocket message were set in DEBUG Replace the PR: https://github.com/odoo/odoo/pull/169525 to only keep the log part
Sales order totals now stay consistent when the tax rounding setting is changed. This prevents outdated totals from appearing in sales order lists, helping users see accurate order values across views.
Original PR description
Steps to reproduce: - Install "Sales" and "Accounting" - Make a sale order with two order lines: - Product with price of 10.5 and tax of 7% - Product with price of 10.99 and tax of 7% - Total will now depends on rounding_method used (22.99 as total or 23.00) Issues: If you change the settings the total will be updated on the sale order since it's computed by JS code however on the list view the field `amount_total` will show the previous value. This is because the compute is not triggered after changing the rounding method as it's missing in it's dependencies. opw-4035724
The barcode command labels in the Manufacturing work order system have been updated from "CONTINUE/PAUSE" to "CONTINUE/START" for better clarity. This change improves the user experience by using more intuitive terminology for barcode-based operations in the manufacturing workflow.
Original PR description
Part of a UI task. Changed CONTINUE/PAUSE to CONTINUE/START Regenerated the PDF file task-id: 3646156 community: https://github.com/odoo/odoo/pull/171616
This update fixes an issue where delivery tests were failing when run without demo data. The tests were referencing a demo partner ('Deco Addict') that doesn't exist in no-demo environments. The fix ensures tests create the necessary partner data when needed, making the test suite more reliable across different configurations.
Original PR description
The Issue: Before this commit, the test always assumed the existence of the 'Deco Addict' partner. However, in the 'no demo' test, we run tests without demo data, so this partner does not exist. The Fix: Create the demo Partner runbot-58765
Miscellaneous changes
Steps to reproduce: - In website edit mode. - Click on the header. - Select the "Vertical" template in the "Header" options. - Drag and drop a "Search" block from the inner content section into the header. - Click on the header. - Select "On Hover" for the "Sub Menus" option of the "Navbar". - Save the page. - Enter a letter (e.g., "a") in the search input. - Click outside the page to lose the focus on the input. - Hover over the search results with the mouse. - Traceback: "Cannot r
Original PR description
Steps to reproduce: - In website edit mode. - Click on the header. - Select the "Vertical" template in the "Header" options. - Drag and drop a "Search" block from the inner content section into the header. - Click on the header. - Select "On Hover" for the "Sub Menus" option of the "Navbar". - Save the page. - Enter a letter (e.g., "a") in the search input. - Click outside the page to lose the focus on the input. - Hover over the search results with the mouse. - Traceback: "Cannot read properties of null (reading 'blur')" The bug occurred after commit [1], which didn't account for a dropdown missing a "dropdown-toggle" element. [1]: https://github.com/odoo/odoo/commit/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4 opw-4012850 Forward-Port-Of: odoo/odoo#175309
Steps to reproduce the bug: - Create a storable product “P1” with BoM - Component: 1 unit of C1 tracked by Serial Number - Update the quantity of P1 with “SN1” - Create a MO to produce one unit of P1: - Confirm it - Select “SN1” for C1 - Validate the MO - Create a repair order to remove C1 from P1 and confirm, start, and complete the repair: - Destination location: WH/Stock - Serial Number: “SN1” - Perform the same steps to add C1 (SN1) into P1 again. -
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM - Component: 1 unit of C1 tracked by Serial Number - Update the quantity of P1 with “SN1” - Create a MO to produce one unit of…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM
- Component: 1 unit of C1 tracked by Serial Number
- Update the quantity of P1 with “SN1”
- Create a MO to produce one unit of P1:
- Confirm it
- Select “SN1” for C1
- Validate the MO
- Create a repair order to remove C1 from P1 and confirm, start, and complete the repair:
- Destination location: WH/Stock
- Serial Number: “SN1”
- Perform the same steps to add C1 (SN1) into P1 again.
- Remove C1 (SN1) a second time.
* After these steps, C1 with SN1 is available in stock.
- Create a new MO to produce one unit of P1:
- Confirm and select “SN1” for C1
- Try to validate it
Problem:
When checking the availability on the MO, SN1 is correctly
reserved. However, when marking the second MO as done, a User Error is
displayed: "The serial number SN1 used for component C1
has already been consumed."
opw-4029309
Forward-Port-Of: odoo/odoo#173355
Forward-Port-Of: odoo/odoo#173191Steps to reproduce the issue: - Debug mode > Settings > Technical > Decimal Precision > Product Price - Set to another number - Purchase > Any Purchase order - Mobile view, puchased item has a decimal precision of 2 Why is this a bug: Kanban view is the only one to disregard Product Price Precision setting What this fix does: Update the display with correct decimal precision opw-3984082 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr F
Original PR description
Steps to reproduce the issue: - Debug mode > Settings > Technical > Decimal Precision > Product Price - Set to another number - Purchase > Any Purchase order - Mobile view, puchased item has a decimal precision of 2 Why is this a bug: Kanban view is the only one to disregard Product Price Precision setting What this fix does: Update the display with correct decimal precision opw-3984082 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172049
### Steps to reproduce: - Install the 'l10n_sa' module and switch to a saudi company - Install the Arabic language - Go in Accounting > Customers > Invoices and create a new one - Add an internal note with a list (using /) - Add a translation in arabic with the "EN" button - Click Preview - The points of the list appear in the middle of the page ### Cause: The lists are not adapted to be displayed from right to left. ### Solution: Add the option `dir="rtl"` in the span of the Arab
Original PR description
### Steps to reproduce: - Install the 'l10n_sa' module and switch to a saudi company - Install the Arabic language - Go in Accounting > Customers > Invoices and create a new one - Add an internal note with a list (using /) - Add a translation in arabic with the "EN" button - Click Preview - The points of the list appear in the middle of the page ### Cause: The lists are not adapted to be displayed from right to left. ### Solution: Add the option `dir="rtl"` in the span of the Arabic text to make the lists appear the right way. opw-4043175 Forward-Port-Of: odoo/odoo#175333 Forward-Port-Of: odoo/odoo#174541
Step to reproduce: - install l10n_in - create an invoice - select an Indian customer with GSTIN - change delivery address to other indian customer without GSTIN - print report, call it "report 1" - change delivery address to other indian customer with GSTIN - print report, call it "report 2" Current behavior: For report 1: - The GSTIN value of the partner_id appear twice on the report For report 2: - The GSTIN value of the partner_id appear twice - The GSTIN value of the
Original PR description
Step to reproduce: - install l10n_in - create an invoice - select an Indian customer with GSTIN - change delivery address to other indian customer without GSTIN - print report, call it "report 1" - change delivery address to other indian customer with GSTIN - print report, call it "report 2" Current behavior: For report 1: - The GSTIN value of the partner_id appear twice on the report For report 2: - The GSTIN value of the partner_id appear twice - The GSTIN value of the delivery partner does not appear Expected behavior: - The GSTIN value of partner_id should not appear twice - If exist, the GSTIN value of delivery partner should be shown opw-4027540 Forward-Port-Of: odoo/odoo#173655
Translated text that contains multiple interpolated values should always use named placeholders. Otherwise, sprintf will always insert the values in the same order, which may not match the order of the placeholders after translation in a language with a different syntax. Forward-Port-Of: odoo/odoo#175332
Original PR description
Translated text that contains multiple interpolated values should always use named placeholders. Otherwise, sprintf will always insert the values in the same order, which may not match the order of the placeholders after translation in a language with a different syntax. Forward-Port-Of: odoo/odoo#175332
Currently, when a loyalty program has a reward of type product and uses `reward_product_tag_id` (set up for at least 2 products), the addition of rewards to the pos order will have mismatched reward lines when adding the second free product (the first product needed to be added first). Steps to reproduce: ------------------- * Go to **Point of Sale** App * Go to **Products** and add a tag (the same) for two products * Under **Products** select `Discount & Loyalty` * Create a new program
Original PR description
Currently, when a loyalty program has a reward of type product and uses `reward_product_tag_id` (set up for at least 2 products), the addition of rewards to the pos order will have mismatched reward…
Currently, when a loyalty program has a reward of type product and uses `reward_product_tag_id` (set up for at least 2 products), the addition of rewards to the pos order will have mismatched reward lines when adding the second free product (the first product needed to be added first).
Steps to reproduce:
-------------------
* Go to **Point of Sale** App
* Go to **Products** and add a tag (the same) for two products
* Under **Products** select `Discount & Loyalty`
* Create a new program of type **Buy X Get Y**
* Rule:
* Min qty: 2 products $0.00
* Among Products: Put all chairs products for example
* Reward:
* Type: Free Product
* Product: None
* Product tag: The tag put on the products previously
* Open shop session
* Add 2 chairs
* Select reward, add the first one
> Everything ok until now
* Add 2 chairs
* Select reward, add the second one
> Observation: Reward computation is wrong we have the following lines:
```
4 Chairs,
Reward 1,
Reward 2,
Free product reward 1
```
> We are missing the free product line related to the second product added and the button to select reward is still highlighted.
Why the fix:
------------
To explain this fix I will use the example given above.
Here are the steps that have been executed already
* Add 2 chairs
* Add the first reward product
* Add 2 chairs
We are currently in the middle of the step "Add second reward product". During that process, we end up in the function `_computeUnclaimedFreeProductQty` while computing values for the reward line. At this very moment in time, the order has the following lines:
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2
Where Product 1 and Product 2 are the reward products, having the same tag.
Let's focus on this piece of code, with the current example: https://github.com/odoo/odoo/blob/76023820c4d725c81677d2bf3e010c8cee1edd19/addons/pos_loyalty/static/src/js/Loyalty.js#L1464-L1475
Where `product` in this case is `Product 2`. What is happening here at the end is that we have `available = 1` because of line 4 and `claimed = 1` because of line 3. The program considers that we have already claimed the quantity and is the reason why it is not adding the reward line.
The first idea to fix this issue was to write the condition:
```js
if (reward.reward_product_ids.includes(product.id) && reward.reward_product_ids.includes(line.product.id)) {
```
instead of this one
```js
if (line.get_product().id === product.id) {
```
Now both line 2 and 4 are counted toward the `available` quantity. This way the code knows that we have two availaible free product but only 1 was claimed.
While this fixed the original issue, a new issue was created. Now, when we add the second product, the two reward lines were grouped together, using the price of the first free product added. Why was this happening?
Well, once the fist call to the function `_computeUnclaimedFreeProductQty` was done and the reward line was added we had the following order (temporarily)
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2
* Free product (related to Product 2)
Which is what we expect but we face an issue when the loyalty programs are updated. When the programs update, we go through the function `_updateRewardLines`. In this function we discard the reward lines from the order and then for each claimed reward (Product 1 and Product 2) we re-apply the reward.
While applying the reward for Product 1, we again go through the function `_computeUnclaimedFreeProductQty`. In this case, the order looks like this:
* 4 Chairs
* Product 1
* Product 2
and the function will say that there are 2 available free product and 0 claimed. Were it is technically true, in this case we want to have the available quantity to 1. We want the initial condition:
```js
if (line.get_product().id === product.id) {
```
In the second passage, for product 2, we have `available = 2` and `claimed = 2`.
opw-3587020
Forward-Port-Of: odoo/odoo#173529Since #169396, the hr_expense_test_tour is failing on community nightly runs as the "save the new report" step does not succeed without demo. runbot-70701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174476
Original PR description
Since #169396, the hr_expense_test_tour is failing on community nightly runs as the "save the new report" step does not succeed without demo. runbot-70701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174476