Daily updates from Odoo
Wednesday, February 4, 2026
24 changes · 18.0
Security fixes and vulnerability patches
This update fixes a security vulnerability where temporary credentials (RDTs) used to access customer data were being logged in application logs. This prevented sensitive information like buyer names and addresses from being exposed outside of controlled environments, reducing the risk of data breaches. The change disables logging for operations handling these sensitive credentials.
Original PR description
Previously, the connector logged all SP-API responses for debugging purposes. When operation is `createRestrictedDataToken`, this would also log the `restrictedDataToken` in plaintext. RDTs are short-lived credentials that grant access to PII (buyer names, addresses, etc.) and should not appear in application logs. While the token is only stored in memory while in use, logs are frequently shared in support tickets, error reports, and monitoring systems without the same access controls, making credential exposure far more likely. This commit adds a parameter to disable logging for operations that return sensitive data. opw-5491878 Forward-Port-Of: odoo/enterprise#105178
Enhancements to existing features
This update adjusts a test case within the l10n_pe_edi module to reflect a recent change in how debit notes are processed through Peppol. This ensures the test case accurately validates the system's functionality after the Peppol update. The change was necessary to accommodate the addition of a new node during debit note creation.
Original PR description
A Node was added when creating debit notes in peppol, so the change was also applied to the debit note template to adjust a test case task-5875689
Resolved issues and error corrections
This update prevents users from creating duplicate attendance records when network connections are unstable. The fix introduces a timeout for location tracking and a system to avoid multiple check-in/out clicks, ensuring accurate attendance data and a smoother user experience. It addresses a previous issue where prolonged network interruptions led to incorrect record creation.
Original PR description
when using signInOut with geolocation, slow or temporarily unavailable network connections could cause getCurrentPosition to hang indefinitely (default timeout is infinite). This led to: - Frontend…
when using signInOut with geolocation, slow or temporarily unavailable network connections could cause getCurrentPosition to hang indefinitely (default timeout is infinite). This led to: - Frontend not updating, allowing multiple clicks and creating duplicate attendance entries - Incorrect check-in/check-out data __Steps to reproduce:__ 1. check in while online and server reachable 2. disconnect network or make server unreachable 3. check out Currently, getCurrentPosition would hang indefinitely. till the network is restored. then it will trigger the rpc call much later than the action time. in the meantime, the user could click multiple times, creating multiple attendance records. With this fix, getCurrentPosition will timeout after 10 seconds, then it will proceed without position. and if the server is unreachable, it will show an error notification without allowing multiple clicks. __FIX__ - Adds a timeout to getCurrentPosition - Uses a `_attendanceInProgress` flag to prevent multiple clicks - Ensures only the first callback (success or error) triggers the RPC opw-5414044 Forward-Port-Of: odoo/odoo#244477
This update fixes a problem where automated tests relied on specific demo data, causing inconsistent results. The change ensures tests always use a consistent partner for searching, improving the reliability of our automated testing process. This enhances the overall stability and predictability of our website sales functionality.
Original PR description
As part of the forward part for [1] the shop mail tour was updated because the new demo partner was earlier alphabetically than the partner generated for the test, and tests run with demo data for CI in this version. The test should create a partner that will appear first in the m2o selection regardless of whether demo data is installed. [1]: 549708965924b17403ef7c8e6a6d5bc43af460c3 runbot-238406 Forward-Port-Of: odoo/odoo#245753
This update resolves a test failure in the restaurant POS booking process. The fix replaces a method used for general loading with one specifically designed to wait for RPC requests, ensuring the tour accurately reflects the system's behavior when booking and releasing tables. This improves the reliability of the test and the overall booking experience.
Original PR description
Fix failing tour `test_book_and_release_table` by replacing `waitForLoading`, which is intended for POS loading, with `waitRequest` to properly wait for RPC requests. Error-227652 Task-5897383
This update resolves an issue where users could select product variants with excluded options in the Point of Sale system. The fix ensures that selected attributes are properly considered when determining if a variant is allowed, preventing incorrect product selections. This improves the accuracy and reliability of the POS experience.
Original PR description
Step to reproduce: - for a product A, have 3 attributes, legs , color and extra options (type: multi) - for a color attribure values (eg red) exclude one option of 'extra options' - open pos and select this product - select "red" and excluded option Observation: - you are able to select this variant but shouldn't as it is excluded Fix: - previously, we do not considered selected attributes for `multi` attributes in `getVariantAttributeValueIds` - we now compute 'exclusion' for all product once and then use it at runtime, to qualify if variant is allowed or not. opw-5220427 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where enabling tracking on custom HTML fields within invoices caused update failures. The change hides the 'Enable Ordered Tracking' option for these fields, preventing the error and ensuring data updates function correctly. This improves data integrity and reliability for invoice modifications.
Original PR description
From https://github.com/odoo/odoo/pull/241367#issuecomment-3711040501 Nothing prevent tracking from being enabled on HTML fields, but if it is enabled, updates of the field systematically fail. This commit avoids this error by hiding the "Enable Ordered Tracking" for HTML fields. Steps to reproduce: - Install sale and web_studio - Activate debug mode - Add a custom HTML field inside the invoice form view - Open the "More..." of the field (or go to Settings/Technical/Field) and go to the new field - Set "Enable Ordered Tracking" to 1 - Save - Go to an invoice and modify the new field - Save => An error was displayed task-5236436 Forward-Port-Of: odoo/odoo#242183
This update resolves a bug where the timer stopped appearing for survey participants after submitting their answers in live sessions. The fix ensures the timer correctly displays for the duration of the live session, regardless of whether the participant finishes or the session ends, improving the participant experience.
Original PR description
Description of the issue/feature this PR addresses: Fixes timer not showing to participants of a live session after submitting an answer. Current behavior before PR: Steps to reproduce: Create a…
Description of the issue/feature this PR addresses: Fixes timer not showing to participants of a live session after submitting an answer. Current behavior before PR: Steps to reproduce: Create a Survey with two questions of any type. Set some Question Time Limit on both. Create Live Session for that Survey. Access Live Session as a participant. Start Survey as the host. The first question appears to the participant, with the timer on the top right. Answer the question as the participant and click Submit or press Enter. On the host side move to the next question. Bug: timer for the second question does not appear to the participant. Desired behavior after PR is merged: Fix: The logic to hide the timer is on `survey_form.js`. In the `_nextScreen` function. Specifically, when `options.isFinish` is set to `true`. It is set to `true` in the `_onSubmit` function. This function triggers when the participant submits an answer. The fix: only set that flag to `true` if there isn't a session in progress. This aligns with the other calls to `_nextScreen` for live sessions. That is, when a timer expires and the form is submitted: `'isFinish': !this.options.sessionInProgress` and when a notification is received for the session: `isFinish: nextPageEvent.type === 'end_session'` Meaning that for live sessions the only time `isFinish` should be set to `true`, is when the `end_session` notification is received. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241086
This update fixes an issue where the toolbar remained visible on mobile devices when the side menu or a popover was open, obstructing the user's view. Now, the toolbar automatically hides when a popover or sidebar is active, providing a cleaner and more intuitive mobile experience. This enhancement improves usability and accessibility.
Original PR description
In mobile, when the side menu or a popover is opened, the toolbar remains displayed above the keyboard. This commit hides the mobile toolbar while such elements are opened. Steps to reproduce: - In mobile, go to a "To do" note - Put cursor inside text to display the toolbar - Open the hamburger menu => The toolbar remained displayed on top of the side menu - Open the gear menu => The toolbar remained displayed while the menu was opened task-5222582
This update fixes an issue where vendor bill labels on payable lines were not correctly populated when the Payment Reference was empty. Now, the payable line label automatically displays the Bill Reference when no Payment Reference is provided, and updates accordingly when the Payment Reference is changed. This ensures accurate labeling of vendor bills for better reporting and reconciliation.
Original PR description
Before PR: - On vendor bills and refunds, if the Payment Reference is empty, a placeholder saying `Use Bill Reference` is shown. But the Bill reference is still not written on the Payable line, making the label empty. - When Payment Reference is set, updating the Payment Reference does not update the payable line label. After PR: - The payable line label is now populated with the Bill Reference when the Payment Reference is empty. - Now, when Payment Reference is set, updating the Payment Reference updates the payable line label. - Modified the test cases which were failing due to an empty label. Related PR (Enterprise) : https://github.com/odoo/enterprise/pull/91535 Task : 4982864
This update fixes an issue where user information (name, email, etc.) entered as global questions during event registration wasn't being saved to the registration record. Now, this data is correctly captured and stored, improving the accuracy of event registration data. This ensures better reporting and management of event attendees.
Original PR description
Before this commit: =================== - When an event uses a user's fields (name, email, phone, company_name) as a global questions (once per order), these values were not saved on the event registration record. After this commit: ================== - User fields defined as global questions are now correctly populated on the event registration record. Task: 5462923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update replaces the SFU (Server-Side File Upload) bundle with version 1.3.3, addressing a technical update to improve the performance and stability of file uploads within Odoo. This change ensures continued optimal functionality for users uploading and managing files.
Original PR description
https://github.com/odoo/sfu/releases/tag/v1.3.3 Forward-Port-Of: odoo/odoo#244971
This update allows users to reset Vendor Bills (e-invoices) received from ANAF to a draft state, even if they are currently in an 'EDI' processing stage. This change is necessary due to a recent update consolidating the e-invoice functionality into the broader 'l10n_ro_edi' module, ensuring proper processing of e-invoices. It improves the flexibility for users to manage their invoices.
Original PR description
Adjusting the visibility check for "Reset to draft" button to allow Vendor Bills received from ANAF to be reset even when they have a EDI state. Will require to be shifted to `l10n_ro_edi` in 18.0+ as the efactura module is merged into it. task-5892651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246697
This update resolves an issue in the account_edi_ubl_cii module related to how the 'LineExtensionAmount' is calculated. The change introduces a new value to account for global tax rounding differences, ensuring accurate untaxed and total amounts in generated invoices. This prevents potential discrepancies and maintains data consistency.
Original PR description
…-10] According to [BR-CO-10], LineExtensionAmount should be: <quantity> * <price_unit_wo_tax> + charges - allowances It was implemented as: <quantity> * <price_unit_wo_tax> + charges - allowances + <delta_total_excluded> <delta_total_excluded> is needed because it's the additional delta distributed by the global rounding of taxes accross the lines. If you don't add it, you will change the untaxed and total amount of your document. Instead, this commit adds 2 new values in the base_lines's tax_details: gross_total_excluded & discount_amount being the rounded versions of raw_gross_total_excluded & raw_discount but taking care of maintaining a global consistency regarding the global rounding. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing legal validation of the annual VAT report for Luxembourg companies. The fix adds missing required fields to the XML export, ensuring compliance with tax reporting regulations. This ensures accurate and legally compliant VAT reports are generated.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing ### Note: This PR is related to the 17.0 PR: https://github.com/odoo/enterprise/pull/105143 opw-5119920
This update resolves an issue where the POS ID wasn't being correctly transmitted to the blackbox during v1 CleanCash integration. The fix ensures accurate data transmission, improving the reliability of the fiscal data reporting process. Additionally, a security enhancement restricts blackbox device selection to the Fiscal Data Module in POS configuration settings.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448
This update resolves an issue where tickets in 'folded' (closed) stages were incorrectly displayed in the helpdesk email plugin. The fix ensures that closed tickets are filtered out, preventing them from appearing in the plugin's results and improving the user experience. This ensures users only see active tickets.
Original PR description
**Steps to reproduce:** - Install Mail_plugin - Setup the outlook mail plugin in Outlook - Once connected, click on a mail from a contact on the database - Click on the Odoo Inbox Addin. action - Under the contact 5 related tickets are showed - Create 5 tickets with priority and put them in folded stage (closed) - Create new normal tickets - User can't see new tickets in the plugin **Issue:** The search is done on priority and then id ordering, this means that tickets in folded stages (closed) which have a high priority are always showed first. Tickets in a folded stage are considered as closed, so they should not appear anymore in the contact data to avoid displaying them indefintely. **Fix:** Adapted search domain and removed fold attribute in the answer. opw-5075477
This update resolves a problem with Indian GST reports where test cases were failing due to a recent change in how payable lines are labeled. The test cases have been updated to now correctly account for the new label format that includes the bill reference, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864
A bug was causing incorrect order quantities to be sent to the kitchen when using the numpad in the POS Restaurant Preparation Display module. This was resolved by adding a brief delay to ensure the quantity is updated before the order is submitted, preventing errors in the kitchen display.
Original PR description
TASK: [#5897381](https://www.odoo.com/odoo/project/1737/tasks/5897381) --- Inside tour tests environment for POS Restaurant Preparation Display module, when using the numpad to change the quantity of a product in the POS and sending the order to the kitchen immediately after, there is a chance that the quantity is not updated in time. This could lead to sending an order with an incorrect quantity to the kitchen display. As a result, the test `test_payment_does_not_cancel_display_orders` was failing. We add a small delay after using the numpad to ensure the quantity is updated before sending the order.
This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems on their end. The change now excludes these zero-price products from the sync process, ensuring smoother integration with UrbanPiper and preventing potential errors.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272
This update resolves an issue preventing the legal validation of annual VAT reports for Luxembourg companies. The fix adds missing required fields to the XML export, ensuring compliance with reporting regulations. This resolves a technical problem impacting report generation and submission.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#105143
This update resolves an issue where the 'Validate' button in the shopfloor picture instruction wizard remained disabled after a user encountered an error (missing picture). The fix ensures the button is re-enabled, preventing users from needing to restart the wizard and improving the manufacturing workflow. This enhances user experience and efficiency.
Original PR description
Current behavior: When trying to validate a picture instruction in shopfloor, Odoo legitimately raises a UserError if the picture is missing. However, even after adding a picture afterward, the…
Current behavior:
When trying to validate a picture instruction in shopfloor, Odoo legitimately raises a UserError if the picture is missing. However, even after adding a picture afterward, the Validate button remains unclickable, forcing the user to close the wizard and start again.
Expected behavior:
Even if an error occurs during validation, the Validate button should remain clickable (especially once the cause is addressed).
Steps to reproduce:
- Create a BoM with one operation - Save.
- Add a "take a picture" instruction on this operation.
- Create a MO with this BoM, confirm it.
- Go to the shopfloor, find the WO of the created MO. Open "instructions".
- Click on the small camera to open the check wizard.
- Confirm without taking a picture or uploading an image.
- Error pops up ("Please upload a picture"), close the popup.
- Then add a picture. => The Validate button remains unclickable. We need to close and re-open the wizard to continue, which can be frustrating and time-consuming for manufacturing users, especially with many instructions.
Issue Explanation:
In MrpQualityCheckConfirmationDialog/doActionAndClose, this.props.record.model.orm.call can legitimately raise a UserError, but the button is disabled at the beginning of the method and remains in this state regardless of what happens afterward.
Fix:
Add a try-catch clause to re-enable the button if an error occurs.
Alternative fix:
The button should remain disabled until a picture is taken, but that sounds like a more disruptive change that might impact other flows.
### Open questions
Do we need to add a test for it? Only a JS tour is suitable which it seems a bit much for this kind of bug. What do you think?
https://github.com/odoo/odoo/pull/246481This update fixes an issue in the French P&L report where accounts 65 were incorrectly categorized. The accounts have been moved to the 'Other Expenses' line, ensuring accurate financial reporting and alignment with French accounting standards. This improves the clarity and reliability of the financial data.
Original PR description
On the french P&L, accounts 65 are refferenced in the line 'Other purchases and external charges' but this is not where those accounts need to be, they need to be part of the line 'Other Expenses' task-5446018 Forward-Port-Of: odoo/enterprise#103357
Documentation and clarification updates
This pull request updates our contributor agreement to include a new contributor from Aerospacelab. This ensures proper legal recognition and allows Aerospacelab to contribute to the Odoo project according to our guidelines. It's a standard process for onboarding new developers.
Original PR description
https://github.com/odoo/enterprise/pull/105990 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr