Daily updates from Odoo
Monday, June 10, 2024
15 changes · 17.0
New functionality added to Odoo
A new Rhodes module has been created and added to the Odoo system. This module extends Odoo's functionality with new capabilities specific to Rhodes operations. The addition enables users to access Rhodes-related features within their Odoo environment.
Original PR description
Creation of Rhodes module 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
Enhancements to existing features
The salary configurator now intelligently handles document uploads by only requiring new files when they don't already exist on the contract. If a document is already on file, employees will simply see the existing file instead of being asked to upload it again. This reduces unnecessary re-uploads and streamlines the salary setup process.
Original PR description
Document fields in the salary configurator now check for existing files on the current contract. Fields are set to required only if no associated file is detected on the contract, otherwise we just show the already existed file. Task-3468245
This update prevents employees from deleting leave records for future periods when a payslip has already been generated and paid for that time. This protects payroll integrity by ensuring leave data remains consistent with finalized payroll records.
Original PR description
Employees should not be able to delete leaves in the future when there's a payslip generated and paid for that period. Task-3776411
Resolved issues and error corrections
Fixed a bug in the Planning module that prevented users from assigning a resource to multiple scheduling slots at once. Previously, attempting to select multiple empty slots and assign a resource would cause an error. This update allows the resource assignment feature to work correctly with multiple slots, improving the user experience when managing schedules.
Original PR description
Steps to reproduce: - Install Planning - Click on Schedule -> By Resource - Select multiple slots without a resource - Select a resource to add Issues: A traceback is shown because this line in the write function wasn't coded to work with recordset. https://github.com/odoo/enterprise/blob/70f0ce78ac5f976f93abd0b9ee239a998d6d7445/planning/models/planning.py#L803-L806 opw-3948517 Forward-Port-Of: odoo/enterprise#63450
A bug in the helpdesk module was causing unwanted email addresses to be added as ticket followers when multiple email domains were used. This fix ensures that only legitimate emails are added as followers by properly filtering out the helpdesk team's email alias, regardless of which domain it uses. This prevents confusion and keeps ticket follower lists clean and accurate.
Original PR description
With the introduction of alias domains in 17.0 an issue was uncovered in the helpdesk module where any additional alias names with different domains would be added as followers. This stemmed from an issue in _ticket_email_split which was not properly filtering emails out that matched the alias name because self was not yet defined when the method was called. This was not a problem before because this was immediately fed into _mail_find_partner_from_emails that would also filter out by alias_name. This is no longer the case because the domain has to also match. Passing in the newly created ticket and using this to map to team_id.alias_name fixes this issue by properly filtering out alias emails even with different domains. opw-3920634
This update corrects how Greece is identified in Dutch intrastat and tax reports. Greece uses different codes depending on the context—the ISO standard code (GR) versus the European Union code (EL). Since these are European reports, the EU code is now used consistently, ensuring accurate reporting for transactions involving Greece.
Original PR description
For Greece, the ISO 3166 code (GR) and European Union code (EL) is not the same. Since this is a european report, we need the European Union code. opw-3890635 Forward-Port-Of: odoo/enterprise#64087
This fix prevents spreadsheets from becoming unusable after users perform many large operations. The system now creates automatic snapshots every 2 hours instead of every 12 hours, which reduces the amount of data the server needs to load when reopening a spreadsheet. This prevents memory issues that could occur when handling very large spreadsheets with extensive edit histories.
Original PR description
Purpose ------- Let's say a user works a lot on a spreadsheet and performs a lot of heavy operations generating very large revisions (with lots of commands), such as copy-pasting a very large zone (there's one UPDATE_CELL command per copy-pas cell) If the user does multiple such very large revision, one after the other, every thing is fine client side. The next time the spreadsheet is open though: the server needs to load all those revisions to send them to the client. The revisions can be so large it can blow up the server memory limit. The spreadsheet cannot be open anymore. Solution -------- In this commit, we increase the number of snapshot by snapshotting more often. Previously, we used to snapshot when opening a spreadsheet and no activity was done in the spreadsheet in the last 12 hours. It's reduced to 2 hours in this commit. The reason we don't want to snapshot too often is that it kills the local history (CTRL+Z) of connected users. Task: 3940465
Fixed a bug where US payment files generated after 5 PM in Pacific timezone would incorrectly show tomorrow's date in the File Creation Date field. The system now correctly uses the user's local timezone when setting this date, ensuring accurate file timestamps regardless of when the file is created.
Original PR description
When a user in US/Pacific generates a file after 17:00 the File Creation Date field incorrectly has tomorrow's date. To fix it use the localized timestamp for the File Creation Date as well. opw-3942095 Forward-Port-Of: odoo/enterprise#64172
This fix resolves an issue where generating a bill in a restaurant Point of Sale would incorrectly send the order to the kitchen. The change removes unnecessary kitchen order processing during the billing step, ensuring orders only go to the kitchen when actually needed for food preparation.
Original PR description
Problem: In restaurant, when we make a bill, the order is made to the kitchen Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" and "pos_preparation_display" modules - Open a restaurant session - Select products for a table - Click on "Bill" - The order is now in the kitchen while it should not Cause: The full process for making an order is called with "sendOrderInPreparationUpdateLastChange" while it is not necessary to make a bill Solution: Remove the "sendOrderInPreparationUpdateLastChange" for the bill screen when pos_preparation_display is installed Note: Linked with this PR: https://github.com/odoo/odoo/pull/166844 opw-3938924
This fix corrects how payment references are extracted from bank statement files (CAMT format) across different countries. Previously, a field that is sometimes populated in non-Nordic countries like Switzerland was being checked first, causing incorrect or missing payment references. The fix reorders the priority of where to look for payment information to ensure the most reliable reference is captured first, improving the accuracy of imported bank transactions.
Original PR description
In previous commit https://github.com/odoo/enterprise/commit/099531438fe9ef7b008a2b281780ed3ee2175692 we added a new tag check. As we tought it was empty for non-nordic countries, we thought it was fine to have it in first place but happens it is sometimes filled in other countries but not with the payment reference, as in Switzerland. We now check to fill payment_ref, in order: 1. NtryDtls>RmtInf>Ustrd 2. NtryDtls>RmtInf>Strd>CdtrRefInf>Ref 3. Ntry>AddtlNtryInf (was buggy before https://github.com/odoo/enterprise/pull/62703) 4. NtryDtls>RmtInf>Strd>AddtlRmtInf opw-3923665 opw-3971080 opw-3932651 opw-3918491 Forward-Port-Of: odoo/enterprise#64004
This update prepares the Belgian POS blackbox system for Version 17 certification with several operational improvements. Key changes include removing the reprint option from the tip screen, enabling invoicing of previously non-invoiced orders, and allowing order cancellations that were previously restricted. The system now automatically handles work clock in/out, supports cash in/out operations, and ensures accurate sequence numbering on receipts and logs.
Original PR description
In anticipation of Version 17 certification, multiple adjustments were required. The option to reprint tickets has been eliminated from the tip screen. Furthermore, the functionality on this screen has been rectified to enable the invoicing of previously non-invoiced orders. Previously, this action was not feasible when an order was placed using a blackbox. This commit also involves alterations to values within the sale details template. Moreover, steps have been taken to guarantee the precision of sequences for both pro forma and standard sales. We've now enabled the option to cancel orders that were previously restricted.
This update fixes a bug where the system incorrectly rejected valid UTM source names as duplicates. The issue occurred when users deleted marketing templates but the associated tracking names remained in the system. The fix ensures the system properly checks for existing names across all tracking records, not just active templates, preventing false duplicate errors.
Original PR description
With this commit whenever utm.source name is written it will check its uniquness (generating a unique name if necessary). [Reproduce] - Install marketing_automation - Have Campaign with a Template: -…
With this commit whenever utm.source name is written it will check its uniquness (generating a unique name if necessary). [Reproduce] - Install marketing_automation - Have Campaign with a Template: - Access the Campaign's Template and go to the Settings tab. - Note down the NAME of the `utm.source` (found in the Advanced section, under the field "Name"). - Delete this template (which will also delete associated `mailing.mailing` records.) - Create new template (by returning to the Campaign form, opening an activity, creating template) - Open the Campaign's Template: - Disable read-only on the Name field in Advanced section (modify the `mailing.mailing.form` view). - Change its name to the previously noted `utm.source` NAME. - Save -> BUG: Trackback "The name must be unique" [Why this bug happens?] When you delete a template (`mailing.mailing`) related to a `utm.source`, the `utm.source` will still exist. Then, when attempting to change the `utm.source` name, the system is supposed to detect if the name already exists and generate a new unique name if necessary. However, due to the mechanism utilized in the function (ref.1), which searches for existing names based on existing templates (`mailing.mailing`), which you have deleted, the existing `utm.source` NAME won't be found. Consequently, the function mistakenly believes the name is unique and doesn't generate a new name, leading to the encountered error. (ref.1) `UtmMixin._get_unique_names` https://github.com/odoo/odoo/blob/205caa3d6539187009a8b8bbd1557e75fe045ff3/addons/utm/models/utm_mixin.py#L77 opw-3835704 Forward-Port-Of: odoo/enterprise#63993 Forward-Port-Of: odoo/enterprise#63360
This update fixes a reliability issue with the WhatsApp message unread counter that was not accurately tracking unread messages. The fix ensures that users see the correct number of unread messages in their WhatsApp conversations, improving the accuracy of message notifications and helping users stay on top of their communications.
Original PR description
opw-3877370 community: https://github.com/odoo/odoo/pull/165955
This fix resolves a critical error that prevented users from updating payments after creating and signing PPD invoices and external trade documents in the Mexican localization module. The issue caused the system to crash when attempting to process payment updates, which is now corrected to ensure smooth payment workflows.
Original PR description
Currently, a traceback with `KeyError: 'emisor'` occurs when attempting to update payments after creating and signing a PPD and external trade invoice, and registering a payment. opw-3904458
This update fixes a crash that occurred when users tried to access call activities that had been removed from the Call Queue. The system now properly updates the record when a call activity is deleted, ensuring the interface refreshes correctly and prevents errors when clicking on removed activities.
Original PR description
When call activity gets deleted, the record has to be updated so that it can trigger automatic re-rendering of the component. Steps to reproduce: - on crm lead schedule call activity and make sure that activity is at least 1 month old - book activity and save it - add it to `Call Queue` - remove it from `Call Queue` - try to access it/click on it