Daily updates from Odoo
Thursday, November 14, 2024
27 changes
3 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>
Fixes an issue where the mailing editor sidebar could cover part of the editable email area after reopening a saved mailing based on a non-basic template. This helps users continue editing email campaigns without layout obstruction or confusion.
Original PR description
related commit: [1] Issue: ====== mass_mailing view is covered by the snippet sidebar Steps to reproduce the issue: ============================= - Create a new mass mailing with any template except the basic - Save it - Go back - Enter again to the mailing - The sidebar covers a part of the editable area Spec: ===== This is an application of the mentioned commit in the case when we don't have to select a new theme. opw-4227663 [1]: https://github.com/odoo/odoo/commit/3aa9a36ed47d0446e51c8dc991d0f7f6f2bacc80
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
1 change
Resolved issues and error corrections
The PDF viewer used for signing and document previews now hides built-in buttons that were unnecessary or could cause confusion. This creates a more consistent, focused experience when users review or sign documents.
Original PR description
The native viewer of PDF.js adds some buttons that we don't want as useless or problematic. This commit aims to uniformize add remove these buttons. task-4286512
19 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-prFixes an issue in the HTML editor color picker where choosing the radial gradient option that extends to the farthest corner would not stay selected on the first attempt. This makes gradient styling more predictable for users editing text or backgrounds.
Original PR description
**Behaviour before PR:** Steps to reproduce issue: - Add some text, select it. - Open color picker to apply text or background color. - Switch the gradient tab, select radial gradient type. - Try to…
**Behaviour before PR:** Steps to reproduce issue: - Add some text, select it. - Open color picker to apply text or background color. - Switch the gradient tab, select radial gradient type. - Try to select 4th option of size (extend to the farthest corner). - Selected option is deselected and gets switched to first option. - If we try to select it again then it gets selected. The issue happens because `fathest-corner` is the default size parameter for radial gradient. When we apply background-image property for farthest-corner it gets simplified later and rendered without keyword `'farthest-size'`. E.g.` radial-gradient(circle farthest-corner at 50% 50%, rgb(255,..` will be simplified to `radial-gradient(circle at 50% 50%, rgb(255,..` Due to this reason when we get background-image property using `style['background-image']` we get simplified value. As result in `setGradientFromString` method regex fails to extract the value of `'farthest-corner'` and `state.size` is set to `'closest-side'` which is our first option. **Desired behaviour after PR:** Now, default size is set to `'farthest-corner'` and 4th option is selectable. task-4240711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the translation button behavior when editing the base structure of form views. It helps administrators using technical settings access translations reliably after a previous interface structure change.
Original PR description
The html structure translation button is changed in https://github.com/odoo/odoo/pull/184900 This commit fixes the hack for the translation button for ir.ui.view.arch_base reproduce the bug Settings -> Technical -> Views -> open any form view  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
Order lines in Point of Sale and restaurant orders are now only marked as changed when they have actually been edited. This avoids unnecessary follow-up synchronization work and helps keep order status more accurate.
Original PR description
Before this commit, lines was always set as dirty when synchronizing orders. This was due to the fact that the line was marked as dirty in the synchronization process, even if the line was not modified. This commit fixes this issue by only marking the line as dirty if it has been modified. taskId: 4314110
This 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 fix adds a missing dependency so purchase orders can correctly calculate related repair counts. It prevents setup or loading issues when the repair and purchasing features are used together without relying on automatic module installation order.
Original PR description
The field [`purchase.order.repair_count`](https://github.com/odoo/odoo/blob/a4b21175dec1c09b0b02e31350de4b9848fa1728/addons/purchase_repair/models/purchase_order.py#L8-L13) depends on field `order_line.move_dest_ids.repair_id`, and [`move_dest_ids`](https://github.com/odoo/odoo/blob/a4b21175dec1c09b0b02e31350de4b9848fa1728/addons/purchase_stock/models/purchase_order_line.py#L28) is defined in module `purchase_stock`, but it is not an explicit dependency and the autoinstall does not guarantee the existence of the module. Fixing the dependency to ensure the field `purchase.order.repair_count` can be computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the background color used in the outstanding credits section of customer invoices when dark mode is enabled. It improves readability and visual consistency for users reviewing invoice credits.
Original PR description
Fix the background color for customer invoices on the outstanding credits section. task-4326841 --- 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
The Discuss app now displays the Threads and Invite People popovers at a stable width, preventing unwanted horizontal scrolling. This makes these actions easier to read and use, especially in constrained panel layouts.
Original PR description
Before this commit, the "Threads" and "Invite People" actions in Discuss app could overflow and have horizontal scroll. This happens because the `ActionPanel` has some responsive width when in a…
Before this commit, the "Threads" and "Invite People" actions in Discuss app could overflow and have horizontal scroll. This happens because the `ActionPanel` has some responsive width when in a panel, but these panels could also be displayed in popover in which this rule shouldn't apply. This commit fixes the issue by fixing a constant width to these action panels in popover, with similar width as the messaging menu. Task-4292021 Before / After - Threads <img width="400" alt="Screenshot 2024-11-13 at 18 42 41" src="https://github.com/user-attachments/assets/5701333c-9623-4ae8-bc10-0900251d353f"> <img width="593" alt="Screenshot 2024-11-13 at 18 45 41" src="https://github.com/user-attachments/assets/62393043-5a88-468d-acde-7fbee837be2e"> Before / After - Invite People <img width="407" alt="Screenshot 2024-11-13 at 18 42 48" src="https://github.com/user-attachments/assets/03025c09-1e9c-4790-a708-627f0aa731ec"> <img width="691" alt="Screenshot 2024-11-13 at 18 43 10" src="https://github.com/user-attachments/assets/8ef9ad7c-d7b1-4a44-a0b3-f1e4525e0fa4">
This fix speeds up an automated website menu editing test so it is less likely to fail because of timing limits. It helps keep quality checks reliable without changing the customer-facing website experience.
Original PR description
In this commit, we force checkDelay to 100ms (default is 500ms) to make the tour faster and avoid script timeout exceeded error. 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
This fix removes an unnecessary warning from the mail-related logs by correcting how a text replacement option is passed internally. It helps keep system logs cleaner and avoids distracting administrators with a harmless technical warning.
Original PR description
Description of the issue/feature this PR addresses: Passing the regex flags in place of positional argument `count` generates a warning. Pass correct argument to `re.sub()` Current behavior before PR: Warning appears in log about incorrect use of positional parameter `count`. Desired behavior after PR is merged: No warning appears in log by `mail` addon due to usage of `re.sub`. --- 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>
A typo in the sale PDF quote builder test was corrected. This helps keep automated checks reliable and prevents false test failures during development.
Original PR description
There was a typo in test_pdf_qoute_builder. This commit corrects it. [broken test](https://runbot.odoo.com/web#id=74907&view_type=form&model=runbot.build.error&menu_id=405&cids=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers paying through Worldline are now sent back to the website where they started checkout, even when the business runs multiple websites. This prevents users from landing on the wrong site after payment and keeps the checkout experience consistent.
Original PR description
In multi-website context, we should return the user to the root of the origin website which is not necessarily the same as the one from `web.base.url` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an installation problem where the Repair module could fail if Inventory was already installed but not yet updated. The change makes the Repair setup compatible with both older and newer Inventory layouts, reducing upgrade and installation interruptions.
Original PR description
Following https://github.com/odoo/odoo/pull/186831, the installation of the repair module would fail if stock was previously installed without upgrading it first. This is due to the new xpath defined…
Following https://github.com/odoo/odoo/pull/186831, the installation of the repair module would fail if stock was previously installed without upgrading it first. This is due to the new xpath defined in the repair module that reference the changed form in the stock module. However, if stock wasn't upgraded, then the new label / div don't exist yet, leading to an error as the xpaths link to something that doesn't exist yet. This means that this patch needs to work with two possible versions of stock: - The old one, with only <field> in the form - The new one, with <field> and <label> in the form Due to that singular situation, it made the declaration of xpath in repair impossible to have a proper target, as both versions of stock would require different targets and cannot co-exist. To solve that situation, the choice was made to overwrite completely the common ancestor of the two versions (i.e. the locations <group>) and write it back in repair as if every previously declared xpath have been applied to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in Belgian reporting where a description could be too short for expected form requirements. It helps keep generated tax/reporting forms compliant and reduces the risk of validation errors during submission.
Original PR description
The aim of this commit is Context: Before the commit: After the commit: Community-PR: Enterprise-PR: Upgrade-PR: task-id:
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#186833Sign request emails now use the recipient-selected language consistently across both the message body and email layout. This avoids mixed-language emails, making signature requests clearer and more professional for recipients.
Original PR description
**Email layout is not translated to targeted sender's language with Sign mails** Impacted versions: - 18.0 Steps to reproduce: 1. Create a partner with language other than the current user's language. 2. Create a sign request and send the request to the created partner. 3. The strings from the email layout like Odoo's `Powered By` and `Your Document` (Your Signature Request) are not translated to the partner's language, but translated with the user's language. This differs from the language in the body. Current behavior: Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies. Expected behavior: After this commit, only the language given in the kwargs is used and therefore fixing the translations issues.
4 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 ---
This update ensures quality checks are only triggered for products that have actually been received into inventory. Previously, a product could trigger a quality check even if it was part of a pending order. This change corrects a bug related to backorders, improving inventory accuracy and preventing unnecessary quality check processes.
Original PR description
**Steps to reproduce the bug:** - Create a tracked product by SN: “P1.” - Create a storable product: "P2." - Create a receipt for one unit of P1 and P2. - Mark it as "To Do." - Set the done quantity of P1 to 0. - Attempt to perform the quality check. **Problem:** You must perform a quality check for P1 even though it has yet to be received. Since the move_line is set to 0 rather than deleted in the original picking, it will be linked to the backorder when it is created. Therefore, to avoid unexpected behavior we can ignore linking its quality check to the backorder. https://github.com/odoo/odoo/blob/00057f8efd3c728e13a981290a725878e058d2c6/addons/stock/models/stock_picking.py#L832 opw-4187521