Daily updates from Odoo
Monday, January 12, 2026
17 changes · 19.0
Resolved issues and error corrections
This update fixes an issue where the timesheet timer wasn't correctly associated with the task being worked on. The fix ensures the timer uses the correct task or project from the list view, providing a more accurate and user-friendly timesheet experience. This improves the reliability of time tracking.
Original PR description
### Issue: When looking at the list of timesheet for a task, we can start the time but the timer have default values that don't correspond to the task. ### Cause: `startTimer` in the `timesheetTimerService` is called from the timesheet timer hook without vals. It then makes an orm call to `action_start_new_timesheet_timer` to retrieve the fields (project or task) but as nothing is given in the vals, the selected project is the one returned by `_get_favorite_project_id()`. ### Solution: Get the context of the list view to retrieve the task or the project and input it in `vals`. opw-5342525
This pull request includes updates to translations for various languages and addresses several bug fixes across different modules. Specifically, it fixes issues with address formatting in the contact module, improves printer linking in the inventory app, and resolves a problem preventing ticket creation from email aliases.
This update resolves a minor typo within the Odoo Enterprise system. The change ensures the naming of attachment files accurately reflects their associated external IDs and intended functionality. This improves data consistency and reduces potential confusion.
Original PR description
Fix typo – Correct the ir_attachment file name to match the external ID and its functionality. OPW-5428700
This update fixes an issue where Odoo was incorrectly selecting DIAN number ranges, leading to upload errors. The system now consistently uses the highest available number range returned by the DIAN service, ensuring successful document uploads. This improves the reliability of our integration with DIAN.
Original PR description
**PROBLEM** The GetNumberRange service of DIAN used to retrieve the attributed number ranges can return multiples ranges for the same prefix. In odoo, for each prefix, we only store the last range we encountering in the xml the service respond with. This means there is a chance we select a number range that is already full. This cause an error when trying to upload a new document to DIAN. **STEP TO REPRODUCE** Not reproducible on runbot since this need a production DIAN setup (GetNumberRange service is only available in prod). 1. In DIAN portal, have two valid numbering ranges for the same shortcode. 2. In Odoo, go to Accounting > Configuration > Journals, select the journal, and click "Reload DIAN Configuration" 3. Only one of the NumberRangeResponse is pulled into Odoo, and it may not be the correct one **FIX** For each prefix, we keep the highest range we find in the DIAN response. opw-5086590
This update resolves an error that occurred when creating attendance records using the 'Planning' work entry source. The fix corrects issues with how the system calculates working time and handles partial day allocations, ensuring attendance creation now functions correctly.
Original PR description
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to…
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to Reproduce([Video](https://drive.google.com/file/d/1vGIZswZ-0D_ISAKn8LltYlGgQ7gzI6oA/view)):** - Install the `hr_work_entry_planning_attendance` module. - Go to `Employees` and create a `new employee` or open an `existing one`. - In the `Payroll` section, set `Work Entry Source` to `Planning`. - Go to `Planning` and create a planning slot for this employee `(if it does not exist)` with `Allocated Time` set to less than 100%. - Go to `Attendance` and create `an attendance for this employee` within the planning slot start and end dates. **Error 1:** `AttributeError: 'method_descriptor' object has no attribute 'min'` **Error 2:** `TypeError: Intervals.__init__() takes from 1 to 2 positional arguments but 4 were given` **Cause:** When the Work Entry Source is set to Planning and an attendance is created for that employee, the system updates overtime (if any) and retrieves the scheduled working time from the planning slot. If the planning slot has less than 100% allocated time, it is split day by day, keeping only a portion of each day’s working hours based on the allocation percentage. While creating a datetime at the very start or end of a day, an error occurs due to incorrect access of the min or max attribute from datetime. Another issue occurs when creating intervals using the start and end dates: an error is raised because separate start and stop arguments are passed instead of a list of interval tuples. **Fix:** This commit ensures that the correct datetime.min.time() / datetime.max.time() values are used and that intervals are provided in a list-of-tuples format. [1]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L56-L57 [2]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L60 **No Task ID**
This update fixes an issue where the Helpdesk return wizard incorrectly defaulted to internal 'PICK' operations instead of the final 'OUT' operation for multi-step deliveries. The fix ensures the wizard now correctly selects the customer-facing 'OUT' operation, streamlining the return process and improving data accuracy.
Original PR description
Steps to reproduce: - 1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship). 2. Create a Sales Order for a product and fully process the delivery, including all steps. 3. Create a Helpdesk ticket for that customer. 4. From the ticket, click the "Return" button to open the wizard and select the sales order. Issue: - The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation. Cause: - Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary. Fix: - The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order. task-4948134 Forward-Port-Of: odoo/enterprise#93154
This update corrects a technical issue where the test button on the IoT device interface incorrectly reported successful status even when errors were occurring. The fix standardizes the data format used for IoT device communication, ensuring accurate status reporting and improved reliability of the device testing process. This prevents misleading feedback for users.
Original PR description
This commit fixes several situations where a positive status would be given by the test button despite the presence of an error: - If the websocket connection was used but there was a timeout - If the websocket connection was used but there was any other error - If any 6-digit error code was returned when using the stable IoT box To fix these issues, we stop using the `data['message']` field, since it gets ignored by the websocket confirmation controller. We now use the same result format as the other requests (and the stable IoT box). We also add a check for the `"timeout"` that we receive when a websocket request times out. Forward-Port-Of: odoo/enterprise#103817
This update ensures the employment bonus calculations in the l10n_be_hr_payroll module accurately reflect bonus amounts up to March 2026. This fix addresses a recent adjustment to Belgian tax regulations regarding employment bonuses, maintaining compliance and accurate payroll reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#103820
This update corrects a bug in the l10n_lu reports that prevented the `TaxBase` element from being included in FAIA XML reports when invoices had multiple taxes. This ensures compliance with Luxembourg tax regulations and accurate reporting to tax authorities, resolving a potential data discrepancy.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103543 Forward-Port-Of: odoo/enterprise#101178
This update fixes a minor issue in the SendCloud integration where the product ID was incorrectly accessed. The change ensures the system reliably retrieves product information using the correct 'id' key, preventing potential data retrieval errors. This improves the accuracy of SendCloud order processing.
Original PR description
Same fix as d4fae97, the id was retrieved by doing `[0]` but the proxy object has changed so we need to use the `id` key to get the value instead. ----- Ticket: opw-5433254
This pull request addresses several critical issues impacting payroll processing for Australian businesses using the Odoo Enterprise system. Specifically, it resolves errors related to Medicare calculations, STP reporting accuracy, and rounding discrepancies, ensuring more reliable and compliant payroll operations. The fixes improve data integrity and reduce the risk of financial inaccuracies.
Original PR description
Tracebacks on zeroing Medicare computation to require the variation form Rounding error on STP reporting of Additional withholding task-5416549
This update restores automatic follower copying from parent sale orders for subscription renewals and upsells, aligning with expected business processes. Previously, this feature was removed for all users, but this change specifically addresses the needs of subscription-based sales. It maintains the existing restrictions for other record types.
Original PR description
[FIX] sale-subscription: Restore automatic follower copying from parent SO In Odoo 18.2 (Task 4655022), automatic follower addition was removed for all users and limited to internal users. However, for subscriptions, it is logical to automatically copy followers from the parent sale order to renewal and upsell orders. This commit restores that behavior for subscription renewals and upsells while keeping the restriction for other record types. task - 5002181
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to the 3000 deduction. The change ensures the deduction accurately reflects tax regulations up to the year 2026, improving payroll accuracy for Belgian businesses. This fix addresses a previously identified discrepancy.
Original PR description
Forward-Port-Of: odoo/enterprise#103824
This update clarifies the terminology used in the Odoo Enterprise payroll module. The 'Other Input Types' and 'Payslip Other Input Types' menu items have been renamed to 'Salary Input Types' to improve user understanding and ease of navigation. This change enhances the overall user experience within the payroll system.
Original PR description
Updated the Input type for better clarity and easier understanding for users: - '**Other Input Types**' : 'Salary Input Types' - '**Payslip Other Input Types**' : 'Salary Input Types' **task-5474028**
This update fixes issues with document folder synchronization and the order of actions when creating accounting records. Specifically, it ensures documents are moved to the correct accounting folders and that multi-step actions execute in the correct sequence, preventing data inconsistencies.
Original PR description
This PR addresses two related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Execution Order of Multi-Actions.…
This PR addresses two related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Execution Order of Multi-Actions. Previously, multi-step server actions (e.g., 'Create Vendor Bill') executed child actions alphabetically. This caused the manual "Move to Taxes" action to execute after the record creation sync, effectively overriding the correct journal folder placement and moving the document to a generic folder (e.g. 'Taxes'). Changes: - Enforced a specific execution order: The document is now moved before the accounting record is created. This ensures the final automatic sync prevails. - Additionally, the action is temporarily embedded (pinned) on the intermediate folder during execution to allow the subsequent record creation to proceed even after the document has been moved to a new folder (which would otherwise fail consistency checks). **Fix 2:** Sync on Miscellaneous Entry Creation Previously, creating a Miscellaneous Entry (move_type='entry') from an existing document failed to move the document from its original location (e.g., "Finance") to the correct accounting folder. The existing sync logic explicitly skipped entries to avoid issues with multi-attachement invoices. Changes: - Extended `ir.attachment.write` to detect when a document is linked to an account.move of type 'entry'. - Triggers `_update_or_create_document` immediately upon linking to ensure tags and folders are synchronized. Task-5452729
This update resolves a bug where the 'copy link' button in the salary calculator generated a 404 error. The fix ensures the offer is saved before generating the link, preventing errors related to missing offer IDs. This improves the usability of the salary calculator for generating offer links.
Original PR description
Steps to reproduce: 1- Open salary calculator 2- Do not edit any fields 3- Click on copy link button 4- Open the link Issue: When you open the link you'll see a 404 page. Cause: The salary calculator essentially creates an offer. When no fields are modified in the form, the offer isn't created yet. When a link is created for that offer, the offer id part of the link is NewId_xxx. Fix: Modify the widget that copies the link to clipboard to first save the offer before generating the link. Task-5441297
This update fixes an issue where payment advice reports (PDF and XLSX) were incorrectly displaying only the first bank account when an employee had multiple salary distributions. The fix ensures that all bank accounts with salary splits are accurately reflected in the payment advice, providing correct payment information for employees.
Original PR description
Issue: When an employee had multiple bank accounts with salary distribution, the payment advice (PDF and XLSX) was displaying only the first bank account and assigning the full salary amount to that account. This resulted in incorrect payment information being generated. Fix: When multiple bank accounts are configured with salary distribution, the payment advice now displays the correct information in both PDF and XLSX reports. task-5390429