Daily updates from Odoo
Sunday, August 9, 2026
4 changes · master
Resolved issues and error corrections
Uruguayan electronic delivery guide PDFs now correctly include a separate addenda page when the notes are too long for the standard space. This prevents important delivery information from being omitted on legal documents generated from stock operations.
Original PR description
**Description** When printing the legal PDF of a CFE, the report can request a dedicated addenda page (`adenda=true` report parameter) when the addenda does not fit in the small box of the standard…
**Description** When printing the legal PDF of a CFE, the report can request a dedicated addenda page (`adenda=true` report parameter) when the addenda does not fit in the small box of the standard report (roughly 6 lines of 140 characters). `l10n_uy_edi_document._get_report_params()` computed the addenda by calling `self.move_id._l10n_uy_edi_get_addenda()` directly. For e-remito EDI documents created from stock pickings, `move_id` is not set, so the addenda was always empty and the dedicated addenda page was never requested for delivery guides. **Changes** - Resolve the addenda from the document origin record: reuse the existing `_get_origin_record()` abstraction. Add it on `l10n_uy_edi.document` (returns the move) and let `l10n_uy_edi_stock` extend it to fall back to `picking_id`; `_get_report_params()` now reads the addenda through it. - Remove a no-op `_get_pdf()` override in `l10n_uy_edi_stock`. - Add a unit test covering the dedicated addenda page threshold (6 lines x 140 chars) for delivery guides. **Note** This PR replaces branch `adhoc-dev:18.0-t-stock-edi-addenda-fix-kz` (original authorship preserved); resubmitted from a new branch to keep follow-up and tracking with the current maintainer. Forward-Port-Of: odoo/enterprise#124539
VAT correction submissions for Dutch reports will now be sent using the correct OBSUP message type instead of being treated like regular VAT reports. This prevents routing errors in Digipoort and helps Dutch VAT corrections reach the right destination.
Original PR description
Description of the issue this commit addresses: VAT corrections are sent to Digipoort as regular VAT reports, causing routing errors. --- Desired behavior after this commit is merged: This commit sends VAT corrections using the OBSUP message type. --- opw-6353166 Forward-Port-Of: odoo/enterprise#127235
Users can now re-invite portal users or groups to shared Documents folders after a previous invitation has expired. This prevents cases where the system reported a successful invite but the recipient still had no access.
Original PR description
Sharing a folder with a portal user with an expiration date cannot be done again after the access has expired. The sharing dialog reports success, but the user does not get access and is no longer…
Sharing a folder with a portal user with an expiration date cannot be done again after the access has expired. The sharing dialog reports success, but the user does not get access and is no longer listed. ### Steps to reproduce - In Documents, share a folder with a portal user and set an expiration date. - Wait until the expiration date has passed. - Share the same folder with the same user again from the invite box. => The dialog says the member was added, but the user has no access and does not appear under "People with access". ### Cause The invite box has no expiration field. When re-inviting a user, it updates the existing `documents.access` record and passes `None` for the expiration, which keeps the old `expiration_date`. If that date is already in the past, the user remains expired even though the invite reports success. ### Fix Pass `False` instead of `None` when inviting a member so the existing record's expiration date is cleared. Re-inviting an expired user now restores access. Setting an expiration from the "People with access" list is unchanged. opw-6387559 Forward-Port-Of: odoo/enterprise#127050 Forward-Port-Of: odoo/enterprise#125140
Timesheet assistant suggestions now use the actual planned or calendar event duration instead of calculating time from start and end times. This ensures suggested timesheet entries better match allocated working hours, especially for planning shifts with breaks or non-working gaps.
Original PR description
*_: project_timesheet_forecast, timesheet_grid, timesheet_grid_calendar Previously, the timesheet assistant derived suggested entry durations from an event's start and stop datetimes. This worked for calendar events but produced incorrect suggestions for planning shifts whenever the allocated working hours differed from the overall scheduled time window. This commit introduces an explicit ``duration`` field in assistant events and updates all providers to supply it. Planning slots now use their allocated hours as the event duration, while calendar events expose their existing duration value. The assistant now consistently relies on this field instead of computing the duration from the event time range. As a result, suggested timesheet durations accurately reflect the intended working time for both planning shifts and calendar events. task-6366593 Forward-Port-Of: odoo/enterprise#127111 Forward-Port-Of: odoo/enterprise#125108