Daily updates from Odoo
Wednesday, May 20, 2026
6 changes · saas-18.2
Resolved issues and error corrections
This update fixes an error in the Luxembourg Annual VAT Declaration report that resulted in incorrect calculations for Appendix E 1a. The fix ensures that key financial data is accurately included in the report formula, improving the reliability of VAT reporting for Luxembourg businesses. This resolves a discrepancy in the reported total.
Original PR description
### Issue: The formula `L10N_LU_TAX_163` in the Luxembourg Annual VAT Declaration was incorrect: - `L10N_LU_TAX_791.year_start` was added twice - `L10N_LU_TAX_993.year_start` was missing As a result, the computed total in Appendix E 1a was incorrect ### Steps to reproduce: - Install `l10n_lu_reports` - Open the `Report: Annual VAT Declaration (LU)` - Go to `Appendix E` - Use the `Start of Financial year` pencil icons to manually set values for fields `791` and `993` - Check the computed value of field `163` After the fix, both values are included exactly once in the formula opw-6158950 Forward-Port-Of: odoo/enterprise#117214
This update resolves an issue where signed PDF documents lost their original bookmarks and links. The fix ensures that signed documents remain fully navigable and consistent with the original PDF, preserving document structure and integrity for users.
Original PR description
Version - 18.0 Steps to reproduce: 1. Upload a PDF document containing bookmarks and internal/external links. 2. Sign the document and download the signed PDF. 3. Open the downloaded file and check the bookmarks and links. Issue: When a signed document was downloaded, the original PDF bookmarks And the links were not working. This broke structured navigation and affected document integrity. Fix: The PDF signing process has been updated to preserve the original bookmarks and ensure internal and external links remain functional after signing. Impact: - Signed documents remain navigable and consistent with the original PDF. - Preserves document structure and integrity. Task- 4915124 Forward-Port-Of: odoo/enterprise#108684
This update fixes an error that occurred when selecting shift templates on planning slots, specifically when dealing with long periods of leave. The change ensures the system falls back to a previously calculated end date if the template's calculation fails, preventing the application from crashing. This improves the reliability of shift planning.
Original PR description
Currently, an error occurs when a user selects a shift template on a planning slot. **Steps to Reproduce:** - Install the `Planning` module with demo data. - Create a `Resource Time Off` record with…
Currently, an error occurs when a user selects a shift template on a planning slot. **Steps to Reproduce:** - Install the `Planning` module with demo data. - Create a `Resource Time Off` record with `start` and `end date` separated by more than `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week. - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create a `new one`, and set the `Working Days` to more than 1 day. - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above `shift template`. `AttributeError: 'bool' object has no attribute 'replace'` This error occurs because when the user sets the shift template, the compute method runs to calculate the start and end datetimes [1]. It computes the end datetime by adding the template duration in working days from the given start datetime using the resource working calendar within a searchable range of around 1400 days [2]. During this computation, leaves and non-working days are skipped [3]. If no valid working interval is found within the searchable range, then it returns False [4], which raises the error [5]. This commit ensures that if plan_days returns False, the computation falls back to the previously calculated end date. [1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671 [2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835 [3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537 [4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835 [5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654 sentry-7472958590 Forward-Port-Of: odoo/enterprise#117073
This update resolves an issue where cancelled food delivery orders continued to show as 'Draft' in the Point of Sale system. The fix synchronizes PoS order states with delivery cancellations, ensuring that preparation displays accurately reflect the cancelled status. This improves order visibility and prevents confusion for staff.
Original PR description
pos*: pos_urban_piper, pos_enterprise When a food delivery order is cancelled from the aggregator side, the PoS order remains active on the frontend instead of reflecting the cancelled state. Steps to reproduce: - Configure UrbanPiper with Atlas - Place an order via Atlas - Open the order from the notification bar - Cancel the order from Atlas Issues: - Cancelled orders continue to appear in `Draft` - Accepted/preparation orders are not cancelled on the preparation display Fix: - Synchronise the PoS order state with the delivery state on cancellation - Update preparation display orders when delivery orders are cancelled Task-6217704 Forward-Port-Of: odoo/enterprise#117374
This update resolves an issue where removing orderline notes on the preparation display would incorrectly mark the line as cancelled and create a new one. The fix ensures that note history is recorded regardless of whether the note is confirmed, allowing the system to accurately update existing orderlines instead of creating duplicates.
Original PR description
Steps to reproduce: --------- 1. Create an order with an orderline general note. 2. Send the order to the preparation display. 3. Remove the note from orderline. 4. Resend the order Issue: --------------- Removing the note changes the preparation line key, so the preparation display marks the old line as cancelled and creates a new one instead of updating the existing line. Cause: ----------- The note history was only recorded when the note was confirmed. If the user simply removes/clears the note, no note history entry is generated, so the backend cannot match the previous key with the updated key. Fix: ---------- Record note history even when the note is discarded (not only when confirmed. This allows the backend to match the old and new keys and update the line instead of cancelling it. Task-6101501 Related PR - https://github.com/odoo/odoo/pull/258632 Forward-Port-Of: odoo/enterprise#113514
This update corrects a translation issue within the Gantt view, specifically the button used to toggle display modes. The change ensures that all button labels are accurately translated, improving the user experience for international users. This was reported and resolved by our translation team.
Original PR description
The title of the button allowing to toggle the display mode in the Gantt view was not translated. This commit adds a getter to compute the title based on the current display mode, and uses it in the template. Issue reported by translator. Forward-Port-Of: odoo/enterprise#117739