Daily updates from Odoo
Friday, February 2, 2024
22 changes
Resolved issues and error corrections
Fixed an issue where clicking on amounts in analytic reports would show empty results for all analytic plans except the default "Projects" plan. The fix ensures that all analytic plans now properly display the detailed transactions that make up the reported amounts, improving the auditability and usability of financial reports.
Original PR description
When grouping by analytic plan and/or account in a report, clicking the amount always opened an empty tree view, except for the default "Projects" plan which properly displayed the analytic lines making the amount. This was due to the fact the domain was built using field account_id of account.analytic.line, which is only used for the default plan (other plans dynamically create fields on account.analytic.line to store their chosen account). auto_account_id is overridden in the model to allow searching on all plans, and should hence be used in this context.
This update fixes visual styling and display issues in the Account Follow-up report. The report now properly shows styling that was previously missing, displays the current date correctly at the top of the report, and prevents errors when maturity dates are not set. These fixes ensure the follow-up reports appear correctly and function reliably for users.
Original PR description
In 17.0, the style applied in the python side was not used in the template. This commit will add the style classes, change the template used in the python side since it isn't there anymore and correct a traceback when the date_maturity is not set. Also, a bug fix is applied: - the date was not populated on top of the report because the field today is only accessible on lines but not on the report itself. task: 3695867
This fix resolves a crash that occurred when viewing attendance records for employees with split work schedules (like morning and afternoon shifts). The system was incorrectly trying to process multiple schedule entries at once, causing an error. Now it properly handles employees with complex working schedules.
Original PR description
Steps to reproduce: 1) Set your "Working Schedule" for example like this from Monday to Friday Morning | Morning | 04:00 | 12:00 Afternoon | Afternoon | 12:00 | 22:00 2) Create a manual attendance…
Steps to reproduce:
1) Set your "Working Schedule" for example like this from Monday to Friday
Morning | Morning | 04:00 | 12:00
Afternoon | Afternoon | 12:00 | 22:00
2) Create a manual attendance record for any employee who is using the above schedule:
Go to Attendances Tree view -> Click on New -> Add a new attendance record -> Add the record with check in for yesterday(in this example Monday) and don't add the check out.
3) Now go back to home and click on attendance and go back to previous day by clicking on "<-" beside days
4)
Error:
File "/data/build/enterprise/hr_attendance_gantt/models/hr_attendance.py", line 63, in <listcomp>
expected_worked_hours[emp.id] = sum([(att[2].hour_to - att[2].hour_from) for att in expected_attendances])
File "/data/build/odoo/odoo/fields.py", line 1148, in __get__
record.ensure_one()
File "/data/build/odoo/odoo/models.py", line 5842, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: resource.calendar.attendance(1, 3)
Solution:
We need to consider multiple resource.calendar.attendance in att[2]Users were unable to send WhatsApp messages because the system was incorrectly checking archived (inactive) phone numbers against the blacklist. This fix ensures only active phone numbers are checked when validating blacklist status, allowing users to send messages successfully. The change includes improved test coverage to prevent this issue from recurring.
Original PR description
When the user tries to send a conversational WhatsApp message, it fails saying that the phone number is blacklisted. Problem:- By default, the archived records are not searched in `.search()` unless `active_test` is given `False` in context. Here while searching blacklisted numbers in `_send_message`, the `False` value is obtained for `active_test` in context due to which archived blacklisted numbers are also being searched. This context is obtained from the `mail_message_post` controller. https://github.com/odoo/odoo/blob/46d94c4bdaec287615e47aac6597f36f498cf8de/addons/mail/controllers/thread.py#L96 Solution:- We will forcefully pass the `active_test` with `True` while searching blacklisted phone numbers. Due to this archived records will not be searched and it will let the user send the WhatsApp message using the discuss channel. Task - 3698511
Fixed a bug where customers updating their subscription payment method were not seeing a confirmation message after saving. This fix ensures users receive proper feedback when they successfully change their payment method in their account portal, improving the user experience and reducing confusion about whether their action was completed.
Original PR description
After changing the payment method of a subscription, the confirmation message was not displayed on the subscription. To reproduce: - prerequisite: setup a test payment provider with tokenization support - login in as 'portal' user - Buy a 'Car Leasing' product, on payment choose the preceding payment provider with tokenization - go to 'My Account', then click on 'Subscriptions' - choose the order with 'Car Leasing' - click "Manage Payment Method" - click on "Save Payment Method" => After page reload we should see a message saying that the payment method was successfully changed, but no message are displayed. Forward-Port-Of: odoo/enterprise#48671
This update fixes a critical issue in the attendance app where work schedules with no break periods (such as split shifts like 8am-12pm and 12pm-5pm on the same day) were causing errors. Users can now properly view their weekly attendance reports without encountering system errors, improving the reliability of attendance tracking.
Original PR description
Steps to reproduce: - Install attendance app - Setup working schedule with no break like so (Mon 8-12h), (Mon 12-17h) - Check attendance for the week Issues: Traceback is displayed opw-3705883 opw-3706118
This update fixes a bug where menu options for pivot and list properties were incorrectly displayed when a spreadsheet formula referenced a non-existent data source. Users would encounter an error when clicking these menu items. The fix ensures these menu options are now hidden when the referenced data source doesn't exist, preventing confusion and errors.
Original PR description
The menu actions to access the pivot & list properties were visible when the formula was referring to an inexisting datasource. Clicking on the said action would then traceback as ce cannot find a datasource. Task: 3670824 Forward-Port-Of: odoo/enterprise#55529 Forward-Port-Of: odoo/enterprise#54675
This fix ensures that when an analytic distribution is assigned to a bank transaction's counterpart, the analytic column now properly displays in the bank entry preview. This improves visibility and accuracy when reviewing bank reconciliations with analytic allocations.
Original PR description
When an analytic distribution is set on the counterpart of a bank transaction, the analytic column should appear in the preview of the bank entry. task-3687839 Forward-Port-Of: odoo/enterprise#55354 Forward-Port-Of: odoo/enterprise#54837
Fixed a bug in the Data Cleaning app that caused the application to crash when users applied custom filters on Company fields using "contains" or "not contains" operators. The issue was caused by improper handling of special characters in database queries, which has now been resolved to ensure filters work correctly.
Original PR description
Steps to reproduce: ------------------- In Data Cleaning app, try to apply a custom filter on Company with "contains" or "not contains" operator. Issue: ------ A traceback occurs. For this line: `res…
Steps to reproduce:
-------------------
In Data Cleaning app, try to apply a custom filter on Company with "contains" or "not contains" operator.
Issue:
------
A traceback occurs.
For this line: `res = self._obj.execute(query, params)`, we have `IndexError: list index out of range`.
Cause:
------
There is a mismatch between the `%` in the query and the number of parameters.
The query is constructed by combining subqueries with a template. These subqueries will be determined using the `mogrify` method and will be concatenated to the main query template.
The `'` characters are correctly escaped with `\` , but the `%` characters are not.
Solution:
---------
Don't use mogrify, so that we can keep the subquery parameters
and pass them directly to the main query.
By leaving the values wrapped with `%` in the parameters,
there are no more escape problems.
Note:
This is a better fix than manually escaping the `%` if necessary like:
```py
if operator in ('not ilike', 'ilike'):
value = f'%{value}%'
```
opw-3668433
Forward-Port-Of: odoo/enterprise#55204
Forward-Port-Of: odoo/enterprise#54287This fix resolves an issue in the Helpdesk module where customer email addresses were not being saved correctly on support tickets. The email field is now properly set when creating or updating helpdesk tickets, ensuring that support teams can reliably contact customers and maintain accurate customer records.
Original PR description
Forward-Port-Of: odoo/enterprise#55491
This fix resolves an issue where the status bar field (showing project stages) was not updating correctly when switching between projects. The problem occurred because the system was using outdated information when retrieving stage data, causing the wrong stages to display. This fix ensures the status bar always shows the correct stages for the currently selected project.
Original PR description
Steps to reproduce ================== - Create a new project - Add a few new stages - Go back to the project overview - Select another one - Open any task - Click on the new button - Change the project The status bar field containing the stages is not correctly updated Cause of the issue ================== The StatusBarField uses the useSpecialData hook. This then uses the useRecordObserver hook which calls the callback after a new animation frame. By that point, the props are out of date and the search_read uses the incorrect domain Solution ======== opw-3693113
This fix addresses an issue where invoices in Kenya were generating final PDFs before being sent to the fiscal device, resulting in missing legal information. The system now generates a proforma invoice when legal information is unavailable, ensuring compliance with fiscal requirements. Users receive a warning when a proforma is generated due to the invoice not being sent to the fiscal device.
Original PR description
With Kenya localization installed Create an invoice Send&Print Issue: The sytem will issue the final pdf before the invoice has been send to the fiscal device, so the legal information is actually missing A solution is to generate a proforma pdf invoice when the legal info is still missing Removing call to `_hook_invoice_document_after_pdf_report_render` as it seems intended to add a legal layer not needed in proforma invoice opw-3599869 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 Forward-Port-Of: odoo/odoo#142861
This update makes the automatic save feature more reliable when users close a form with unsaved changes. Previously, changes could be lost if the network connection was poor or the data was large. The system now uses a more dependable method to ensure data reaches the server, and alerts users if the data is too large to send automatically, prompting them to save manually.
Original PR description
In form views, when the user closes the tab while having unsaved changes, and if those changes are valid, we want to save them automatically before leaving. Before this commit, there could be…
In form views, when the user closes the tab while having unsaved changes, and if those changes are valid, we want to save them automatically before leaving. Before this commit, there could be situations where the changes weren't actually saved. For instance, if they involved an heavy payload for the write rpc, or if the network connection was poor, it might happen that the xhr is killed. Or at least, browsers do not offer any guarantee to wait for those xhr to reach the server. Instead of a classical xhr, we thus use navigator.sendBeacon which ensures that the data will be sent reliably [1]. There's a drawback though, as its payload is limited. When the payload is too heavy, sendBeacon simply returns false and does nothing. In this case, we prevent the page from unloading and display a notification suggesting the user to manually save his changes before leaving. [1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon Task 3537838 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 Forward-Port-Of: odoo/odoo#151448 Forward-Port-Of: odoo/odoo#149944
This fix resolves an issue where WhatsApp messages were not being properly blocked when sent to blacklisted phone numbers. In Odoo 17, a system change inadvertently removed the check for whether a number was actively blacklisted, allowing messages to be sent to customers who had requested to stop receiving communications. The fix restores proper message blocking while maintaining other system improvements.
Original PR description
When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True,…
When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False.
Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line in whatsapp_message.py
if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]):
In SaaS 16.4, this line returns the following SQL request:
SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE (("phone_blacklist"."active" = true) AND ("phone_blacklist"."number"::text ILIKE '%32491730941%')) ORDER BY "phone_blacklist"."id";
Here, we check if the Active state is True to block the message if necessary.
In 17, this same line returns this SQL request:
SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE ("phone_blacklist"."number"::text ILIKE '%32491730941%') ORDER BY "phone_blacklist"."id";
I correct it in a PR https://github.com/odoo/enterprise/pull/55498
But if we go further we find that it's really because of the active_test = False of this line in thread.py thread = request.env[thread_model].with_context(active_test=False).search([("id", "=", thread_id)]) from this commit
https://github.com/odoo-dev/odoo/commit/8b2605b99348b7707b3db3db46af880c17c7029c
with the fix of this PR, the discussion on Whatsapp is now possible and we keep the fix of the previous commit.
opw-3704136
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves issues with the color picker tool in the project module. Previously, the color picker would open in the wrong direction, either appearing as a dropdown when there wasn't enough space (making it inaccessible) or always opening as a dropup on subsequent uses. Now the color picker intelligently opens upward when space is limited and downward when space is available, ensuring users can always access the full color selection tool.
Original PR description
**Current behavior before PR:** - In the project module, when a user opens the color picker, it opens as a dropdown even if there is not enough space available, resulting in some parts of the color picker being inaccessible. - In the project, when a user opens the color picker a second time, it always opens as a dropup, even if there is space available for it to open as a dropdown. **Desired behavior after PR is merged:** - Now, when a user opens the color picker, it opens as a dropup when there is not enough space available for the color picker to open as a dropdown. - The color picker will open as a dropdown when there is enough space available. task-3608803 Forward-Port-Of: odoo/odoo#151681 Forward-Port-Of: odoo/odoo#144698
This fix resolves a technical error that occurred when confirming multiple sales orders in batch (such as through automated tasks). The system was incorrectly trying to check user permissions on multiple records at once, which caused it to crash. The fix ensures the permission check works properly regardless of how many orders are being confirmed together.
Original PR description
Thanks to changes in 82314364c6029a83 the auto-lock settings also works for public users. But, going from `self.env.user` to `self.create_uid` to check the group leads to a traceback when `self.create_uid` is not a singleton. This is because `has_group` expects a single record. To fix that, this commits checks the group of the create_uid of the first record in self. Because `sale.group_auto_done_setting` is an implied_group of a res.config.settings parameter, it's enough to only check for the first record in the recordset. To reproduce: - Install sale - Create a quotation as Mitchell Admin - Create a quotation as Marc Demo - Create a cron that searches on all draft sale.orders and confirm them in batch - Run the cron -> Singleton Error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151903 Forward-Port-Of: odoo/odoo#151789
This fix improves the Stripe payment form to properly handle and display errors when payments fail due to amount restrictions or other issues. Previously, users would see technical error messages or tracebacks when attempting invalid payments. Now, clear error messages are shown both when the form loads and when users try to submit, providing a better experience for customers attempting to make purchases.
Original PR description
Steps to reproduce: 1) Try to make a payment with the amount less than 0.50$ (minimum amount required in Stripe) 2) Stripe inline form fails to load 3) One can still click pay and see the traceback After this commit the error are handled and displayed on the form loading and on the form submit. opw-3634316
This fix ensures that the mobile version of ecommerce checkout steps can be properly translated into different languages. Previously, the way text was formatted in the code prevented translation systems from recognizing these strings. The fix reorganizes how the text is written so that translation tools can correctly identify and translate all checkout step labels for international customers.
Original PR description
Appending strings within a `t-out` for a website template makes it so that it can never be translated. Instead the string should be written like normal text so that it is correctly seen as to be translated and `t-out` only the next step so that it's also correctly matched as to be translated. opw-3700815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The sales portal was displaying the wrong address as the invoicing address—it was showing the main sales order address instead of the actual invoicing address. Additionally, the edit button for updating the customer's main address was appearing incorrectly next to the invoicing address even when the sales order didn't belong to the customer or when the invoicing address differed from the main address. This fix ensures the correct address is displayed and the edit button only appears when appropriate.
Original PR description
The address displayed as 'Invoicing address' was the main SO address and not the invoicing one. Also, the pencil icon link to update the customer main address was always displayed next to the invoicing address, even if: * the so does not belong to the customer * the invoicing address is different than the customer main address This commit fixes those two issues. opw-3653190 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a bug where the status bar field in task forms would display incorrect stage options when switching between projects. The issue occurred because the system was using outdated information when loading the available stages, causing the wrong stages to appear either immediately or after saving. This fix ensures the status bar always displays the correct stages for the currently selected project.
Original PR description
Before this commit, there was a race condition with the statusbar field, and more specifically with the useRecordObserver. The issue could be reproduced in the form view of project.task. In an…
Before this commit, there was a race condition with the statusbar field, and more specifically with the useRecordObserver. The issue could be reproduced in the form view of project.task. In an existing task, belonging to a project with some stages, change the project to another project with its own stages. It might happen that the displayed stages weren't the one of the newly set project. If this didn't happen directly, this happened upon saving (i.e. the correct stages are displayed just after switching the project, but as soon as the user saves the record, the former stages are back). This happens because of useRecordObserver used an outdated version of the props to get the domain (i.e. the props of the component have been updated, but useRecordObserver still used the old version, in particular the old props.domain). This commit fixes the issue by ensuring that we always use the last version of the props. opw 3693113 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 resolves an issue where the "force post" option was not working correctly in the account move validation wizard. Previously, when users tried to force post an auto-scheduled move, the system would incorrectly reject the action. Now users can successfully override the auto-post setting when needed through the validation wizard.
Original PR description
Force post does not work in the validate account move wizard. Steps: - Create a move in the future and set it to be auto post - On the list view, select the move and select action "post entries" - On the wizard, check "force" and validate -> UserError "This move is configured to be auto-posted ..." Forward-Port-Of: odoo/odoo#152271 Forward-Port-Of: odoo/odoo#152003
This fix resolves a bug in the web editor where deleting completed checklist items would incorrectly mark subsequent uncompleted items as done. Users can now safely delete completed checklist items without affecting the status of other items in the list.
Original PR description
Current behavior before PR: When in a checklist where first and second checklist are marked done after selecting first and second checklist and deleting it the third checklist would be marked as done. Desired behavior after PR is merged: Now deleting previous done checklist would not affect the current checklist. task-3203889 Forward-Port-Of: odoo/odoo#151778 Forward-Port-Of: odoo/odoo#134619