Daily updates from Odoo
Saturday, May 23, 2026
17 changes · master
New functionality added to Odoo
This update adds a new field for NISS (National Identification Number) directly to the employee search view within the Odoo Enterprise system. This allows for more precise employee identification and reporting, aligning with Belgian payroll requirements. It improves the accuracy of employee data retrieval for HR and accounting processes.
Original PR description
Adds the NISS field directly to the employee search view task:6233643
Enhancements to existing features
This update simplifies Odoo controller code by replacing `request.env` with `self.env`, aligning with existing model practices. This change reduces code complexity and improves maintainability, ensuring a more consistent and efficient system.
Original PR description
*= `payment_sepa_direct_debit, sale_(amazon, lazada, shopee), website_sale_(*)` Purpose of this commit: - Since https://github.com/odoo/odoo/commit/9ce68df56cf01ad166de4d21d1670fbd9631940d, `self.env` can also be used in controllers as a replacement for `request.env`. This significantly reduces the need to import and rely on request in controller code. - Using request has already become bad practice in models. With this change, we aim to reduce its usage in controllers as well, aligning controller code more closely with model practices. - Therefore, within our scope, all occurrences of `request.env` are replaced with `self.env` wherver possible. See also: - https://github.com/odoo/odoo/pull/262467 task-6172360
This update enhances the Odoo Enterprise phone system by adding tooltips to long names displayed in call summaries and contact information. This improves usability by providing more context and detail for users, particularly when dealing with lengthy names or numbers.
Original PR description
Task-6179948
Resolved issues and error corrections
This update fixes an issue where ticket close times were inaccurate when tickets were reopened and closed again. Now, the calculation considers only the time spent in currently open stages related to the ticket's team, providing a more precise record of time spent resolving the issue. This ensures more reliable reporting on support team efficiency.
Original PR description
Issue: When a ticket is reopened and closed again, `close_hours` included time spent in previous closing stages, causing inaccurate total close time. Before this commit: The `close_hours` field was computed as the total time from ticket creation to close date. If a ticket was closed and later reopened, the time spent in the closed stage was still included in the final `close_hours`, which led to inaccurate results. After this commit: `close_hours` is now computed by summing the working minutes from `duration_stage_tracking` field, considering only the open stages related to the ticket's team. task-4133988
This update allows Invoicing Administrators to delete or edit reconciled lines in the accounting system, resolving a previous restriction. The change ensures consistent access control based on the line's review status, aligning with existing accounting rules and improving usability for administrators. This update was driven by a bug fix related to privilege checks.
Original PR description
Deleting or editing a reconciled line raised "Validated entries can only be changed by your accountant." for Invoicing Administrators because the check only tested `group_account_user`, which is not granted by the Invoicing privilege chain. Delegate to `AccountMove._check_review_state_access()` to apply the same rules as `account.move`: - `'supervised'` → requires `group_account_manager` - `'reviewed'` → requires `group_account_user` or `group_account_manager` - `'todo'` / `'anomaly'` → no restriction opw-6128792 Forward-Port-Of: odoo/enterprise#117795 Forward-Port-Of: odoo/enterprise#114833
This update fixes an error in how VAT reimbursement moves are generated when unclaimed tax is carried over to the next month. The previous calculation incorrectly used data from the previous month's tax report, leading to inaccurate reimbursement amounts. This ensures accurate VAT reporting and proper reimbursement processing.
Original PR description
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and…
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and post a bill in May containing a VAT amount. - Create and post a bill in June containing a VAT amount. - Create a VAT return for May to carry over the VAT amount to the next month. - Create a VAT return for June, requesting the full VAT amount to be reimbursed. - Validate and send the June VAT return. - Check the generated reimbursement move Issue: Line values does not correspond to anything real/tangible. It occurs because when computing the ratio for the move we check the last tax report entry, where we find the amount of tax from the past months and a line balancing the last month that should not be taken into account. The "Balance tax current account (receivable)" line from the tax closing entry is mistakenly picked up as a tax carried forward line, throwing off the amounts. opw-5961836 Forward-Port-Of: odoo/enterprise#117927 Forward-Port-Of: odoo/enterprise#115451
This update fixes a bug where the Odoo Agent would repeatedly fail when updating records without the specific 'natural language query' topic. By adding a list of available menus and models to the context, the Agent now correctly identifies and interacts with records, preventing timeouts and improving stability.
Original PR description
Purpose: -------- The update and create tools can generate a link to show a preview of the created/updated record. However, the list of available menus is only added when the agent has the natural language query topic. Therefore, when using the Odoo Agent (that does not have that topic) to update a record, the LLM loops on the update record tool guessing random menu ids and eventually times out because the tool calls fail since the menu ids guesses do not match the model of the updated record. The list of available menus is now added in the context if the create or update records topics are available on the agent. The list of available models has also been added in this case. Task-6236642 Forward-Port-Of: odoo/enterprise#117998
This update fixes a problem where adding rental products to the cart would fail due to mismatched date calculations. The fix ensures that rental product durations are correctly handled, preventing errors when mixing different rental periods and improving the overall rental experience. This resolves a conflict between how dates are stored and processed during the cart addition process.
Original PR description
Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3.…
Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3. Add to card directly from the product card 4. Add a rental product from product image that has date type value date 5. Go to that product details page. 6. Click add to cart -> Invalid operation, You cannot mix different rental periods... Cause: ====== When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added. However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing). This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page). Solution: ========= The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist. opw-5450576 Forward-Port-Of: odoo/enterprise#117946 Forward-Port-Of: odoo/enterprise#103373
This update resolves an issue where users would encounter an error when attempting to sign in to planning slots without a defined end date. The fix ensures that the system handles empty end dates gracefully, preventing the error and allowing users to successfully schedule tasks. This improves the overall reliability of the planning feature.
Original PR description
Currently, an error occurs when user tries to signin on a planning slot which doesnt have an end date selected.
Steps to replicate:
- Install `planning_field_service` and open Planning.
- Click New > Add a Customer > Change status to `Scheduled`.
- Remove end datetime (right one) > Click `Sign In`.
Error:
```
File '/home/odoo/odoo19/enterprise/planning_field_service/models/planning_slot.py', line 264, in action_sign_in
if now > self.end_datetime.astimezone(ZoneInfo('UTC')):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- As the user removed value from end datetime, `self.end_datetime` is False so we get this error when trying to access `self.end_datetime.astimezone()`.
Solution:
- Added a conditonal check for `self.end_datetime` before accessing `self.end_datetime.astimezone()`.
sentry-7480608465
Forward-Port-Of: odoo/enterprise#117425This update fixes an issue where users could attempt to change assets to draft after setting lock dates in the accounting system. This prevented users from modifying finalized accounting records, ensuring data integrity and compliance with accounting standards. The change restricts draft status for assets after lock dates are applied.
Original PR description
Steps to reproduce: 1- Install Accounting 2- Go to [Accounting -> Assets] and create a new asset with start date 1/1/2025 3- Specify the fixed asset account and confirm the asset 4- Open [Accounting…
Steps to reproduce: 1- Install Accounting 2- Go to [Accounting -> Assets] and create a new asset with start date 1/1/2025 3- Specify the fixed asset account and confirm the asset 4- Open [Accounting -> Lock Dates] 5- Set a Lock date on everything with the date 31/12/2025 and save 6- Cancel the asset, set to draft and confirm again Issue: `Invalid Operation: The remaining value on the last depreciation line must be 0` Expected behavior: Should not be able to set to draft once the asset is cancelled Why this happens: Commit 66db1d5 introduced a new condition on the `Set to Draft` button which results in the button being visible when it should not be. If a Lock Date is set after an asset is confirmed, the acquisition and any depreciation entries are effectively finalized in the accounting history. Allowing a user to "Set to Draft" at that point would involve deleting or modifying entries in a closed period, which violates accounting integrity. opw-6152777 Forward-Port-Of: odoo/enterprise#116900
This update enhances the working files reporting feature by adding a confirmation step when deleting files, preventing accidental data loss. It also ensures all working files open in the standard cycle view and displays embedded actions correctly. These changes improve the user experience and data integrity for account reports.
Original PR description
contains: [FIX] account_reports: Working files delete button: - hide it for non-accountant - add confirmation dialog [FIX] account_reports: Working file should always open in cycle view [FIX] account_reports: Always show embedded actions in Working files task-5880319 Forward-Port-Of: odoo/enterprise#117831 Forward-Port-Of: odoo/enterprise#115596
This update resolves an issue preventing normal users from canceling approval requests they created. The fix utilizes 'sudo' to grant the correct permissions, allowing users to successfully cancel their own approvals and streamlining the workflow.
Original PR description
Issue: - A user who created an approval request could cancel it. But a rights error appeared during the cancellation. Steps to Reproduce: - Create an approval being a normal user. - Try to cancel the approval. - A ValidationError is raised eventhough the approvals can be cancelled by creator of it. Fix: - Changed the cancel action to use the sudo for the user who created the task and can cancel it Impact: - Users can cancel their own approval requests without errors. Task: 6123104 Forward-Port-Of: odoo/enterprise#114189
This update resolves a crash that occurred when users clicked the 'hide' button on the payroll dashboard due to an error in how in-memory payrun warnings were handled. The fix ensures warnings are correctly identified and processed, preventing the database error and improving dashboard stability. This change impacts the payroll dashboard functionality.
Original PR description
Closing date payrun warnings are created as in-memory records (.new()), giving them a NewId instead of a real integer DB id. When the user clicked the hide button, this NewId string was passed to action_snooze/action_archive, causing a psycopg2.errors.InvalidTextRepresentation SQL error. Fix by sending False as the id for in-memory warnings in get_payroll_dashboard_warning_cards, and suppressing the hide button on the dashboard when warning.id is falsy. task-6205849 Forward-Port-Of: odoo/enterprise#117854
This update resolves an issue where the generic tax report wouldn't display an error message when dealing with negative net values. The fix ensures that the report accurately checks for tax discrepancies, regardless of whether the net amount is positive or negative, improving report reliability.
Original PR description
**Issue:** In the generic tax report, a check is performed on the report lines to ensure that the declared tax amount is consistent with the expected amount. If the difference between the declared tax amount and the expected one is higher than 0.1% of the declared net amount, then a error message is displayed. If the net amount is negative, the error message is never displayed because the computed percentage of the tax difference is negative and therefore lower than 0.1% (i.e. 0.001). opw-6014350 Forward-Port-Of: odoo/enterprise#117990
This update fixes an issue where the POS incorrectly applied AvaTax fiscal positions even when AvaTax wasn't activated in the POS settings. The system now prioritizes AvaTax fiscal positions only when AvaTax is enabled in the accounting settings, ensuring accurate tax calculations for POS transactions. This improves the reliability of the Point of Sale tax functionality.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 Forward-Port-Of: odoo/enterprise#116626
This update fixes a potential error message displayed when spreadsheets are unavailable, preventing disruptions to user workflows. The change handles server errors within the system, eliminating the need for complex template modifications and streamlining the process. This improves stability and user experience.
Original PR description
The fix suggested in #81276 did not account for other spreadsheet models than a document as it required some modification in the component template. The same logic should then have been forwarded to other models (quality.check for instance] but that process is error prone. This revision changes the approach by handling the server error inside the abstract action so that no template modification is required. task-6208222 Forward-Port-Of: odoo/enterprise#117934 Forward-Port-Of: odoo/enterprise#117221
This update fixes inconsistencies in how barcode settings are applied to Manufacturing Orders. Previously, mandatory scan requirements weren't consistently enforced, allowing users to bypass them. Now, the system correctly utilizes MRP operation type configurations, ensuring accurate barcode tracking during production processes.
Original PR description
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For…
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For example, setting the scan of lot/serial as mandatory didn't prevent the user to set automatically a SN on consummed component by generating a lot/serial on the produced product or by clicking on "Produce All" button. This commit adds some conditions to avoid to update barcode lines in case they should depending of the config. This commit also fixes a related issue where the MRP operation type's config wasn't used at all when a MO is created directly from the Barcode app. As the config is get from the MO's picking type and no MO exists when a new one is created from the Barcode app, there is no MO's config returned in the data send by the server. To fix that, the config is now updated clientside when the data are fetched after a save. [Task-5420762](https://www.odoo.com/odoo/project/966/tasks/4655907/project.task/5420762) [opw-5223507](https://www.odoo.com/odoo/project/49/tasks/5223507) Forward-Port-Of: odoo/enterprise#117816 Forward-Port-Of: odoo/enterprise#113318