Daily updates from Odoo
Wednesday, April 3, 2024
24 changes
2 changes
Resolved issues and error corrections
Bank statement reports now show the latest running balance correctly when balances are grouped. This prevents misleading totals in accounting views and helps finance teams rely on the displayed cash position.
Original PR description
Since https://github.com/odoo/odoo/pull/127353, the web client only asks for the aggregatable field, making the read_group override of 'account.bank.statement.line' becomes ineffective. Remove the check done on fields, and always return the latest running_balance by group. https://github.com/odoo/enterprise/pull/59936
This fix allows Brazilian PIX QR codes to work even when no payment amount is included, which is important for offline point-of-sale use. It helps cashiers continue accepting PIX payments in situations where the final amount must be entered later or connectivity is unavailable.
Original PR description
Since this commit we support the QR code without amount To be used in the POS when the POS is offline. Introduced by: https://github.com/odoo/odoo/pull/148803/commits/f286e2c0473c568991171ef8c0b2dbb9871d2f2e 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
22 changes
Resolved issues and error corrections
Fixed an issue where the "Create Invoice" button was not appearing when selecting tasks in the Field Service module. The problem was caused by an incorrect context key that was being automatically removed by the system. The fix uses the correct context key to ensure the button displays properly when users select tasks to invoice.
Original PR description
### Steps to reproduce issue: 1. Go to _Field Service > All Tasks > To Invoice_ - If no task is shown, remove To Invoice filter 3. Click on the checkbox of a task 4. The button Create Invoice should appear next to the Print and Actions buttons but it does not ### Explanation: The context key used to show the element contains a `search_default` prefix. Keys with this prefix are specifically used to create a search filter and are deleted in the process. https://github.com/odoo/odoo/blob/71c81e605b2f06889ad8031f021863638edab268/addons/web/static/src/search/search_model.js#L291-L300 ### Suggested fix: No existing key in the context is specific to the action nor is their value. Adding a new specific context key prevents unintended behaviours. opw-3773005
This fix corrects how shipping rates are selected from Sendcloud. Previously, the system was comparing prices as text rather than numbers, causing it to sometimes choose more expensive shipping options (e.g., selecting $11.00 instead of $9.00). The fix ensures prices are properly converted to numbers before comparison, so customers always get the lowest available shipping rate.
Original PR description
Before this commit, the lowest shipping rate was used as the delivery cost, as in: https://github.com/odoo/enterprise/blob/8c40ba77b23c4ccd24c3785bc1e6cf5b3fbe0e51/delivery_sendcloud/models/sendcloud_service.py#L91 However, the prices received from the Sendcloud are strings, and as a result, this line returned the rate with the lowest lexicographical order. As a result, sometimes the rates with a higher value were chosen. The issue happens when a shipping product costs a single digit amount (e.g. `9.00`) but a second product costs in double digits (e.g. `11.00`). In this case the latter is used which is wrong. This commit, converts the prices to float before comparing them to get the actual best price. opw-3815117
This update fixes a system crash that occurred when UPS shipping alerts lacked a description field. The system now properly handles alerts from UPS regardless of whether they include descriptions, ensuring smooth delivery processing without interruptions.
Original PR description
It happens that the alerts message returns by UPS doesn't contains a descirption. In that case the dictionary has no key and traceback. Only returns alerts with description Forward-Port-Of: odoo/enterprise#59606
This fix corrects an issue where custom field labels in worksheets were not displaying correctly for portal users. When a worksheet field had a custom label (like "Proute" for an ID field), portal users would see the default field name instead. The fix ensures that custom labels are properly used when available, improving the consistency of the worksheet experience across all users.
Original PR description
Steps: In the default worksheet template, add the field "ID" and change its label as "Proute". Go to a helpdesk ticket, and create a worksheet. See that the label is "Proute". Now share it with a portal user. Log in as that user, and go on the ticket. Issue: The label of the worksheet's field is "ID". Cause: The back-end template uses `<field name="id" string="Proute">`. It is then translated to a qweb as `<div string="Proute">ID</div>` because it sets the name of the field as the description. Fix: Set the string of the tag if any, or else the name of the field. task-3479545 Forward-Port-Of: odoo/enterprise#47803
This update removes an outdated field from the appointment calendar view that was previously replaced with a newer resource management system. The change ensures the calendar interface displays only current, relevant fields and prevents confusion from duplicate or obsolete options.
Original PR description
Hide correctly appointment_resource_id in the calendar event form view as it has been replaced by resource_ids. task-3839587
This update adds database indexes to speed up the deletion of partner records. Previously, deleting a partner required the system to scan entire tables to find and update related records, which could take a long time. With these new indexes, the system can now quickly locate the relevant records, making partner deletion significantly faster and more efficient.
Original PR description
Deleting a partner may take a long time because odoo has to check an entire table to find few records or no records at all that reference the partner and set it to null. So we are adding an index btree not null to speed up the deletion of partners. TASK-ID: 3759406
Fixed an issue where importing FEC files with journals having the same name but different codes would cause errors when trying to create duplicate mail aliases. The system now prevents automatic mail alias creation during FEC imports, allowing users to add them manually later if needed.
Original PR description
It is possible that a FEC file contains journals with different codes but same name. In such case, each of these would try to create a distinct mail alias with the same name ; this is not allowed and raised an error. We now prevent that by not generating any mail alias by default on journals imported via FEC. They can still be added later on by the user if he wishes to do so. OPW 3813584 Forward-Port-Of: odoo/enterprise#59859 Forward-Port-Of: odoo/enterprise#59527
This fix resolves a problem that occurs when the IoT application is uninstalled from a Point of Sale system. Previously, an internal flag was not being reset during uninstall, which caused errors when trying to install other modules afterward. The fix ensures the flag is properly cleared when IoT is removed, preventing installation failures in related modules.
Original PR description
In `pos_enterprise` we alias `is_posbox` as `module_pos_iot`. If the value is True we install the module `pos_iot` when a write in pos.config model happens:…
In `pos_enterprise` we alias `is_posbox` as `module_pos_iot`. If the value is True we install the module `pos_iot` when a write in pos.config model happens:
https://github.com/odoo/odoo/blob/f7ee5633a8c80afca05074b8574e9c2a720e4bc9/addons/point_of_sale/models/pos_config.py#L496
Steps to reproduce:
1. Install PoS and IoT applications -- will install `pos_enterprise` module.
2. Set is_posbox = True, via the PoS settings.
3. Uninstall IoT application -- will uninstall `iot` and `pos_iot` modules.
4. Try to install a module that writes in a column of the pos_config with is_posbox=True
We get an error like:
```
...
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_module.py", line 569, in _button_immediate_function
raise UserError(_('The method _button_immediate_install cannot be called on init or non loaded registries. Please use button_install instead.'))
odoo.exceptions.UserError: El método _button_immediate_install no puede ser llamado en registros init o no cargados. Por favor, utilice button_install en su luga
```
The issue is that when we uninstall `iot` module the flag is never reset. This then causes issues if we try to install a module that writes on any value of `pos.config`. Observed during upgrades, e.g `l10n_es_pos` at xml load of data files. Other modules also affected.
The solution we propose here is to introduce a _soft_ dependency between pos_iot -- which is an enterprise module -- and pos_enterprise. The former checks at uninstall if the latter is installed to clear the `is_posbox` flag.
Forward-Port-Of: odoo/enterprise#59810This update resolves multiple issues discovered during months of WhatsApp integration usage. It fixes template duplication problems, message retry failures, variable naming inconsistencies, and prevents system crashes in specific scenarios. The changes also enable sending messages with templates flagged as lower-risk quality warnings and improve overall system stability.
Original PR description
Provide fixes after some months of using WhatsApp. See sub tasks / sub PRs for more details, each being related to a specific issue to fix. Task-3807017, master fix task Contains fixes done for…
Provide fixes after some months of using WhatsApp. See sub tasks / sub PRs for more details, each being related to a specific issue to fix. Task-3807017, master fix task Contains fixes done for following tasks / tickets * Task-3619004 (WhatsApp: Fix variable computation and name) * Task-3680030 (WhatsApp: Fix buttons / template duplication) * Task-3829328 (WhatsApp: Allow to send yellow quality templates) * Task-3644990 (Whatsapp: Fix retrying message with report on template) * Task-3679715 (WhatsApp: Fix cron block or crash with shared users) * Task-3576712 (WhatsApp: Sync template attachments at sync, avoid missing) * Task-3640336 (WhatsApp: Fix Document Header / Report mismatch) * Task-3605612 (WhatsApp: Fix header / upload / reporting usage) * Task-3640336 (WhatsApp: Fix Document Header / Report mismatch) * Task-3794483 (WhatsApp: Add account information in template views) * Task-3794365 (WhatsApp: Ease module / variable name change) * Task-3691887 (WhatsApp: Avoid draft templates in event mail schedulers) * Task-3732188 (Whatsapp Event: Avoid crashing registration process) Co-Authored-By: Amélie Dieudonné <amdi@odoo.com> Co-Authored-By: Akshat Trivedi <aktr@odoo.com> Co-Authored-By: Dato Nefaridze <dane@odoo.com> Co-Authored-By: Nishant Jain <niai@odoo.com> Co-Authored-By: Rahul Prajapati <rapr@odoo.com> Co-Authored-By: Noé Antoine <nan@odoo.com> Co-Authored-By: Thibault Delavallée <tde@odoo.com> Forward-Port-Of: odoo/enterprise#59815 Forward-Port-Of: odoo/enterprise#58535
Read-only accounting users were unable to access the Accounting App Dashboard due to missing permissions for bank connection records. This fix grants read-only access to bank connection and account records for users with read-only accounting privileges, allowing them to view banking information without being able to modify it.
Original PR description
In the system parameters, switch account_online_synchronization.proxy_mode to sandbox
Add a bank with plaid for example and follow the different steps
Have a user [DEMO] with Accounting access set to 'Read-only'
Log in with [DEMO]
Try to access the Accounting App Dashboard
Issue:
Access Error
"""
You are not allowed to access 'Bank Connection' (account.online.link) records.
This operation is allowed for the following groups:
- Accounting/Accountant
- Accounting/Bookkeeper
Contact your administrator to request access if necessary.
"""
This occurs because the read access to the account.online.link
and account.online.account records is granted only to users having at
least the account.group_account_user group
But, as those accesses are defined to be read only, it should be
greanted also to account.group_account_readonly users
opw-3821540This update fixes an issue where users would see duplicate error messages when a website page fails to save. Previously, when an error occurred during saving, both a popup notification and an error dialog would appear, creating confusion. The fix ensures users only see one clear error message displayed as a popup on the edited content block.
Original PR description
If an error happens when a website page is being saved, the error message is displayed as a popup on the edited block. Unfortunately, an error dialog is also displayed. This commit prevents that dialog from being displayed when the error is already shown to the user. task-3599890 Forward-Port-Of: odoo/odoo#154050
This fix resolves an issue where changing text color on buttons in the website editor would cause an error. The problem occurred because the system was incorrectly handling the undo/redo history when color changes were applied. The fix ensures that color changes are properly saved and can be undone without errors.
Original PR description
Steps to reproduce the issue: ============================= - Go to website and open editor - Click on the 'Contact Us' button - Change the color of the text - error Origin of the issue: ==================== `HistoryReverCurrentStep` will call `observerFlush` which will mark `_toRollback = true` and in `_observeOdooFieldChanges` we will update the html with `withoutRollback` but this only works only if `_toRollback` is `false`. Solution: ========= We need to rever the step without rollback too. task-3770287
This fix corrects a display issue in spreadsheets where aggregated values that equal zero (such as 9000 + -9000) were incorrectly shown as empty cells instead of displaying "0". Users will now see the correct zero value in their spreadsheet calculations, ensuring accurate data representation.
Original PR description
When the aggregated value is 0 (9000 + -9000 = 0), it displays an empty cell in spreadsheet, instead of zero. Task: 3827502 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A bug in the Payment Receipt printing feature was causing the invoice number placeholder to display incorrectly in the title. The fix corrects the HTML formatting to properly embed the invoice number within the document title when printing payment receipts.
Original PR description
## Issue: - When printing a Payment Receipt the name "INV0001" is added to the title. ## Steps To Reproduce: - Accounting > Vendors > Payment - create new payment and print payment receipt. ## Solution: - The issue was using a self-closing <span> tag and incorrectly placing the INV0001 placeholder outside it. - I placed INV0001 within an opening and closing <span> tag for correct dynamic content replacement. opw-3820212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where customers couldn't use gift cards or eWallets when they had less than 1 point remaining. The system was incorrectly preventing redemption of these small balances. Now customers can use their remaining gift card balance regardless of the amount.
Original PR description
If user had less than 1 point, which is equivalent to 1 quantity of set currency, on gift card and eWallet, they could not use it due to not enough point on Gift Card and eWallet for claiming reward. opw-3667934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155161
This fix ensures that when creating invoices from Point of Sale transactions, the system now uses the customer's designated invoice address, just like the Sales app does. Previously, invoices were created with the main customer address instead of the specific invoice address, causing inconsistency between the two apps.
Original PR description
Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address.…
Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address. Steps to reproduce: ------------------- * Go to the **Contacts** app * Select any contact (ex: Azure Interior) * Under **Contacts & Addresses** select Add * Select **Invoice Address** * Write the address then **Save & Close** * Go to the **Point of Sale** app * Add items * For customer, select the contact we just modified * Select **Payment** * Select any payment method * Select **Invoice** * Validate > Observation: The invoice address is not used Why the fix: ------------ We observe a discrepancy between the sale and pos output for the same workflow. * Sale * Sale order form: `Customer` -> Azure interior (Has a field for invoice address) * Account move form: `Customer` -> Azure interior, Az inv (Use the invoice address) * PoS * PoS order form: `Customer` -> Azure interior (Does not have a field for invoice address) * Account move form: `Customer` -> Azure interior In stable we can't add the invoice address on the PoS order form but we can still stay consistent with the sale workflow in terms of account move. In the sale workflow, the move is created with `invoice_vals_list` https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1207 Having a look at `invoice_vals_list`, we can see that the customer_id is set using the invoice contact address. https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1004 With `partner_invoice_id` computed as follows: https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L340-L342 Thus, we also send the invoicing contact address as partner_id when creating the move in pos; opw-3797434 Forward-Port-Of: odoo/odoo#159856 Forward-Port-Of: odoo/odoo#159172
This update removes an outdated route from the live chat system that was no longer being used and was causing crashes when accessed. The route attempted to load templates that no longer exist in the system. This fix prevents errors and cleans up unnecessary code.
Original PR description
This route is no longer used in our code and it tries to read templates that are no longer existing, leading to a crash if called manually. Forward-Port-Of: odoo/odoo#160206
This fix addresses an issue where translation data fails to load correctly when item names contain dots. The system was splitting these names into too many parts instead of the expected two parts (module and name), causing database save failures. The fix ensures names are split into exactly two parts, allowing translations to load properly regardless of dots in the name field.
Original PR description
In `ir.model.data` model, there is no SQL constraint which is ensuring that the `name` field can not contain `.` (dot) So when loading the translations to database if the xmlid's `name` contains dot then `xmlid.split('.')` will split it more than 2 parts. Which will cause issue during saving it to database as it is expecting[^1] 2 parts `[<module>, <name>]`. I ensured the splitting to 2 parts with `maxsplit=1`
Description of the issue/feature this PR addresses:
Current behavior before PR:
It is splitting xmlids as many as possible parts.
Desired behavior after PR is merged:
It will split xmlid to the 2 parts `[module, name]`
[^1]: https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L1326
and
https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L1390
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#160098This update adds database indexes to speed up the deletion of partner records. Previously, deleting a partner required the system to scan entire tables to find related records, which could take a long time. With these optimizations, partner deletions will now complete much faster, improving overall system performance.
Original PR description
Deleting a partner may take a long time because odoo has to check an entire table to find few records or no records at all that reference the partner and set it to null. So we are adding an index btree not null to speed up the deletion of partners. TASK-ID: 3759406 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
The help text displayed in tooltips for the product margins report was not accurately describing the actual calculation being performed. This fix corrects the tooltip text to match the real calculation logic, ensuring users see accurate guidance when reviewing margin information.
Original PR description
Issue ----- The tooltip help text doesn't match the actual calculation made in the product margins report. **opw-3792181** Forward-Port-Of: odoo/odoo#159131
This update corrects the account type classification for Spanish equity accounts (accounts 10x through 13x) to properly reflect them as 'equity' type accounts. This ensures these accounts are correctly displayed under the Equity section of the Balance Sheet, improving financial reporting accuracy for Spanish companies using Odoo.
Original PR description
Accounts 10x -> 13x should be of 'equity' type. (In the Balance Sheet, they are referenced under the Equity section.) Enterprise PR: https://github.com/odoo/enterprise/pull/57117 opw-3743637 Forward-Port-Of: odoo/odoo#160161 Forward-Port-Of: odoo/odoo#154859
This update fixes an automated test for the live chat bot redirect feature. The test was failing because it wasn't properly waiting for the bot's confirmation message when testing multiple redirect scenarios. The fix ensures the test correctly validates that the chat bot continues to work properly after being redirected.
Original PR description
The `website_livechat.chatbot_redirect` tour checks that the chat bot still works after redirection. The tour waits for the chat bot message that indicates the redireciton was made. Since the tour restarts the bot to test two differents flows, this message is already present before the second redirection occurs. The tour should instead wait for two occurences of this message the second time. Forward-Port-Of: odoo/odoo#160276