Tuesday, March 24, 2026
12 changes · 18.0
Resolved issues and error corrections
This update corrects a small, unintended message appearing in the documents generated for employee payroll. This ensures a cleaner and more professional presentation of payroll information for employees and managers. The change improves the overall user experience.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update fixes a potential issue where an employee's work email could be unintentionally modified when linked to a user. This change ensures that the work_email remains consistent, preventing indirect email manipulation and improving data integrity. It addresses a bug related to offer updates.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974 employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. ### Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382
This update corrects a problem where translations were not consistently appearing in the Chilean VAT reporting module (l10n_cl_edi_factoring). The change simplifies the code to ensure accurate translation lookup, specifically addressing issues on Ubuntu Jammy and Debian Bookworm. This ensures correct VAT reporting functionality.
Original PR description
This commit transforms the list comprehension into a regular for loop to avoid the translation missing context when looking up for lang. Note: the issue appeared more specifically on Ubuntu Jammy and Debian Bookworm. runbot-240951
This update corrects a technical issue where FedEx's VAT number limitations caused problems with certain customer records, particularly those using Swiss VAT formats. The change ensures that VAT numbers are properly formatted for FedEx, preventing delivery errors and maintaining accurate data. This resolves a compatibility issue with the FedEx shipping service.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452
A technical problem prevented users from correctly accessing WhatsApp event notifications. This update fixes a validation error that was incorrectly restricting access based on the event type, ensuring all approved event registrations now receive WhatsApp notifications. This resolves a reported issue impacting event communication.
Original PR description
Issue:
1) User goes to Event.event Form -> communication tab -> add line 2) Select whatsapp -> type something -> create and edit -> create new template with any model except event.registration -> save ( all the way including the event form) 3) reload page -> whatsapp event.mail displays "User does not have access to this record".
Fix: Added validation errors for the same criteria as the domain below inside the create and write of the event.mail model
"Domain.AND([[('model', '=', 'event.registration')], [('status', '=', 'approved')], domain])"
https://github.com/odoo/enterprise/blob/b06da04210f820e91ae2c829afe10fd8c82ed1f4/whatsapp_event/models/whatsapp_template.py#L19-L21
opw-6037488This update ensures that VAT reports (l10n_rs_edi and l10n_pl_edi) consistently attach related documents within the same transaction. Previously, updating move fields and attachments separately could lead to inconsistencies. This change improves data integrity and reliability for VAT reporting.
Original PR description
Was committing the move fields update, then updating the attachment. This might create an issue were the move update commits successfully, but setting the attachment fails and we end up with an inconsistency. Set attachment in the same transaction as the move update. task-6035727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255262
A test within the MRP module was failing due to a dependency on a module only available in the Enterprise version of Odoo. This update removes the problematic dependency, ensuring the test now runs successfully across both Community and Enterprise environments. This resolves a test failure and improves overall test coverage.
Original PR description
The test `test_multi_lot_component_consumption` relies on `move_raw_line_ids`, which is initialized by the `stock_barcode_mrp` module. This module is only available in enterprise, causing the test to fail in community setups. https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/mrp/tests/test_consume_component.py#L481 runbot-241990
A minor bug in the Point of Sale test suite was causing it to fail. This update ensures that changes to order data are properly synchronized with IndexedDB before page refreshes, preventing data loss and improving test reliability. This ensures consistent test results and a more stable Point of Sale experience.
Original PR description
During the tour test `CustomerNoteIsPresentAfterRefresh`, we set a customer note on an order line and then refresh the page. Even though we wait for the customer note to be written on the `pos.order.line` record, the change must also be saved in IndexedDB before the refresh. Otherwise, the data reloaded after the refresh does not contain the customer note, causing the test to fail. The issue was that the page refresh could happen before the debounced `syncDataWithIndexedDB` was completed. To fix this, an additional step was added in the tour to wait briefly, ensuring that `syncDataWithIndexedDB` finishes before refreshing the page. --- Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231435
This update ensures Odoo's cbor2 library aligns with the latest Debian Bookworm and Ubuntu Jammy versions, including a pre-built wheel. This change improves stability and performance by using a more current and optimized version of the library.
Original PR description
This commit sets the cbor2 library's version to match more closely the Debian Bookworm/Ubuntu Jammy packaged versions and to match the ones with a prebuild wheel. Note: while the 5.4.2 already matched the one from Jammy, it didn't provided a corresponding wheel, which the 5.4.2.post1 did fix (cf. https://github.com/agronholm/cbor2/releases/tag/5.4.2.post1). runbot-238903
This update fixes a previous restriction that prevented users from editing taxes on reward lines within confirmed sales orders. Previously, confirming an order would recompute taxes on these lines. Now, tax edits are permitted on confirmed reward lines, ensuring accurate order calculations without impacting the order's final price.
Original PR description
Issue: --- Due to this issue, the tax on reward SOL cannot be edited. Cause: --- This is introduced in #172110 to prevent users from editing taxes on reward lines because confirming the order would recompute the tax. We can make it editable on confirmed SO as the tax wouldn't recomputed on reward lines later. opw-5918435
This update resolves a confusing error in the website editor related to loading custom Google Map snippets. The fix prevents errors when users create custom snippets from disabled base snippets, ensuring a smoother editing experience. It also clarifies which snippet is the Google Map snippet.
Original PR description
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4.…
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4. Enable developer mode and refresh the website editor 5. Add a new Google Map snippet to the page a. The Google Map snippet is the one where the icon shows a map with a pin on the **left side**. 6. In the wizard, enter your valid API key and click Save a. Alternatively, you can use Odoo inspector to write any string into the `google_maps_api_key` field of the `website` model to simulate the above 7. Disable developer mode and refresh the website editor 8. Click one of the categories in the editor side panel to open the snippets browser 9. Click into the 'Custom' snippets category 10. Observe the error Depending on whether or not you have a Google Maps API key configured on your website, either the `s_map` or `s_google_map` base snippet will be disabled/hidden. When a user has created custom snippets out of the disabled base snippet, you will recieve the error mentioned above when the snippet browser attempts to load in these custom snippets, as it will be unable to load the base snippet. To fix this, we check if an original snippet was found when loading in a custom snippet. If not, we will not load in the custom snippet to avoid confusion. This error does not occur in Developer Mode, as both base snippets are always enabled in this case. Aditionally, we also clarify which snippet is the Google Map snippet to avoid confusion for the user when creating custom snippets. opw-5933787
This update ensures survey invitations are sent in the correct language for recipients with different language preferences. Previously, mixed-language groups received invitations in a default language. This fix uses recipient language settings to deliver personalized invitations, improving user experience and data accuracy.
Original PR description
When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language. ### Steps to reproduce 1. Install the "Surveys" module and activate a second language (e.g., Dutch). 2. Create a survey and ensure its invitation template has translations for both languages. 3. Create two contacts: one with English as their language and another with Dutch. 4. On the survey, click "Share" and add both contacts as recipients. 5. Send the invitations. 6. The contact with Dutch preferred language receives the email in English. ### Cause By default, the wizard uses a single language for every email in a batch. While it can switch this language if everyone in the group speaks the same tongue, it fails to do so for mixed-language groups. Adding compute_lang=True fixes this by telling the system to look up and use the correct language for each recipient one by one. opw-5868581