Daily updates from Odoo
Thursday, January 15, 2026
31 changes · master
Resolved issues and error corrections
This update fixes an issue where preparation timers for courses within a split order were incorrectly shared. Now, each preparation order has its own timer, ensuring accurate timing for each course and improving the restaurant's order fulfillment process. This change enhances the overall customer experience.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update ensures that archived employees are no longer included in payroll runs and pay slip forms. This prevents incorrect payments and simplifies payroll processing by focusing only on active employees. The changes remove outdated filters and improve data accuracy.
This update resolves a technical issue that caused a traceback error when removing a selected pay category for employees in the payroll section. The fix ensures the system handles the removal of pay category selections correctly, preventing errors and improving payroll stability. This change impacts the HR Payroll module.
Original PR description
Fixed a traceback bug that appears when removing unselecting the Pay Category in the Employee's form payroll tab Steps to reproduce: - Select a pay category for an employee - Delete your selection - Traceback appears Cause: _compute_display_be checks on the name of the structure_type_id without checking that this field is not null, producing a bug when its value is removed task-5453432
This update fixes a minor issue in the Thai tax reporting module where trailing spaces were causing incorrect calculations in tax reports. The change removes this space, restoring the reports to accurately reflect tax liabilities. This ensures data integrity for Thai businesses using Odoo Enterprise.
Original PR description
-Report line formula was converted from Char to Text, which no longer strips trailing spaces. -The fix removes the trailing space from "formula" to restore correct behavior. Related Community PR: https://github.com/odoo/odoo/pull/242462 task-5468804
This update corrects a database error that prevented the Tax Report from properly expanding invoice lines. The fix ensures accurate report generation by using the correct database table for tax descriptions. New test cases have been added to verify the report's functionality.
Original PR description
Before: The `query_tax_lines` method was incorrectly using the account tag alias to access the `description` field, which does not exist on that table. This caused a database error when expanding invoice lines from the Tax Report. After: Now the query correctly uses the `account_tax` table alias to fetch the tax description. - Also added test cases for sales and purchase reports to ensure correct generation of report lines and proper expansion of the hierarchical structure. task-5461512 Forward-Port-Of: odoo/enterprise#104111 Forward-Port-Of: odoo/enterprise#103668
This update fixes a technical issue preventing AI server tools from running correctly. The problem stemmed from an unnecessary inclusion of '__end_message' in tool arguments, causing validation errors. The fix ensures correct tool execution by removing this element before validation.
Original PR description
When executing AI server actions, tools with `ai_tool_schema` defined would fail with "Missing definition for __end_message" error. Root cause: - `_prepare_tools` adds `__end_message` to the schema sent to the LLM - The LLM returns tool calls with `__end_message` in arguments - `_ai_tool_run` validates arguments against the original schema (which doesn't have `__end_message`) - Validation fails with "Missing definition for __end_message" Fix: Use `pop` instead of `get` to extract and remove `__end_message` from arguments before calling the tool executor. This ensures that it's not passed to the tool validation. TASK-ID: 5423756 Forward-Port-Of: odoo/enterprise#103779
This update fixes an issue where the 'Out of Contract' calculation was incorrectly extending beyond the payslip period. The change ensures that contract overlap dates are accurately limited to the payslip's start and end dates, preventing inaccurate payroll reporting. This improves the reliability of employee compensation data.
Original PR description
Steps to Reproduce: 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). Reason: - If a contract ends before the payslip period, it adds all days from the end of the contract until the end of the payslip period as "Out of Contract", ignoring the payslip start date. - If a contract starts after the payslip period, it adds all days from the payslip start date until the contract start date, ignoring the payslip end date. Solution: Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5350519 Forward-Port-Of: odoo/enterprise#103539 Forward-Port-Of: odoo/enterprise#100694
This update enhances the logging of errors related to Stripe expense transactions. Specifically, it now captures full traceback information when errors occur during webhook events, providing more detailed insights for troubleshooting. Additionally, a fix was implemented to prevent unnecessary actions when a Stripe card is marked for destruction, ensuring data integrity.
Original PR description
## [IMP] hr_expense_stripe: full traceback logging When a pyhon error is raised during a webhook event we only get the error main line, not the full traceback. This adds the full traceback message to the log ## [FIX] hr_expense_stripe: Fix returned card error When a card is returned to the factory for destruction, when Stripe sends us the information, we sent a payload to stripe. This makes no sense as the card has been updated by Stripe into a state that doesn't allow further changes Forward-Port-Of: odoo/enterprise#103940
This update fixes a dashboard display issue that previously showed incomplete employee information during payroll exports. The changes now correctly list employees without version ID export codes and incorporate Prisma code for a better user experience. This ensures accurate and complete payroll export data.
Original PR description
\* = {acerta, group_s, prisma}
Dashboard warnings opened a contract template containing the version data of the employee, while not showing employee's name or id, this commit changes the redirected view to a list of employees that do not have the version id's export code.
This commit also adds Prisma code to the external codes group for better UX
task: 5212681
Forward-Port-Of: odoo/enterprise#98389This update fixes a random failure in a key tour that simulates unpacking packages onto pallets within the stock management system. The issue stemmed from a timing conflict during the tour's steps, leading to incomplete actions. The fix adds a verification step to ensure the first pallet line is fully unpacked before proceeding, improving the tour's reliability.
Original PR description
Before this commit, the tour `test_internal_picking_reserved_move_packages_into_new_palet` was randomly failing. In this tour, we have two palets we unpack. The issue is, after unpacked the first one, we complete the second one line and then we unpack it. But it can happen the click on the button to complete the second line was done too quickly (in the meantime the first palet line is unpacked) and thus, because of this race condition, the second palet line was not complete (either it's just a visual bug due to a refresh in the wrong time, either the complete action is dropped due to the first line unpacking action.) To fix that, this commit adds a step to verify the first line is correctly unpacked before going further. runbot-build-error: [237801](https://runbot.odoo.com/odoo/runbot.build.error/237801) Forward-Port-Of: odoo/enterprise#104261
This update resolves a technical error that occurred when a sale order lacked an invoice date. The fix ensures that stock move filters now correctly use either the order's last invoice date or today's date, preventing a traceback and ensuring accurate stock management for subscription orders. This improves the reliability of the subscription order fulfillment process.
Original PR description
The Issue: Prior to this commit, When the sale order last_invoice_date is False, a traceback is thrown The Fix: To resolve this, We get the last_invoice_date or todays date opw-4403557 Forward-Port-Of: odoo/enterprise#75717
This update resolves an issue where wage calculations were producing incorrect results and causing validation errors when changing working schedules. The changes improve the accuracy of hourly wage calculations by dynamically determining working hours from company calendars and removing unnecessary dependencies, leading to a more stable and reliable payroll system.
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 Forward-Port-Of: odoo/enterprise#103889 Forward-Port-Of: odoo/enterprise#102488
This update fixes a bug where document favoriting wasn't working correctly, particularly when multiple documents were involved. The change ensures consistent behavior for toggling favorites, even with different user permissions, and adapts the process for batch operations. This improves the overall user experience for managing document favorites.
Original PR description
The inverse method for the computed field was actually implementing a toggle instead of writing the passed value. We modify it and update the existing test to not only check the compute method but…
The inverse method for the computed field was actually implementing a toggle instead of writing the passed value. We modify it and update the existing test to not only check the compute method but also the inverse method.
Note that this behavior is currently used in
documents/static/src/views/kanban/documents_kanban_renderer.js (useCommand, Toggle favorite that writes on the selection the opposite of is_favorited of the first record on the whole selection).
[IMP] documents{_spreadsheet}: adapt toggle favorite for batch of records
We update the document toggle_favorited method to work in batch with the following logic: if all documents share the same state (either all favorited or all not favorited), the method toggles their state; otherwise, it marks all items as favorites. Then using that updated method, we improve the toggle favorite method of the document service to support multiple documents and manage the reload.
We also apply the correction of the shortcut command for favorite introduced in odoo/enterprise#89928 but not propagated to master. That correction ensures we use the toggle_favorited method rather than writing on the is_favorited field, so that it also works in all situation (even if the user doesn't have write permission on the document).
Partially based on the forward port of odoo/enterprise#89928 (by adsh-odoo).
Task-5095066This update fixes an issue where the quantity of products scanned via GS1 barcodes wasn't correctly reflected in manufacturing orders. Previously, the system only added one unit regardless of the barcode's specified quantity. Now, the system accurately uses the barcode's quantity to update the finished product's output, ensuring consistency and accurate tracking of manufactured goods.
Original PR description
Description of the issue/feature this PR addresses: The quantity of GS1 barcodes was not taken into account when scanning the final product of a manufacturing order. More details of this issue can be found in https://www.odoo.com/odoo/project.task/4817418 Current behavior before PR: When scanning a GS1 barcode with a quantity defined (e.g. 0120250524135700310210000010LOT887766 ) as the final product of a manufacturing order, the quantity is not taken into account in the call to produceQty(), so the line will have a qty_done of 0 regardless of the quantity specified in the barcode Desired behavior after PR is merged: The qty_done of the final product line should be the one specified in the barcode, in order to make the behaviour consistent with other usages of GS1 barcodes. Forward-Port-Of: odoo/enterprise#104240 Forward-Port-Of: odoo/enterprise#95174
This update fixes an issue preventing non-administrator users from updating GI CFDI sequences. Previously, the system required elevated privileges, limiting functionality. Now, sequence updates are available to all users, streamlining the process for generating CFDI documents.
Original PR description
In odoo/enterprise#102500, support was added for custom GI CFDI sequences at branch level. However, the sequence consumption fails for non-admin users due to missing write access on ir.sequence, so sudo() is required when updating number_next. Forward-Port-Of: odoo/enterprise#104242
This update corrects a calculation error in part-time contracts. Previously, the system incorrectly attempted to adjust percentages when a 4/5 or part-time offer was created, leading to inaccurate salary calculations. This fix ensures that offer percentages are automatically determined based on the specified part-time rate.
Original PR description
When you make an offer to a 4/5 time for example, you set the 4/5 gross or employer cost and not the full, so no need to modify the percentage on the offer Forward-Port-Of: odoo/enterprise#104294 Forward-Port-Of: odoo/enterprise#103936
This update resolves an issue related to the DmfA declaration in the Belgian payroll module. The change adapts the payroll calculations to align with recent refactoring efforts within the Odoo Enterprise platform. This ensures accurate and compliant payroll processing for Belgian employees.
Original PR description
Forward-Port-Of: odoo/enterprise#104175
This update hides the 'suggest next documents' tab within the signing feature from users who are not logged into Odoo. This change ensures that sensitive document suggestions are only visible to authorized personnel, enhancing security and data protection. It aligns with our security protocols for confidential document workflows.
Original PR description
This commit makes the suggestion tab of signing next documents hidden to public users, as they should be logged in to be able to see the next documents to be signed. task-5487349 Forward-Port-Of: odoo/enterprise#104287
This update resolves an issue where the Ticket Screen in the POS Urban Piper module wasn't correctly loading order data. A recent Odoo update changed how order loading works, so this fix ensures the necessary order information is available before users can edit tickets, improving the user experience.
Original PR description
Since odoo/odoo#211804 change the order loading in background when opening the Tciket Screen. We need to ensure the component data is ready before modifying it in runtime. See odoo/odoo#211804
This update corrects a technical error that impacted the processing of annual leave data. The group assigned to a key feature related to annual leaves was mistakenly changed, leading to a runbot error. This fix ensures accurate tracking and reporting of employee leave balances.
Original PR description
Following a runbot error, the group on l10n_ae_annual_leaves_taken was changed from hr to the payroll group task-5498578
This update resolves an issue causing errors when sending DIAN documents for credit notes created with specific journals. The problem stemmed from a misconfigured namespace, preventing proper document generation. This fix ensures credit notes with DIAN support documents can be successfully sent, improving data accuracy and compliance.
Original PR description
**PROBLEM** When trying to create a credit notes using a journal with support documents, there is a lot of errors when sending the dian documents. **STEP TO REPRODUCE** 1. setup DIAN (knowledge page https://www.odoo.com/odoo/knowledge/5/knowledge/23114). 2. create a vendor bill, and then create a credit note with the DIAN support document journal. 3. Confirm and click on send DIAN documents. **CAUSE** `_get_document_nsmap()` uses the wrong namespace for credit notes. opw-5378540 Forward-Port-Of: odoo/enterprise#103821
This update fixes an issue where subscription tax calculations were incorrect after a partner's address was changed. The update ensures that fiscal positions and taxes are automatically recomputed when subscriptions are updated or reactivated, preventing inaccurate invoices and amounts. This ensures accurate financial reporting for our customers.
Original PR description
When updating a partner address that may impact the fiscal position, we need to ensure the fiscal position (and taxes) are also updated on running subscription or when reopening a churned subscription. Otherwise the subscription and generate invoices won't have the correct taxes and amount. opw-5365258 Forward-Port-Of: odoo/enterprise#103802
This update fixes an issue where the end of the pay period wasn't being calculated correctly for Mexican companies using specific payroll schedules (10 Days, 14 Days, Bi-weekly, Bi-monthly). The fix involves updating a key method to align with the standard calculation used in the core HR payroll module, ensuring accurate pay run period determination.
Original PR description
Bug: When we create a new pay run for a mexican company and we select the schedule "10 Days", "14 Days", "Bi-weekly" or "Bi-monthly", the end of the period is computed incorrectly. Cause: The standard method changed but it wasn't updated in the mexican payroll module. Fix: Change the signature of the method to match the one in hr_payroll. Task: 5421825 Forward-Port-Of: odoo/enterprise#104039 Forward-Port-Of: odoo/enterprise#102326
This update resolves an issue where the payroll rule parameter module would generate a technical error when configured with a future date. The fix ensures that computed fields are properly initialized, preventing the traceback and guaranteeing accurate calculations for payroll rules. This improves the stability and reliability of the payroll processing.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#104346
Forward-Port-Of: odoo/enterprise#102924This update fixes an issue where customer statements incorrectly showed zero amounts due in certain reconciliation scenarios. The fix ensures that the system accurately considers partially reconciled invoices and payments when determining follow-up actions. This improves the accuracy of customer statements and reporting.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#104337 Forward-Port-Of: odoo/enterprise#101874
This update resolves a minor issue in the invoice import process where the wrong company's purchase tax was sometimes selected when importing invoices in a business with multiple companies. This has been fixed to ensure accurate tax calculations across all company setups. The fix was part of a larger refactoring effort.
Original PR description
In v18.4, the invoice import has been refactored with these 2 PRs: - [189979](https://github.com/odoo/odoo/pull/189979) - [75327](https://github.com/odoo/enterprise/pull/75327) This introduced a small bug where, in a multi-company setup, an `account.tax` could be selected from the wrong company when `_fetch_mail()` was called from the cron `Mail: Fetchmail Service` or if the method was called manually from the wrong company. Ticket: opw-5375785 Forward-Port-Of: odoo/enterprise#104075 Forward-Port-Of: odoo/enterprise#103190
This update corrects a terminology issue in our accounting reports. Specifically, it replaces instances of 'VAT' with 'tax' across various locations, ensuring consistent and accurate reporting for US and international users. This change improves clarity and avoids confusion related to tax terminology.
Original PR description
In the US and many other countries, the term "VAT" doesn't really exist. Most countries have their own term to refer to a sales tax or other types of taxes and have already adjusted it via translations. Given that we can't create a translation for en_US just to translate VAT -> Tax, we have to swap the few places that refer to taxes as VAT to actually use tax as it is a more universal term than VAT. task-5401292
This update resolves an error that prevented users from creating and saving bank statements within the accounting module. The issue stemmed from a problem accessing data within the system, now corrected by using a more reliable method for data retrieval. This ensures a smoother experience when managing bank transactions.
Original PR description
We get an owl error: `TypeError: Cannot read properties of undefined (reading 'root').` The code tries to read data from this.env.model, but it is undefined. Steps To Reproduce: 1. Install `account_accountant` 2. Go to Accounting Dashboard > Bank > `...` > Transactions 3. Open in the list view 4. Select any number of transactions 5. Type something in the statement field of one of the rows 6. Press Create and Edit to create a new Statement 8. Save the statement Ticket [link](https://www.odoo.com/odoo/project.task/5352277) opw-5352277 Forward-Port-Of: odoo/enterprise#104072 Forward-Port-Of: odoo/enterprise#101232
This update fixes a display issue in search results, now consistently showing a helpful 'Domain is invalid' message instead of errors. Additionally, the search logic has been optimized for better performance and allows users to easily filter for records that don't meet specific criteria (e.g., 'Is Not Set').
Original PR description
Search method logic was rewritten so since commit:
https://github.com/odoo/odoo/commit/92301a5b300dec1ddfca44dc35318b83d67c56fa
`raise NotImplementedError(_("some text"))`
no longer raises an error nor does it ever show the error message. Instead a notification that says "Domain is invalid. Please correct it" is always displayed when the method is unable to run the search. Therefore we update the legacy way of doing it in these search methods so that the code is clean (i.e. so no one copies it) and to avoid translating strings that will never be visible.
Additionally, the search logic was also updated such that the `value` exists is no longer needed and the `=`/`!=` operators are handled by `in` for optimized code. This change makes it so users can now do the "Is Not Set" search since it will return only the records that do not match the "Is Set" logic.
Forward-Port-Of: odoo/enterprise#104213
Forward-Port-Of: odoo/enterprise#104115This update resolves a technical issue that caused a traceback error when using pivot tables within Odoo's spreadsheet functionality. The fix ensures pivot tables now function correctly, regardless of the data dimensions used, improving spreadsheet usability for users. This improves data analysis and reporting.
Original PR description
Task: 5085724 Forward-Port-Of: odoo/enterprise#103369
This update resolves an issue where FrontDesk hosts with limited access were unable to check out visitors via email. The fix allows the checkout process to run with elevated permissions, ensuring all hosts can successfully complete the visitor checkout. This improves the user experience for FrontDesk staff.
Original PR description
Steps to reproduce: * Create a visitor record with a host who has only FrontDesk user access. * Ensure Notify with Email is enabled on the station. * Click Check Out Visitor from the received email → access error appears. Issue: * Hosts with only FrontDesk user access received an access error when clicking the “Check Out Visitor” button from the email notification. * They were unable to complete the visitor checkout process. Fix: * Run the checkout action with sudo() so the host can successfully check out the visitor from the email link. Impact: * Hosts can now check out visitors without encountering permission errors. task-5373026 Forward-Port-Of: odoo/enterprise#104250 Forward-Port-Of: odoo/enterprise#101179