Wednesday, December 10, 2025
4 changes · 17.0
Resolved issues and error corrections
This update resolves a technical issue that caused the Gantt chart to crash when an event's start or end date was cleared. The fix ensures the Gantt calculation only runs when a valid date range exists, preventing errors and improving stability.
Original PR description
When removing the start or end date on an Event, the system raises a traceback during Gantt information computation. **Steps to Reproduce:** 1. Install `website_event_track_gantt` module. 2. Create a new Event. 3. Add at least one **Track** with a track **Date** and **Duration**. 4. In the Event form, clear the Start or End Date field. **Error:** `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error. **Fix:** This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values. no id
This update fixes an issue where the barcode app wouldn't correctly assign a package as the 'result package' when it already contained items. The fix ensures that packages, regardless of their contents, can be properly used as destination packages during internal transfers, improving the reliability of the barcode scanning process.
Original PR description
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable…
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable "Packages" and "Storage Locations" settings; 2. Create two packages with some content in WH/Stock/Shelf 1; 3. Create an empty package; 4. Create an internal transfer directly from the Barcode app; 5. Scan Shelf 1 barcode and scan first package; 6. Scan the empty package => It's assigned as the result package; 7. Confirm the operation; 8. Create another internal transfer; 9. Scan Shelf 1 barcode and scan second package; 10. Scan the no more empty package => This time, it's not assigned as the result package. Reason ====== A package was assigned as the result package only if one of the following conditions is matched: 1. The scanned package is empty (it's what's happening in 6.); 2. The selected line has no result package yet and the scanned package is in the selected line's destination location. Here, it doesn't work because since we move a package, the barcode line has already a destination package (the same then the source package.) Fix === For the condition 2., adapt the condition to make it works too if the selected line has the same package as the source and result package. [opw-5326234](https://www.odoo.com/odoo/project/49/tasks/5326234)
This update fixes a potential issue where changes to parser rules couldn't be saved after the parser was initially set up. This change ensures that parser rules are consistently applied, improving data integrity and preventing unexpected behavior. It's a routine maintenance update.
Original PR description
The parser rules cannot be modified once the parser has been instantiated. task-5091744 Forward-Port-Of: odoo/odoo#239046
This update resolves an issue where Odoo's logging system incorrectly handled log messages containing complex data, specifically mappings. The fix reorganizes the logging process to correctly format these messages, ensuring more reliable and consistent logging output. This improves overall system stability and reduces the risk of logging-related errors.
Original PR description
When `lower_logging` encounters a `LogRecord.args: Mapping`, it fucks up and strips out all the values keeping only the mapping keys (as a tuple), which then breaks when trying to format it in `LogRecord.msg`. Fix the issue by moving the entire message munging into, appropriately, the formatter: `getMessage` will do the `str.__mod__` call at which point we don't need to deal with the args at all, then `formatMessage` generates the full message line (not including the stack traces from `exc_info` and `stack_info`, those are added in the second half of `Formatter.format`). https://runbot.odoo.com/odoo/error/234669 Forward-Port-Of: odoo/odoo#239410