Daily updates from Odoo
Thursday, November 14, 2024
11 changes
2 changes
Resolved issues and error corrections
This update brings the spreadsheet component up to the latest version for this Odoo release. It fixes date-based line charts and improves the color picker by only showing the reset option when it is relevant, making spreadsheet reports more reliable and easier to use.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/19b7478cf [REL] 17.2.26 Task: 0 https://github.com/odoo/o-spreadsheet/commit/31a9ad664 [FIX] chart: date line chart Task: 4268977 https://github.com/odoo/o-spreadsheet/commit/d4d8a43a4 [FIX] color_picker: conditionally hide reset button Task: 4102704 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Refunds in Point of Sale no longer incorrectly block normal loyalty-program products as if they were gift cards or eWallets. This prevents unnecessary refund errors when loyalty rules are tied to specific products, improving checkout support and customer service workflows.
Original PR description
When adding a rules in loyalty program that had a product set, if you try to refund an order containing this product you would get an error Steps to reproduce: ------------------- * Create a loyalty program with a rules that has product_ids set to any product. * Open PoS and make an order with the product set on the loyalty program * Validate the order * Try to refund the order > Observation: You get an error saying you cannot refund giftcards or eWallets Why the fix: ------------ This was happening because `trigger_product_ids` is related to `rule_ids.product_ids`. And when checking if a product is a giftcard or eWallet we first checked that `trigger_product_ids` was set. Now we only check the type of the program linked to a product. opw-4206226 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
6 changes
Resolved issues and error corrections
Creating a new item from a many-to-many tag field now keeps relevant default information, such as a preselected product, when using Save & New. This prevents users from having to re-enter expected values and reduces mistakes during repeated record creation.
Original PR description
Have a field with many2many_tags widget and a context containing `default_` keys (e.g. `{'default_product_id': 45}`). Type something in the input and click on "Create and edit". In the dialog, the name should be prefilled with the value you typed in the input. Moreover, the product should be set to product 45. Click on "Save & New". Before this commit, all fields were empty, because we removed from the context all `default_` keys.
This is correct to remove the `default_name` key, as we already created that record. However, we must keep the others.
This issue has been introduced with the wowl implementation of the Many2ManyTagsField/FormViewDialog.
task~4331742
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-prThis fixes a timing issue in the payment form by ensuring the system waits for the payment request to complete before continuing. It helps avoid incomplete or inconsistent payment flows for customers during checkout.
The manufacturing work order list now uses clearer compact icons for key actions and better signals when a work order is blocked. This makes daily shop-floor task management easier to scan and reduces layout issues in list views.
Original PR description
Duplicate of https://github.com/odoo/odoo/pull/134187 but without the dirty css hack --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could block users when closing a Point of Sale session after recording a negative payment difference. The session can now proceed without showing a technical traceback, improving reliability during register closing.
Original PR description
When the customer tries to close the pos session, a traceback will appear. Steps to reproduce the error: - Go to Point of Sale > Configuration > Payment Methods > Create new > In Journal: Bank > Save…
When the customer tries to close the pos session, a traceback will appear. Steps to reproduce the error: - Go to Point of Sale > Configuration > Payment Methods > Create new > In Journal: Bank > Save - Open a session > Add a product > Payment > select that payment method > validate - Close Register > Now in count, Add such a number so that the difference will become negative > Close Register > Proceed Anyway Error: A traceback appears: ``` "TypeError: cannot unpack non-iterable bool object" ``` When the customer closes the pos session, ``_apply_diff_on_account_payment_move`` method will be called. It will call ``_get_diff_vals`` method. When ``_get_diff_vals`` method returns the ``False``, https://github.com/odoo/odoo/blob/5a390fede312513a5c9b91d2d18d6d0cfdd43750/addons/point_of_sale/models/pos_session.py#L622-L634 So Here, ``source_vals``, ``dest_vals`` will be ``False`` https://github.com/odoo/odoo/blob/5a390fede312513a5c9b91d2d18d6d0cfdd43750/addons/point_of_sale/models/pos_session.py#L1094 So, It will lead to the above Traceback. sentry-5607468115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes the spreadsheet component to the latest version and fixes issues affecting chart display and color selection. Users should see more accurate date line charts, improved area chart trend lines, and a cleaner color picker experience.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/88e1aeeb4 [REL] 18.0.4 Task: 0 https://github.com/odoo/o-spreadsheet/commit/bb046c5db [FIX] chart: date line chart Task: 4268977 https://github.com/odoo/o-spreadsheet/commit/064a7cf84 [FIX] color_picker: conditionally hide reset button Task: 4102704 https://github.com/odoo/o-spreadsheet/commit/2cb20cee6 [FIX] chart: trend line of area chart Task: 4274294 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes a receipt printing problem in Italian point of sale setups when rounding is applied to discounted totals. Cash registers should no longer enter an error state for small rounding adjustments, helping checkout continue smoothly.
Original PR description
When a rounding amount is sent to the cash register, the printer goes into error.
e.g.
```
Product price 1,21
rounding -0,01
total 1,20
```
There is a code in the XML receipt which must be quoted as a string value.
When writing the rounding without it, the printer crashes.
CLA signed here: odoo/odoo#1868333 changes
Resolved issues and error corrections
This update strengthens how Odoo detects failed invoice cancellations for Brazilian e-commerce (BR-EDI). Previously, the system only checked for a specific 'error' key in the response, which wasn't reliable due to various government rejection reasons. Now, the system checks for the return of XML data, ensuring a failed cancellation is detected regardless of the specific reason.
Original PR description
Before, we relied on just _l10n_br_get_error_from_response() which checks for the presence of an "error" key in the response. Unfortunately that only seems to catch errors directly raised by Avalara. The government can reject the cancellation for a myriad of reasons [1]. We could hardcode all successful status codes (24 codes), but to be more robust in case the codes change we just look if any XML is returned. The lack of XML response should reliably indicate that the cancellation failed. [1] 4.4. Lista das Regras de Validação in https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=J%20I%20v4eN00E=
This update resolves an issue where recomputing taxes on locked sales orders triggered errors, preventing users from completing actions like sending emails. The fix prevents tax recalculation when sending emails from locked orders, addressing a user error blocking functionality. This ensures locked orders remain unchanged and reliable.
Original PR description
1. Set up Avatax on the current company 2. In Settings > Sales > Quotations& Orders active 'Lock Confirmed Sales' 3. Create a SO with fiscal position 'Automatic Tax Mapping (AvaTax)' 4. Add a partner and product having avatax category defined 5. Compute taxes 6. Confirm order, it will be automatically locked 7. Click "Send by Email" Issue: Action will be blocked by User Error ``` It is forbidden to modify the following fields in a locked order ``` This occurs because when sending by email we recompute external taxes, but it should not be the case for locked orders It also occurs on the web shop when finalizing the payment opw-4261396
This update resolves an issue where the barcode app wasn't correctly creating stock move lines when splitting MTO (Multiple Throughput Order) moves. The fix ensures that when a user splits a delivery using the barcode app, new move lines are generated, allowing the app to accurately track inventory. This prevents a single line from appearing in the barcode app.
Original PR description
### Steps to reproduce: - In the settings: enable multi-steps route - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable prodcut with MTO, buy routes and a…
### Steps to reproduce: - In the settings: enable multi-steps route - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable prodcut with MTO, buy routes and a set vendor - Create and confirm a sale order for 3 units of your product - Confirm the purchase order and the associated reciept - Go to the barcode app on you delivery - set the quantity to 1/3 and leave the barcode app - Go back to the the delivery ### > only one line 1/1 appears ### Cause of the issue: The barcode app relies on stock move lines to work properly. These move lines are even in correspondance with the barcode lines. When you update a line in the barcode to be 1/3 and then leave the app, to keep track of the demand, the app split the moves in 2: https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L9-L11 To create the new barcode lines, it is therefore expected that new move lines will be created by this call for the splitted move. which is the purpose of this line: https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L37 However, this will only work for moves whose procure method is not MTO because mto moves are not confirmed but flaged as waiting and hence not assigned by the `_action_confirm`: https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1356-L1362 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1380 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1418-L1422 As a result no move line will be generated for these splitted mto moves and there will be no stock move line for the barcode to rely on. opw-4232106 ---