Daily updates from Odoo
Navigate
Branch
Saturday, January 10, 2026
20 changes
1 change
Resolved issues and error corrections
This update significantly speeds up invoice processing by optimizing how the system determines parent IDs for account lines. Previously, a slow process caused memory errors with large invoices. Now, the update reduces processing time to approximately 4 seconds for invoices with 2000 lines, resolving a critical performance bottleneck.
Original PR description
Before this commit, computing the `parent_id` of `account.move.line` records, involved looping over the `move_lines` grouped by their `move_id` sorted by the `sequence`. The updates on the move_lines…
Before this commit, computing the `parent_id` of `account.move.line` records, involved looping over the `move_lines` grouped by their `move_id` sorted by the `sequence`. The updates on the move_lines are done per line and this involves an individual write operation on each one of them. The cardinality of the set of possible values of the new `parent_id` may involve a lot of values in cases where a big number of lines have a display type of either 'line_section' or 'line_subsection', in most of the cases it is not the case, so a possible performance improvement in the method is to upper bound the number of write operations by the cardinality of the set of possible values instead of a single write operation on each single `move_line`. This can be done by mapping the values to a record set of move lines and updating the move_lines that share the same value. The benchmark below is done on an invoice that contained **2000** `move.line` records. An individual **write** operation is being done on each one of them. | Scenario | Time (seconds) | |-----------|----------------| | **Before** | **Memory Error** | | **After** | **4s** | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239026
1 change
Resolved issues and error corrections
This update fixes an issue where the Helpdesk return process incorrectly defaulted to internal 'PICK' operations instead of the final 'OUT' operation for multi-step deliveries. The fix ensures the correct customer-facing delivery order is selected, improving the accuracy of returns and streamlining the customer experience.
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
4 changes
Resolved issues and error corrections
This update fixes an issue where the Helpdesk return process incorrectly defaulted to internal 'PICK' operations instead of the final 'OUT' operations for multi-step deliveries. The fix ensures the correct customer-facing delivery order is selected, improving the accuracy of returns and streamlining the customer experience.
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 automatically calculates and transmits the required 2050 retirement savings contributions (ELM) for Swiss companies using Odoo. Previously, this calculation was manual, introducing potential errors and delays. This change ensures accurate and timely reporting to the Swiss tax authorities, improving compliance.
Original PR description
task-5166226 Forward-Port-Of: odoo/enterprise#103542 Forward-Port-Of: odoo/enterprise#103453
This update clarifies error messages related to custom field access rules within Odoo. Previously, confusing error messages could hinder users from understanding why they lacked permission to view or modify certain fields. This change simplifies the messages, making it easier for users to resolve access issues and continue working efficiently.
Original PR description
Method `_check_field_access` may raise for fields that have no groups, in case there are custom field access rules. Simply make the details of the error message less confusing. backport of https://github.com/odoo/odoo/pull/231159 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242856
This update fixes an issue where accepting UrbanPiper online orders in multiple POS locations resulted in multiple preparation tickets being printed. The fix ensures that preparation tickets are only generated once when an order is accepted, streamlining the order fulfillment process and reducing printing costs. It also removes local order records when an order is rejected.
Original PR description
When a POS session is open in multiple tabs/locations, accepting an UrbanPiper online order triggers multiple preparation ticket prints. Steps to reproduce: - Configure POS with UrbanPiper and a preparation printer. - Open the same POS session in multiple tabs/locations. - Receive an online food delivery order via UrbanPiper. - Accept the order in the POS terminal (TicketScreen). (Note: Order may also be auto-accepted by UrbanPiper.) Issue: - The same order printed multiple preparation tickets due to multiple active session instances. Fix: - Ensure preparation ticket prints only once when accepting (or auto-accepting) UrbanPiper orders. - Remove local order records when rejecting an online order. Task-5353283 Forward-Port-Of: odoo/enterprise#103867 Forward-Port-Of: odoo/enterprise#100280
3 changes
Resolved issues and error corrections
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 resolves an issue where accepting UrbanPiper online orders in multiple POS sessions resulted in duplicate preparation tickets being printed. The fix ensures that preparation tickets are generated only once, regardless of the number of active POS sessions. This improves order accuracy and reduces unnecessary printing.
Original PR description
When a POS session is open in multiple tabs/locations, accepting an UrbanPiper online order triggers multiple preparation ticket prints. Steps to reproduce: - Configure POS with UrbanPiper and a preparation printer. - Open the same POS session in multiple tabs/locations. - Receive an online food delivery order via UrbanPiper. - Accept the order in the POS terminal (TicketScreen). (Note: Order may also be auto-accepted by UrbanPiper.) Issue: - The same order printed multiple preparation tickets due to multiple active session instances. Fix: - Ensure preparation ticket prints only once when accepting (or auto-accepting) UrbanPiper orders. - Remove local order records when rejecting an online order. Task-5353283 Forward-Port-Of: odoo/enterprise#100280
This update automatically calculates and transmits the required 2050 retirement savings contributions (ELM) for Swiss companies using Odoo. Previously, this calculation was manual, leading to potential errors and delays. This fix ensures accurate and timely reporting of these contributions, complying with Swiss tax regulations.
Original PR description
task-5166226 Forward-Port-Of: odoo/enterprise#103542 Forward-Port-Of: odoo/enterprise#103453
8 changes
Resolved issues and error corrections
This update resolves an issue where changing a Commission Plan's dates would delete all associated targets and forecasts. Now, the system correctly checks if new targets fall within the plan's updated period and only removes outdated targets, ensuring accurate reporting and planning.
Original PR description
Before this commit, changing the Effective Period of a Commission Plan was erasing all the targets and forecast linked to that plan. After this commit, this is no longer the case as we compare if the new targets are within the range and delete the out-of-period targets. task-5469817
This update fixes an issue with hourly wage calculations and improves the accuracy of monthly wage calculations for employees in Russia. The changes ensure that payroll data is derived from accurate resource calendars, eliminating previous static assumptions and preventing unexpected validation errors.
Original PR description
- All percentage fields now use self.env.remove_to_compute to break circular dependencies, so UIs no longer need the ad-hoc skip_percentage_calc context. - _l10n_in_get_montly_wage now derives monthly hours from the version’s or its company’s resource calendar via hours/week previously it was static to 22 days. - fix raises validation when opening offer after changing working schedule it raise validation error which isn't expected behaviour. task-5421228
This update resolves an issue related to how absences are tracked within the HR module. The fix ensures accurate recording and reporting of employee time off, leading to more reliable workforce data and improved HR processes. This change primarily impacts the HR version management.
Original PR description
Task: 5470030
This update corrects a display issue on the website where subscription delivery periods were shown in English instead of the user's selected language. The fix leverages existing translation mappings to ensure consistent and accurate delivery period displays across all languages. This improves the user experience for subscription customers.
Original PR description
This commit[^1] introduced a "Deliver Every [period]" text on the website for subscription consumable products, but used the raw selection key that was not translated. As a result, people would see only the "Deliver Every" part in their language, and the period in English. To fix this in stable, we used the already existing translation mapping for billing periods to also translate the delivery period on the website. In master, we can improve this further by using a computed field with a properly translatable string. Issue reported by support. [^1]: https://github.com/odoo/enterprise/commit/beb7238882eda1fd36aa22bdb6441b8bd5556ef3
This update resolves several issues related to the generation of the social balance sheet in Belgium, specifically for employees with unique payroll scenarios. The changes ensure accurate reporting by preventing double-counting, handling different employee types correctly (including those without certificates), and addressing potential floating-point comparison errors. This improves the reliability of financial reporting.
This update resolves minor issues with the German Point of Sale certification process. Specifically, it now accurately transmits net order values to Fiskaly, ensures correct decimal formatting for financial data, and adjusts payment calculations for customer accounts. These changes improve the reliability and accuracy of financial reporting related to German POS transactions.
Original PR description
In this commit: ------------------ - Transferred **net value** instead of **gross value** for `price_per_unit`. - Included **cash statement business cases** that were prepared earlier but not sent to Fiskaly. - Ensured all **amount fields are sent as strings** to Fiskaly. - Fixed rounding precision using `toFixed()` to maintain **2–5 decimal places**, as required by Fiskaly (e.g., `4.70` should not become `4.7`). - Adjusted logic for **customer account payments** to send the **adjusted order amount** instead of the original total. task: 5122652
This update corrects a technical issue where users were experiencing problems accessing bank accounts related to new contract signatures. The change prevents this error, ensuring a smoother and more reliable process for managing employee contracts and payroll. This resolves a potential disruption to HR workflows.
This update resolves a bug where sample timesheet data was causing errors when switching between views. The fix ensures all sample records have their timers paused, preventing incorrect time display and data conflicts. This improves the stability and accuracy of the timesheet functionality.
Original PR description
Steps to reproduce: - Open Timesheets app, - Click on search(magnifying lens) to open on cell with no records. - Let sample record be loaded. Issue: - Timer is already started. If you switch back to grid view and stop the time it throws traceback as it has data of sample records. Reason: - The sample records can have record states that are running. Fix: - Make sure all the sample records created have their timer paused using field `is_timer_running`. - Update condition in time display to check if time is running instead using `is_timer_running` not using `time_start` and `time_pause` as `time_pause` is not an active field. task-5267303
3 changes
Resolved issues and error corrections
This update prevents a sale order saving error that occurred when a Recurring Plan was created without specifying a Start Date or Next Invoice date. The fix ensures the system handles missing date information gracefully, allowing users to save orders with or without these dates.
Original PR description
Currently, an error occurs when saving a sale order without a Start Date or Next Invoice date. Step to produce: - Install the ```sale_subscription_stock``` module. - Create a new sale order, Add a…
Currently, an error occurs when saving a sale order without a Start Date or Next Invoice date.
Step to produce:
- Install the ```sale_subscription_stock``` module.
- Create a new sale order, Add a Recurring Plan with a date, and add a product that has a Subscriptions true.
- Confirm a sale order, and remove a Start Date or Next Invoice date, and try to save an order.
See Traceback:
```
TypeError: '<=' not supported between instances of 'bool' and 'datetime.date'
File "odoo/http.py", line 2363, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1010, in onchange
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1123, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6981, in __getitem__
return self._fields[key].__get__(self)
File "odoo/fields.py", line 1291, in __get__
self.compute_value(recs)
File "odoo/fields.py", line 1473, in compute_value
records._compute_field_value(self)
File "addons/sale/models/sale_order.py", line 1998, in _compute_field_value
return super()._compute_field_value(field)
File "addons/mail/models/mail_thread.py", line 427, in _compute_field_value
return super()._compute_field_value(field)
File "odoo/models.py", line 5220, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 110, in determine
return needle(*args)
File "home/odoo/src/enterprise/18.0/sale_subscription_stock/models/sale_order.py", line 21, in _compute_recurring_stock_products
if order.state == 'sale' and order.is_subscription and order.next_invoice_date <= order.start_date:
```
An error occurs when the system attempts to compare a date-time value with bool(False) values at [1], because the Start Date or Next Invoice Date is empty.
Link [1]: https://github.com/odoo/enterprise/blob/ed9bae1b37b336e446b9196a6a95def2602a4ac5/sale_subscription_stock/models/sale_order.py#L21
To resolve this issue, add a condition to ensure the comparison is performed only if both the Start Date and the Next Invoice Date are available.
Sentry-6085265423This update fixes a display issue in the Project module where milestone deadlines weren't shown correctly. The fix ensures that milestone names now include the associated deadline, providing clearer and more informative project views. This improves usability and reduces potential confusion for users.
Original PR description
**Steps to Reproduce:** - Install the Sale Project module. - Navigate to the Project module. - Enable Project Stages. - Go to the Project list view. - Observe that the Next Milestone does not display the deadline along with the milestone name. **Issue:** The milestone display name is incomplete and does not include the deadline date. **Cause:** The context overridden in sale project did not pass the required context, cause the display_name computation did not add deadline to the display name. **Fix:** Passed the appropriate context in the action context to ensure the display name is correctly computed and displayed with its deadline. Task: 5255295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the 'Next Milestone' display in Project Configuration didn't show the milestone deadline alongside the name. The fix ensures that milestone names now accurately include the deadline, providing users with clearer project timelines. This improves the usability of the Industry FSM module.
Original PR description
**Steps to Reproduce:** - Install the Industry FSM module. - Navigate to Project Configuration. - Enable Milestones. - Go to the Project list view. - Observe that the Next Milestone does not display the deadline along with the milestone name. **Issue:** The milestone display name is incomplete and does not include the deadline date. **Cause:** The required context was not passed in the action, so the display_name computation did not add the deadline to the milestone name. **Fix:** Pass the appropriate context in the action to correctly compute and display the name along with its deadline. Task: 5255295