Daily updates from Odoo
Monday, October 6, 2025
8 changes · saas-18.2
Resolved issues and error corrections
Exporting a Belgian 325 PDF no longer crashes when there are no related 281.50 forms to include. Instead, users see a clear message explaining that they need to record a transaction with a 281.50 tag before generating the PDF.
Original PR description
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment…
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present. --- ### Steps to Reproduce 1. Go to **Accounting → Reporting → 325 Form**. 2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**. 3. Do not generate any 281.50 forms (`form_281_50_ids` is empty). 4. Click **Export PDF**. **Result before fix:** - Crash with `IndexError: list index out of range`. --- ### Solution - Added a safeguard check before accessing attachments. - If no attachments exist, raise a **UserError** instead of crashing. **New behavior:** > *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”* This gives users a instruction on how to resolve the issue. --- ### Result After Fix - **User error message** replaces traceback. - **Normal behavior preserved** when attachments exist: - One file → direct download. - Multiple files → zipped download. --- task-5090120 Forward-Port-Of: odoo/enterprise#94877
This fix prevents Odoo Studio from crashing when users remove calendar settings such as the color field. Empty values are now handled correctly instead of being mistaken for invalid field names, making view customization more reliable.
Original PR description
On a calendar with studio, try to remove the "color" attribute, or any other that should contain the name of a field. Before this commit there was a crash because the value sent to the server in this case is `undefined` (`null` in JSON or `None` in python), which was stringified and yielding an actual string that was not a field name After this commit, NULL values are not stringified, instead they should represent the emptiness of the attribute. opw-4938351 Forward-Port-Of: odoo/enterprise#95439
This update changes how encoded document data is passed when sending reports to IoT devices, avoiding a compatibility issue with customizations. It helps prevent errors in existing customer modules while preserving the same document sending behavior.
Original PR description
Following commit https://github.com/odoo/enterprise/commit/ecea27f45ab58ae6f348753d94fdf89f902a43b9, the argument `data_base64` was added to the `render_and_send` function. However, adding new arguments in stable versions is not allowed, as it may break custom modules that override this function and do not expect the additional argument. This commit ensures that `data_base64` is passed through the context instead, preventing errors while keeping compatibility with existing overrides. opw-data_base64 Forward-Port-Of: odoo/enterprise#96244
When publishing and sending planning schedules, the system now respects filters already chosen in the planning view, such as role or team filters, while still applying the selected date range. This prevents unintended schedule entries from being published or sent and helps managers target the right employees or shifts.
Original PR description
To reproduce: ============= -Reset all planning.slot to draft -Search "Dev" role -In weekly Gantt view, click on publish & send -Change date to match the current month (or any other period) -Publish Problem: ========= We filter only by datetime and ignore domain from context : https://github.com/odoo/enterprise/blob/20b45f6c65c78a572a3f26b78f6ed458accf7c9f/planning/wizard/planning_send.py#L31-L33 Solution: ========= - Get active domain from context and override only it's date_time since it changed. opw-5017014 Forward-Port-Of: odoo/enterprise#93295
Failed attempts to send shipping labels to an unreachable IoT printer no longer show an error traceback to users. This avoids alarming employees who received a shared print request even when another user may have successfully printed the label.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. As multiple users can receive the broadcasted message at the same time, but might not be able to reach the printer, we need to avoid displaying a traceback on failure. Note that as it is broadcasted, a user could receive the traceback even if label was already printed by the user that was on the same network as the IoT Box. Also note that we don't even display a notification as it would be displayed to every user connected that couldn't reach the IoT Box. Task: 4792491 Forward-Port-Of: odoo/enterprise#96054 Forward-Port-Of: odoo/enterprise#95794
Field Service project settings now show the correct label for the timesheet product when a customer is selected. This avoids confusion caused by the sales order line label appearing in the wrong place.
Original PR description
Steps to reproduce: - Install the `industry_fsm_sale` module. - Open the FSM app. - Go to Projects. - Open a project’s settings. - Select a customer. Issue: The label for the timesheet product is not displayed. Instead, the label for the sale order line appears on FSM projects. Cause: In the PR, https://github.com/odoo/odoo/pull/128967 changed the project settings form structure by wrapping `sale_line_id` in a `div` and separating its label, breaking the xpath for `timesheet_product_id`. Fix: - Update the XPath for `timesheet_product_id` to target the correct container. - Hide the `sale_line_id` label on FSM projects. task-4581748 Forward-Port-Of: odoo/enterprise#96022
Employees with flexible working hours no longer see Saturdays and Sundays incorrectly marked as unavailable in the timesheet grid. This prevents confusion for teams whose schedules allow work on any day.
Original PR description
To reproduce: ============= 1- Update employee worktime to be flexible 2- Go to timesheets -> saturday & sunday are marked grey Problem: ======== Can't apply https://github.com/odoo/odoo/blob/ce2d134d3e8e5c0d96529c1d0490f1e0c5e28294/addons/resource/models/resource_calendar.py#L511 This logic cannot be applied when an employee's work time is flexible, since they can work whenever they want. Fix: ==== When employee work time is flexible we just return empty list for the unavailable dates. opw-5031144 Forward-Port-Of: odoo/enterprise#94346
The Belgian EC Sales List XML export now correctly includes the month or quarter when opened from a VAT Return without manually changing the period. This prevents incomplete XML files and helps businesses submit Belgian tax reporting data as expected.
Original PR description
**Issue** When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a…
**Issue** When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected. **Steps to Reproduce** 1. Install the Accounting module and Belgium localization. 2. Go to the Accounting dashboard. 3. Open the VAT Return via the "Miscellaneous Operations" section. 4. Click the smart button to access the EC Sales List report. 5. Use the gear icon to export the XML. 6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing. **Root Cause** If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered. **Fix** Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period. Opw-4702613 Forward-Port-Of: odoo/enterprise#89290