Monday, March 30, 2026
4 changes · saas-18.2
Enhancements to existing features
This update ensures Odoo automatically syncs product tags with UrbanPiper, resolving an issue where a single, hardcoded tag was used. Now, tags are dynamically determined based on tax configurations and aggregator needs, allowing UrbanPiper to receive the most relevant information for accurate order processing.
Original PR description
Before this commit: ------------------------------------------ - The UrbanPiper payload used a hardcoded tag when the tax percentage was not 5%. - There was no mechanism to add additional tags based on providers, even though UrbanPiper supports multiple tags. After this commit: ------------------------------------------ - Tags are now dynamically handled using the Tag field in the product. - Users can define tags according to their tax configurations and aggregator requirements. - UrbanPiper only accepts relevant tags (default or provider-specific). task - 5154061 Forward-Port-Of: odoo/enterprise#96742
Resolved issues and error corrections
This update corrects an issue preventing the export of Profit & Loss reports with footnotes enabled in the l10n_lu_reports module. The fix addresses a dependency on an outdated model, ensuring the export process now functions correctly and generates the necessary XML files. This resolves a technical problem impacting report generation for Luxembourg accounting.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#111845 Forward-Port-Of: odoo/enterprise#107765
This update fixes an issue where splitting shifts within a single day (using the 'day' view scale) incorrectly duplicated shifts and added unwanted working hours. The change ensures shifts are split accurately at the requested time, preventing time duplication and maintaining correct shift durations.
Original PR description
Since odoo/enterprise#69963, splitting a shift in Gantt view snaps the resulting shifts to the standard working hours (e.g., 08:00 to 17:00). This behavior makes sense when splitting a multi-day shift across a day off, where we want to generate a full working day for the day off as well. However, when splitting a shift within a single day (day scale), this behavior is not wanted, otherwise creating two shifts as follows: 1. A shift from [Original Start] to 5pm 2. A shift from 8am to [Original End] Clearly, the shift is duplicated with the wrong timeframes and adding time outside the original shift's hours. This commits ensures that, when splitting a shift in hours (i.e., when using `day` view scale), the shift is appropriately split at the time requested. For instance: 1. A shift from [Original Start] to [Split Time] 2. A shift from [Split Time] to [Original End] task-5387243
This update resolves an issue where the 'Validate' button in the shopfloor wizard becomes unresponsive after an error occurs when attempting to add a picture to a work order instruction. Previously, users had to restart the wizard to proceed, causing frustration. The fix re-enables the button after an error, streamlining the workflow and improving usability for manufacturing teams.
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
Forward-Port-Of: odoo/enterprise#105990