Monday, May 27, 2024
31 changes
2 changes
Resolved issues and error corrections
This change reverts a previous update that could incorrectly switch an online shopper's cart customer to OdooBot in some website shop requests. Reverting it prevents wrong customer assignments while a cleaner long-term solution is prepared separately.
Original PR description
This reverts commit 4246d6e93e8450adc727981f3bb2b8c24aebafc9. This commit included changes that triggered sale_get_order calls in routes/requests that did not use it previously. Since those routes were using an environment sudoed with the superuser, the call to sale_get_order wrongly changed the customer to OdooBot. This will be addressed in a cleaner way in a separate PR, but for now, we only revert the wrong commit. opw-3949391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where gift cards sold in Point of Sale could fail to generate when product loading was restricted by category. The checkout now includes the required gift card products from the start of the session, ensuring customers receive the expected generated gift card.
Original PR description
Steps: --- - Install pos_loyalty with demo. - Configure shop to restrict product loading, only chairs. - Also make sure the setting is "Generate PDF Cards". - Open pos. - Search for the gift card (search more to load the product from server). - Sell the gift card. Issue: --- At checkout, there should be a generated gift card. Cause: --- Gift card product was not being loaded at the start of the POS session due to category restrictions. This caused `trigger_product_ids` to be empty since the product with the matching ID wasn't loaded. FIX: --- When loading data at the start of the session, load all products listed in `trigger_product_ids`. task-3911737
8 changes
Enhancements to existing features
Project task screens now provide embedded shortcuts to related Documents and Planning actions, making it easier for users to access supporting project information without leaving their workflow. The update also streamlines project view controls and adjusts related performance test expectations.
15 changes
Resolved issues and error corrections
The Austrian financial reports module had an unbalanced Balance Sheet that has now been corrected. The fix adds missing account classifications, separates current year profits from carried-forward profits in both the Balance Sheet and Profit & Loss statements, and aligns the reports with official Austrian accounting standards. This ensures accurate financial reporting for Austrian companies.
Original PR description
According to the Balance Sheet diagnostic test in #47602, the Balance Sheet was unbalanced. To fix this, - missing account tags have now been added (cf community PR); - the Balance Sheet Profit (loss) line has been split into the current year's profit/loss and the profit/loss carried forward. - the Profit and Loss carried forward from previous years has been created as a new line in the P&L. This is all done in accordance with the official Balance Sheet and Profit & Loss found at https://www.jusline.at/gesetz/ugb/paragraf/224 https://www.jusline.at/gesetz/ugb/paragraf/231 Community PR: https://github.com/odoo/odoo/pull/158542 Taskid: 3060790
The invoice attachment viewer now works correctly when opened in a separate tab or window. This ensures visual extraction markers are placed in the right place, improving usability for accounting workflows.
Original PR description
The attachment viewer can now be popped out in another tab/window. We are now targetting the right window to add the boxes where needed. [task-3932781](https://www.odoo.com/web#id=3932781&model=project.task)
The Sign app onboarding has been improved to help users start creating templates more easily. Users can now drag and drop files, while clearer guidance and small usability refinements make the setup flow smoother and more satisfying.
Original PR description
The onboarding process for the sign app has been upgraded to make it easier to use and improve customer satisfaction. This PR allows users to upload templates with ease by simply dragging and dropping files. Additionally, the action helper has been updated to provide a more intuitive and seamless experience. The overall usability has been improved by fine-tuning menu sequences and other minor improvements. task-3764704 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Report export and filing wizards now use a shared error display that makes blocking issues easier to understand and act on. This improves consistency across accounting, SAF-T, Intrastat, and local reporting flows while keeping important errors sorted reliably for users.
Original PR description
`file_generation_error` has been superseded by `ActionableErrors` in `account` which is more generic. SAF-T and other wizards relying on the `critical` attribute need sorting. jsonb fields don't retain order in PostgreSQL, so we re-sort the actionable_errors field by critical and then by error key. Community PR: [odoo/odoo#159251](https://github.com/odoo/odoo/pull/159251) Upgrade PR: [odoo/upgrade#5917](https://www.github.com/odoo/upgrade/pull/5917) Task link: [odoo/task#3698183](https://www.odoo.com/web#model=project.task&id=3698183) task-3698183
Odoo now supports printing complete US checks in-house instead of requiring pre-printed Checkdepot stationery. Businesses can choose top, middle, or bottom check layouts that automatically include company and payment details, giving them more flexibility and control over check printing.
Original PR description
For the United States, Odoo currently offers the option to print checks using a "pre-printed" format that matches a specific supplier (Checkdepot). We don't cover the use case where checks are printed in-house without a pre-populated page with some static information. Also, if a company would like to change or edit some information from the pre-filled checks, it is impossible. We want to offer users the option to print "blank checks" by having a prepopulated template in Odoo that will adjust to the company's information. This commit adds 3 additional check layout to print: - print_blank_check_top - print_blank_check_middle - print_blank_check_bottom Where each of them are designed meticulously to position the required fields in blank checks, according to Checkdepot's layout. task-id: 3719584
The inventory onboarding flow for barcode operations has been updated to better match the latest business-to-business onboarding specification. This should make it easier for users to get started with inventory barcode workflows and understand the next steps during setup.
Original PR description
Task: 3647839
Accountant users can now request and enter OTP codes for GSTR API verification without needing broader settings permissions. This reduces delays in GST return workflows and lets finance teams complete required verification steps with the access they already have.
Original PR description
Before this PR, users with accountant access rights lacking setting permissions could not send and enter OTP for GSTR verification. With this enhancement, users with accountant access rights can now successfully send and input OTP codes, streamlining the verification process. Task ID: 3895351
Resolved issues and error corrections
Dashboard administrators can now insert items such as pivot views into spreadsheet dashboards without needing full system administrator rights. This restores the expected dashboard editing permissions for users in the Dashboard Admin group, especially when Documents is not installed.
Original PR description
[FIX] spreadsheet_dashboard_edition: allow to insert in dashboard Steps to reproduce: - install CRM (make sure Documents is not installed) - login with a user with "Dashboard Admin" group (but not system admin) - go to CRM and try inserting a pivot view in a spreadsheet => you can't Since odoo/odoo@0c50cbe18ce3f1 a new user group was created allowing to create and edit spreadsheet dashboards. However, members of that group are not able to insert anything because the group was not updated in the registry. Task: 3795574
This update fixes how payment tax documents (CFDIs) are dated in Mexico. Previously, payments created in Odoo before being sent to the government would use an incorrect date. Now the system uses the actual submission date, which complies with Mexican law allowing payments to be submitted up to 10 days into the following month. This ensures your tax filings are legally accurate.
Original PR description
[REF] l10n_mx_edi: change fecha date to sent date Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769
This fix resolves a crash that occurred when users tried to retry sending comment notifications in the Knowledge module. When a user tags another user in a Knowledge comment, the system attempts to send a notification email. If an error happens and the user retries, the system was crashing due to a missing data field. The fix ensures the system gracefully handles this situation so users can successfully retry sending notifications.
Original PR description
This commit fixes an issue with comments notifications in Knowledge. When a user tags another user in a Knowledge comment, a mail should be sent. When an error occurs the user have the possibility to retry to send the notification. Retrying this action triggers an error with threads because the msg_vals key doesn't exist when trying to access it inside `_notify_thread_by_email`. The fix is to use the get function of Python dict so that if the msg_vals aren't set, no error is triggered. task-3933062
This fix resolves an issue where shipping addresses with longer city and state names would cause Bpost delivery validation to fail. The system now properly limits the address field length to prevent errors when customers have addresses that exceed the character limit, such as "Marche-lez-Ecaussinnes, Brabant Wallon (BE)".
Original PR description
Steps to reproduce: - Create a contact who has the "City" and "State" populated, that would exceed 40 characters in the following format: "[City], [State] ([Country Code])" eg: "Marche-lez-Ecaussinnes, Brabant Wallon (BE)" - Enable Bpost and enter test credentials. - Create a Sales Order and add Bpost shipping. - Try to validate the transfer - Error about the "LocalityCode" being too long. Fix: same as for other fields impose max length limit opw-3895123 Forward-Port-Of: odoo/enterprise#62710
This fix corrects how asset depreciation amounts are calculated when an asset's lifetime is extended through revaluation. Previously, when extending an asset's depreciation period (for example, adding 12 months), the depreciation entries would end too early. Now the system properly calculates depreciation amounts based on the original asset value, ensuring consistent monthly depreciation across the entire extended lifetime.
Original PR description
Create an asset for 2400$, acquisition date on 1/1/2023. Reevaluate it on 31/12/2023, 36 montths (+12) and add 1200$ to the amount. => The entries on the parent asset finish way too early. You don't get 36 months of lifetime. We would expect the amount of each new depreciation to be 50, so the amount of the parent + the child equals 100 each month for 36 months The reason why it happened is that we tried to compute the expected amount after each depreciation. This took into account changes of amount, but not changes of length. We don't have a good way to incorporate changes of length in the old computation. To fix this, for linear, we consider the original amount from the beginning/the reevaluation to compute the amount for each period. It does not hold for degressive_then_linear, so we separate the logic. opw-3811165 Forward-Port-Of: odoo/enterprise#62377
This fix resolves an issue where Knowledge articles couldn't embed certain views (like Cohort and Gantt views) if their optional modules were manually uninstalled. The system now intelligently detects which modules are loaded and only applies the necessary patches when available, preventing errors and ensuring a smooth user experience.
Original PR description
Cohort views were patched to allow inserting them as an embed in a Knowledge article, but `web_cohort` was not a dependency of `knowledge`. It was an issue if the `web_cohort` (which is auto_install: True) module was manually uninstalled. Using an odoo runtime import, we can evaluate if the module was loaded and apply the patch at that point. If the module was not loaded, the patch is not applied. task-3918938 Forward-Port-Of: odoo/enterprise#63100 Forward-Port-Of: odoo/enterprise#62181
Fixed an issue in the document signing process where users were unable to close the confirmation dialog box after signing documents. Previously, users had to close the entire browser window to dismiss the dialog. Now a close button has been added, allowing users to easily dismiss the dialog and continue with their work.
Original PR description
Steps to reproduce: - Install sign - Add two document to sign for the Marc Demo - Sign in as Marc Demo - Go to the sign app and sign both documents Issues: There's no button to close the dialog box, you are forced to close the window. opw-3847269 Forward-Port-Of: odoo/enterprise#61380
When revaluing an asset with an increase from a previous month, the system was incorrectly recording today's date on the value increase transaction instead of the actual revaluation date. This fix ensures the transaction is dated to match the asset's acquisition date, providing accurate financial records and proper period tracking.
Original PR description
To reproduce: Create an asset. Reevaluate, with an increase, last month. => the move of Value Increase has today's date. We decided to instead put the acquisition date of the child asset. (so it won't be the same in 16.0) opw-3922067 Forward-Port-Of: odoo/enterprise#63115 Forward-Port-Of: odoo/enterprise#63097
This fix prevents dashboards from disappearing when users accidentally remove all group assignments. By making the group field required, dashboards must always be assigned to at least one group, ensuring they remain accessible and cannot be lost.
Original PR description
Purpose ------- If you remove all groups of dashboard and save, the dashboard disappears and there's no way to find it back. Specification ------------- make the field required. Task: 3770194 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where users without write permissions could not properly drag and drop items in kanban views. Previously, items would not reset to their original position when users lacked reordering rights. Now the drag-and-drop functionality works correctly for all users, with items properly returning to their original position when the action is not permitted.
Original PR description
Before this commit, drag-and-drop functionality for groups/records in the kanban view did not work properly if the user lacked write access. Steps to Reproduce: - Log in to Odoo as Marc Demo. - Open the Project module. - Attempt to drag and drop any group/record in the kanban view. Observed Behavior: The group in the kanban view does not reset to its original position if the user lacks the right to reorder the groups/records, rendering the group/record immovable. Expected Behavior: The group in the kanban view should reset to its original position if the user lacks the right to reorder the groups/records. After this commit, drag-and-drop functionality for groups/records in the kanban view now works properly, even if the user does not have write access. Task ID: 3865617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error that occurred when searching for vehicles by driver in the Fleet app when installed without the HR module. The fix ensures the vehicle search functionality works correctly regardless of which modules are installed alongside Fleet.
Original PR description
Problem: * If the fleet app is installed **by itself** (i.e. without hr) searching a vehicle by driver will throw an error. Notes about fix: * The error is caused by a hr_fleet child field being accessed in the base Vehicle model. opw-3858626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a bug in the Accounting app where PDF attachments uploaded to bills would not display a preview. The issue occurred because the system tried to show the PDF before it was fully saved. This update ensures the file is completely uploaded before attempting to display it.
Original PR description
Caused a bug in accounting app. ### Steps to reproduce: - Go to Accounting > Vendors > Bills - Create a new bill - Upload a pdf using the link button in the chatter - The pdf viewer displays but without preview ### Cause: The call to display the attachment occurs before the attachment record is created. This is due to the onUploaded function of mail not being async, so the program does not wait for it to end. ### Solution: Make the function async and waiting for the file to be uploaded. opw-3927764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where test emails sent through the mass mailing feature contained broken placeholder links that would result in 404 errors when clicked. The fix ensures that placeholder links are properly replaced with actual working links when test emails are sent, while preventing unsubscribe links from being modified to protect users from accidentally unsubscribing themselves.
Original PR description
This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the…
This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the actual link when rendered. When the user sends a test mailing, the mail sent will still contain the placeholder link without being replaced. This means that when clicking on it the user is redirected to a 404 error as this is a mere placeholder. This link isn't replaced because the mail created inside testing wizard did not give a res_id, linked to a `mailing.contact`, to the `mail.mail` created. This led the function `_prepare_outgoing_list` to be exited prematurely without replacing any placeholder. This commit fixes the issue by adding a res_id linked to the current user to the mail.mail created in order for the method to finish its execution. But we don't want the unsubscribe links to be replaced, as the user could blacklist himself. Thus we added a context key `send_as_test` which blocks the replacement of the unsubscribe link. task-3869575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where repair orders were not receiving auto-generated sequence numbers after a system upgrade. The problem was caused by an incorrect comparison logic that was checking for a translated value when the field doesn't support translation. By correcting this comparison, repair orders now properly generate their sequence numbers automatically instead of remaining with the default 'New' label.
Original PR description
Issue: In the upgraded version, we have implemented the condition vals['name'] == _('New'). However, the data type of the 'name' field is character and translate = False. Additionally, the default…
Issue: In the upgraded version, we have implemented the condition vals['name'] == _('New').
However, the data type of the 'name' field is character and translate = False.
Additionally, the default value for the 'name' field is set to 'New', causing
this condition to evaluate to false and consequently terminating the execution
of the if block.
Solution: To address this, we propose changing the condition to vals['name'] == 'New'
to ensure correct comparison. This modification is warranted due to the
[configuration](https://github.com/odoo/odoo/blob/89fbb75659ba71b8c76dddd62ba331966161f59b/addons/repair/models/repair.py#L31)
of the field:
The field is not translatable.
The field is required and set to readonly true, preventing customers from inputting values.
The default value for the field is set to 'New'.
Before:
Unable to obtain the auto-generated sequence (receiving default value 'New').
After:
The sequence is generated automatically.
OPW-3887638
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#165771This update fixes an issue where portal access couldn't be granted to multiple customers with the same email address when they're linked to different websites. The system now correctly handles scenarios where customers create separate accounts per website, allowing each to receive portal access independently while preventing conflicts when appropriate.
Original PR description
[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure…
[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure that the "Shared Customer Accounts" setting is disabled. The user is so forced to create an account per website. - As a visitor, create an account in each website using the same email address. -> No issue; it is possible to create two accounts with the same email address. Steps to reproduce the issue: - Create two contacts (e.g. partner or customer) with the same email address. One is linked to website1, the other is linked to website2. - Select them, click on "Action" and then on "Grant portal access". - Click on "Grant Access" for the first contact; it works as expected. -> It is not possible to grant access for the second contact. The goal of this commit is to ensure that the two described behaviors lead to the same results. More specifically, it should be possible to grant portal access for two partners that have: - The same email address but are linked to different websites that have the "Shared Customer Accounts" setting disabled. - The same email address. One user is linked to a website that has the "Shared Customer Accounts" setting disabled and the other is not linked to a website. It should however not be possible to grant portal access for two partners that have: - The same email address and are linked to the same website that has the "Shared Customer Accounts" setting disabled. - The same email address and are not linked to a website. It should also not be possible to grant portal access for a partner that is not linked to a website if it exists a user with the same email address that is linked to the current website. Indeed, in this situation, the partner is redirected to the current website at the creation of its account and an "Access Denied" message would then be displayed. To solve the problem, the method `_get_similar_user_domain()` has been implemented in the "website" module. Its goal is to build the domain needed to find the users that have the same email than partners depending on their linked website characteristics. The `_is_portal_similar_than_user()` method has also been introduced. Its goal is to check if the credentials of a portal user and a user are the same. If it is the case, `email_state` field of the portal user is set to `exist`. task-3640503 Forward-Port-Of: odoo/odoo#166349 Forward-Port-Of: odoo/odoo#148482