Daily updates from Odoo
Wednesday, February 4, 2026
11 changes · 18.0
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 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 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 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 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/246481