Daily updates from Odoo
Friday, May 22, 2026
10 changes · saas-18.4
Resolved issues and error corrections
A recent update caused errors when downloading signed documents through the Sign app. This fix corrects a problem related to how Odoo handles PDF compression, specifically with newer versions of the pypdf library. The change ensures documents download correctly without errors.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/enterprise#117999 Forward-Port-Of: odoo/enterprise#117756
This update resolves an issue where removing a general note from an orderline 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#117943 Forward-Port-Of: odoo/enterprise#113514
This update fixes an issue where the POS incorrectly applied AvaTax tax rates even when AvaTax wasn't activated in the POS settings. The system now correctly ignores AvaTax fiscal positions when a customer doesn't have a defined fiscal position, ensuring accurate tax calculations for Point of Sale transactions. This improves the reliability of the POS tax functionality.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 Forward-Port-Of: odoo/enterprise#116626
This update resolves an issue where the generic tax report wouldn't display an error message when dealing with negative net values. The fix ensures the report accurately checks for tax discrepancies, even when balances are negative, preventing misleading results.
Original PR description
**Issue:** In the generic tax report, a check is performed on the report lines to ensure that the declared tax amount is consistent with the expected amount. If the difference between the declared tax amount and the expected one is higher than 0.1% of the declared net amount, then a error message is displayed. If the net amount is negative, the error message is never displayed because the computed percentage of the tax difference is negative and therefore lower than 0.1% (i.e. 0.001). opw-6014350 Forward-Port-Of: odoo/enterprise#117990
This update improves the performance of Odoo's subscription module by adjusting how it tracks usage. The change ensures the system accurately reflects actual subscription usage, leading to faster query responses and a smoother user experience for subscription management. This optimization addresses a potential performance bottleneck.
Original PR description
runbot-163667
This update removes a redundant step in creating embedded actions within Odoo. Previously, manual translations were required; now that embedded actions automatically inherit translations from their linked actions, this workaround is no longer necessary. This simplifies the process and ensures consistent translations.
Original PR description
Now that `ir.embedded.actions` delegates its display name to the linked action, the manual translation copy on embedded action creation is no longer needed. Related: https://github.com/odoo/odoo/pull/262981 Forward-Port-Of: odoo/enterprise#116793 Forward-Port-Of: odoo/enterprise#116369
This update ensures that when a food delivery order is cancelled through the aggregator (Atlas), the corresponding PoS order is also correctly marked as cancelled in the system. Previously, PoS orders remained in an active state, leading to inaccurate order tracking. This fix improves order visibility and accuracy for both staff and customers.
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#117942 Forward-Port-Of: odoo/enterprise#117374
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 preserve the original document structure and integrity, improving user experience and data consistency.
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#117881 Forward-Port-Of: odoo/enterprise#108684
This update corrects a translation issue in the Odoo Gantt view. The button used to toggle display modes was not correctly translated, preventing users from seeing the view in their preferred language. This fix ensures all users can consistently access and understand the Gantt view's options.
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#117807 Forward-Port-Of: odoo/enterprise#117739
This update resolves an issue where constant fields within signing documents would become empty during the signing process, leading to signing failures. The fix ensures that default field values are retained when auto-fields return empty strings, preventing the 'Some required items are not filled' error and improving the reliability of the signing workflow.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create sign template. - Add a sign item with read only true and linked model and auto_value field set. - Send document for signing. - Try to sign the document. Issue: - Signing fails with "Some required items are not filled". - Constant readonly fields become empty during signing flow. Cause: - In `_populate_constant_items()`, the default field value was always replaced by `_get_auto_field_value()`. - When no reference document was set, `_get_auto_field_value() `returned an empty string. - This caused an empty value to be stored in `sign.request.item.value`. Solution: - Keep the default field value when auto-field resolution returns an empty string. - Only replace the value when a valid auto-field value is found. task-6229776