Monday, May 27, 2024
30 changes
4 changes
Resolved issues and error corrections
This change prevents an error when staff open the restaurant Mobile View after a register has been closed and there are no active orders. It keeps the self-ordering page accessible instead of triggering a backend failure, improving reliability for restaurant operations.
Original PR description
This error usually occurs when there are no active orders present, and we've closed the register and then tried to access the ``Mobile View`` feature. Steps to reproduce: - Install the…
This error usually occurs when there are no active orders present, and we've closed the register and then tried to access the ``Mobile View`` feature. Steps to reproduce: - Install the ``pos_restaurant`` and ``point_of_sale`` modules - Make sure there are no active orders in the restaurant - Dashboard > Open Register > Open session > Close Register - Dashboard > Restaurant > Dropdown Menu > Mobile View - An Error will be generated in the terminal Traceback : ``ValueError: bus.Bus only string channels are allowed.`` This situation arises because we have two self-ordering modes: i) ``Mobile`` and ii) ``kiosk``. When the condition at [1] is evaluated, it will become false because the session has been closed, causing ``pos_config.has_active_session`` to be false. Additionally, since the mode is ``Mobile``, the condition in the ``elif`` statement at [1] also evaluates to false. As a result, we will get the value of ``config_access_token`` as a boolean value from line [2] because the value of ``config_access_token`` will not be set from both of the above conditions. Due to ``config_access_token`` being a boolean value, the value of ``channels`` ends up being a boolean value. This commit will fix the above error by providing an empty string within ``config_access_token``, rather than boolean values. So, the value of ``channels`` will consistently be a string. [1]: https://github.com/odoo/odoo/blob/16120774d6e7b16b44f771ca8224426e78676295/addons/pos_self_order/controllers/self_entry.py#L35-L47 [2]: https://github.com/odoo/odoo/blob/16120774d6e7b16b44f771ca8224426e78676295/addons/pos_self_order/controllers/self_entry.py#L16C8-L23C50 sentry-5136273134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
The Settings page now properly activates developer mode when users click the option. This ensures administrators can access advanced configuration tools without needing a manual workaround or page refresh.
Original PR description
Steps to reproduce ================== - Go to settings - Click on "Activate the developer mode" => Nothing happens Cause of the issue ================== The page isn't reloaded Solution ======== Use the router and pass the reload option. The same call is done in debug_provider.js opw-3922717
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
5 changes
Resolved issues and error corrections
This change removes a temporary placeholder and switches Mexican e-invoicing screens to use the shared document status display already available in accounting. It reduces duplicate code and helps keep invoice, payment, POS order, and stock picking views consistent without changing the business workflow.
Original PR description
In a7adb61e41ef17459eb95d9252cd53db37ebe0b2, the document_state component was removed from l10n_mx_edi to be put in account. We had to keep an "empty shell" component in l10n_mx_edi to avoid having to modify the l10n_mx_edi views in stable. But in master, we can remove this "empty shell" and use the generic component from account.
16 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
A Planning test scenario now correctly handles cases when the current day is the first day of the week. This prevents false test failures and helps keep Planning updates more reliable.
Original PR description
Before this commit, the tour planning_split_shift_week would crash when the current day is the beginning of the current week. This happened because when today is the first day of the week, the selector used in the step "Select first day of the current week" would be the start of the previous week. Thus the final date range produced, would contain two weeks instead of one, making the tour timeout (waitUntil condition not met).
The spreadsheet pivot side panel now correctly shows the minimum calculation option. This helps users choose the right summary method when analyzing document spreadsheet data.
Original PR description
`min` aggregator was missing in the list of available aggregators in the pivot side panel. This commit adds it. Task: 3942858
This change reverts the addition of deferred start and end dates on invoice PDF reports. The dates were being shown for all customers, which was not intended, so the report is restored while a better approach is assessed.
Original PR description
In this commit https://github.com/odoo/enterprise/commit/84e0edcfc88c3361e1e042e80c82f6c4b950c738, we added the deferred_start_date and end_date in the pdf. This change is applied for everyone and it shouldn't be. A next task will be created to assess this problem but in the meantime we will revert the commit no task-id
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
A search button has been added to the WhatsApp tab in mobile view, allowing users to easily find and search for WhatsApp channels on their mobile devices. This improvement enhances the mobile user experience by providing the same search functionality that was previously only available on desktop.
Original PR description
**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 Forward-Port-Of: odoo/enterprise#62680 Forward-Port-Of: odoo/enterprise#59530
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