Daily updates from Odoo
Thursday, April 16, 2026
30 changes · master
New functionality added to Odoo
This update introduces core functionality for complying with Belgian Joint Committee 302 (CP302) regulations within our payroll system. It includes features like seniority calculations, premium payments for overtime, and specific wage reductions for students and work clothes, ensuring accurate and compliant payroll processing for Belgian employees.
This update adds integration with the ZKTeco BioTime attendance system, automatically syncing employee attendance records. The system prioritizes matching new check-ins with existing attendance data and flags any unmatched transactions for HR review. Old attendance records are automatically deleted after 30 days.
Original PR description
Add integration with ZKTeco BioTime attendance system. Introduce two new models: - zkteco.terminal: represents physical attendance devices synced from the BioTime server - zkteco.transactions: stores raw punch records fetched via the BioTime API and processes them into hr.attendance records Check-out transactions are matched in priority order: 1. Existing open attendance (no check-out) within a configurable lookback period (default 2 days) 2. A check-in from the current processing batch (FIFO) 3. If no match is found, the transaction is left unprocessed and an activity is created for the HR manager to review Processed transaction records are automatically cleaned up after 30 days. Task-4521436
Enhancements to existing features
This update improves the Social Balance Sheet report by adding key data points like overtime and streamlining the report's structure. The changes also include updated translations for French, Dutch, and German, ensuring accurate reporting across multiple languages. This enhancement provides more comprehensive financial data for business analysis.
This update improves the Gantt view by displaying progress bars for all employees, regardless of whether they have scheduled leave. Previously, the Gantt only showed progress for employees with leaves. This enhancement provides a more complete and accurate view of employee work hours.
Original PR description
…hose without leaves Previously, the gantt view only showed the progress bars (the number of worked hours) for employees who had leaves. Now, this PR shows the progress bars for all employees, even those without leaves. Task-5999717
This update enhances the self-order point-of-sale system by adding a country prefix selector for phone numbers. This simplifies the process for customers entering their contact information, improving the user experience and reducing potential errors. The change aligns with recent community updates for a consistent user flow.
Original PR description
In this commit we adapt a tour such that it follows the changes done in the corresponding community commit. Task: 5913205
This update simplifies the holiday scheduling view within the Enterprise module. The outdated custom popover has been replaced with the standard dialog used in other views, creating a more consistent and user-friendly experience. This change improves usability for HR staff managing employee time off.
Original PR description
- removed the custom popover for the timeoff gantt view and replaced it with the same dialog that appears in other views task-id: 5473334
This update enhances the reliability of tests within Odoo's enterprise modules by ensuring consistent handling of company environments. The changes address a limitation where simply specifying the company wasn't enough to filter tests correctly, leading to inconsistent results. This improves the overall stability and accuracy of the testing process.
Original PR description
More information on the related community commits.
This update clarifies the capacity settings within the appointment scheduling feature. The changes involve updating labels for both users and resources, making the system easier to understand and use. Additionally, a minor simplification was made to the timezone settings, improving code efficiency.
Original PR description
This commit improves and clarifies the capacity feature on the form view of the appointment type model by changing some labels for both users and resources. Also takes the opportunity to simplify the syntax of the timezone setting in the controller by removing unnecessary code. task-5173341
This update introduces a system to track payrun closing dates specifically for different employee types within the payroll system. The system now provides a warning to users when payrun closing dates are not set for particular employee types, ensuring accurate payroll processing and compliance. This improves payroll management and reduces potential errors.
Original PR description
In this commit, we added a payroll_closing_date for the employee type model. We added a warning to notify the user when the payrun closing date for that employee type. task-5922782
This update allows users to add rentable products directly to sales orders, automatically converting them into rental orders. To revert to a standard sales order, users must remove the rental dates. This simplifies the process of managing rental products within sales transactions.
Original PR description
Before this commit, rentable products could only be added to rental orders. This makes sense because the sales price of a rentable product is actually the rental price. Adding a rentable product to a standard sales order would undervalue the product. For example, a bike rented for $100/week should not be sold for $100, but rather $1000. After this commit, adding a rentable product to a sales order automatically converts it to a rental order. To convert a rental order back to a sales order, users must remove both the start and return rental dates. task-6003684
This update enhances the Discuss interface by displaying phone call status icons, providing a clearer picture of user availability. It automatically tracks active calls and prioritizes leave status when the HR Holidays module is enabled, ensuring accurate presence information. This improves communication and coordination.
Original PR description
Display phone status icons in Discuss when a user is on a call. Compute phone_* IM status on active calls and notify presence updates. Ensure leave status keeps precedence when hr_holidays is installed. community PR: https://github.com/odoo/odoo/pull/254136 task-5478885
This update aligns the self-order POS tour with recent community changes, streamlining the user experience. It involves adapting the delivery distance calculation to ensure accurate estimations for self-order transactions, enhancing the overall functionality of the POS system.
Original PR description
In this commit we adapt a tour such that it follows the changes done in the corresponding community commit. Task: 4177086
Resolved issues and error corrections
This pull request corrects a minor typo in the Odoo Enterprise settings related to company information for several payroll localizations (BE, IN, LT, LU, MA). The change ensures consistent and accurate wording within the application, improving the user experience. This fix addresses a visual inconsistency that could have caused confusion.
Original PR description
To reproduce the issue: 1. Install either BE,IN,LT,LU,MA payroll localization 2. Open settings view 3. "Offical Company Information" Should be "Official Company Information"
This update ensures the 'Load Order' button remains hidden across all screen sizes for Grab/GoFood orders. Previously, resizing the window would briefly show this button, which was replaced with 'Set Food Ready' to prevent manual order changes. This change improves the user experience and data integrity for these orders.
Original PR description
For Grab/GoFood orders, the "Load Order" button is replaced by "Set Food Ready" to prevent manual edits. Previously, resizing or minimizing the window caused the hidden "Load Order" button to reappear due to responsive layout overrides (e.g., mobile view CSS classes). This commit updates the visibility logic to ensure the button remains strictly hidden across all screen sizes for external delivery orders. opw-6044176 Forward-Port-Of: odoo/enterprise#111222
This update fixes an issue where appointment bookings were incorrectly reserving full party sizes for resources. The change ensures that resources are accurately allocated, preventing overbooking and improving the scheduling process. A new test has been added to verify the fix.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113908 Forward-Port-Of: odoo/enterprise#113805
This update ensures that transaction dates used to fetch data from iap are always within the correct 'lock date' range. Previously, dates could be inaccurate, leading to potential data discrepancies. This fix guarantees the most reliable and accurate retrieval of financial information.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update resolves an issue where the 'Time Off Type' dropdown was empty when creating time off entries via the Gantt view. The fix ensures the dropdown correctly displays available time off types by properly filtering the database search. This improves the usability of the time off management feature.
Original PR description
**Steps to Reproduce:**
1. Open Time Off App->Management->Time Off->Gantt View
2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set".
3. Open the "Time Off Type" dropdown.
Result: The dropdown is completely empty.
**Bug Cause:**
The Gantt multi-create popover skips `_loadNewRecord`, meaning `work_entry_type_filter_domain` never computes and evaluates to an empty list. This hardcodes `('id', 'in', [])` into the search, forcing the database to return 0 records.
**Solution:**
Remove the broken computed `('id', 'in', [])` domain from the `work_entry_type_id` field in `hr_leave_gantt_multi_create_view`. Add the `context="{'gantt_multi_create_company_filter': True}"` flag to the field to trigger the country-filtering logic implemented in the `_search` method.
**Task:** 6109569This update corrects a technical issue impacting Envia delivery in Colombia. Previously, the system incorrectly formatted zip codes, leading to inaccurate data sent to Envia. Now, the system uses Envia's geocoding to ensure correct data formatting, improving delivery reliability and reducing potential delays.
Original PR description
For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code. When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`. Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally. opw-6083181 Forward-Port-Of: odoo/enterprise#112838
This update resolves an issue preventing the generation of the session report in the CO company setting. The fix addresses a technical problem with accessing sale details, ensuring users can now successfully generate and utilize this important report. This improves the functionality of the point-of-sale system.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update resolves an issue where the system was incorrectly retrieving neutralization data for payroll calculations in Switzerland. The fix ensures accurate payroll processing by correcting the way the system fetches this critical information. This improves the reliability of financial reporting related to employee compensation.
Original PR description
Forward-Port-Of: odoo/enterprise#113961
This update resolves a test failure in the WhatsApp module related to how archived user IM statuses are handled. The test case was incorrectly designed, failing because the partner wasn't linked to a user. The fix ensures the test accurately reflects the system's behavior by properly linking the partner to a user.
Original PR description
Purpose of this PR: compute_im_status returns false when main_user_id is not set. The testcase was failing because the partner was not linked to a user. Updated the testcase by linking the partner to a user to match the expected behavior. task-4797343
This update ensures that waiting payslips (draft payslips with calculated amounts) are automatically recalculated whenever employee information or payroll settings are modified. This guarantees that the payslip data remains accurate and reflects the latest changes, improving payroll reporting reliability. This change addresses a potential discrepancy between the payslip and the underlying data.
Original PR description
This commit makes waiting payslips recomputes whenever inputs are changed to make sure the sheet is up to date with inputs -waiting payslip: a payslip in draft with computed lines Task#5439146
This update resolves a potential issue where timesheet rules could cause access errors due to mismatched company restrictions on linked projects. By adding a company ID to the timesheet rule, we ensure that projects linked to the rule adhere to the same company, preventing these access problems and improving user experience.
Original PR description
This commit's purpose is to prevent potential access rigths error with aw.rule. Currently it is possible to set a project/task that is restricted to a specific company to an aw.rule. This can lead to a user using that aw.rule having access rights error because he does not have access to that project. To fix this issue, we add a company_id to the aw.rule model and ensure that the project/task linked to it follow the same company as the aw.rule it is set on task-6116548
This update fixes a bug where changes to embedding settings caused sources to incorrectly show as 'processing'. The fix ensures that updates are properly processed and sources are updated correctly, preventing delays and inaccurate status displays. This improves the reliability of the AI embedding feature.
Original PR description
### Issue: In ai.agent, any update to any field causes the sources to be shown as processing. ### Fix In `ai.agent.write()`, the provider change detection was comparing the provider object directly against the stored provider name string. Also, `_cron_generate_embedding` returned early when no missing embeddings were found, skipping the `_update_sources_status` call and leaving sources stuck in processing status. task-id-6121579
This update corrects a technical issue that was preventing users from properly accessing returns reports. The change ensures that the reporting module functions correctly after a recent update to the main account kanban view. This resolves a traceback error and maintains the reliability of the returns reporting process.
Original PR description
After a recent IMP in account return kanban view in #113292 , the overall styling of kanban view was improved, but the inherited view in this module was unchanged which caused traceback. This commit fixes that issue.
This update addresses a crash that occurred when users cleared the 'Today' date filter or selected 'All time' in the global filters. The fix ensures the system remains stable and prevents unexpected errors, improving the user experience. This resolves a technical issue impacting spreadsheet edition functionality.
Original PR description
traceback when deleting the current value of a date filter Task: [6019061](https://www.odoo.com/odoo/2328/tasks/6019061)
This update enhances the Sign module's user experience by streamlining request workflows and addressing key usability issues. Specifically, users can now cancel sent signature requests and receive prompts to update contact information, while a critical bug causing issues with the 'Thank You' dialog has been resolved.
Original PR description
This commit introduces several UX improvements, workflow adjustments, and bug fixes to the Sign module to streamline the user experience. Specific changes: - Views & UI: - Add a related model filter to the sign templates search view. - Clean up the sign request pivot view by removing irrelevant measures. - Request Management: - Allow the original request sender to cancel a sent signature request. - Stop automatically saving the certificate of completion into the Documents app. - Integrate the missing-email popover into the Send Sign Request wizard to prompt users to update contacts on the fly. - Bug Fixes: - [FIX] Resolve the dismiss bug in the Thank You dialog by properly hooking the ESC key/background click into the global dialog environment.
Code cleanup and technical improvements
This update standardizes how date ranges are handled in Odoo's Enterprise module's user interfaces. Previously, relative filters (like 'last week' or 'last month') were implemented inconsistently, leading to errors. This change ensures correct date filtering when users select date ranges, resolving a previous 'Invalid Daterange' issue and improving the overall user experience.
Original PR description
Currently, preset relative filter in view architectures (last week, last month ...) are all written differently. Sometimes they include today, sometimes not, some used 7d + 1d ... We rewrite them to be compatible with the smart dates. WHY: When oponing these arch filter in the filter dialog, we now have the correct smart date instead of `Invalid Daterange` Community PR: odoo/odoo#252484 task#5959944
This update streamlines how work entries are tracked by removing a redundant selection field. It replaces it with a simple boolean flag, making the system more efficient and easier to manage. This change improves the accuracy of time-based calculations related to attendance and schedules.
Original PR description
As of now, the work_entry_source field is a Selection field that is defined in hr_work_entry with only 1 option (Time Off) and then overridden in hr_work_entry_attendance to add another option…
As of now, the work_entry_source field is a Selection field that is defined in hr_work_entry with only 1 option (Time Off) and then overridden in hr_work_entry_attendance to add another option (Attendance). This doesn't make sense anymore, because: 1) Time Off is always considered, that option makes it so that the time is based on the working schedule. 2) There are at most 2 options, so it doesn't need to be a selection. For these reasons we remove the field and substitute it with a Boolean field attendance_based. This field will be defined in hr_work_entry_attendance and, since in the code work_entry_source was sometimes referenced even without the attendance module installed, we change those references to instead use a function result. In other words, anything in hr_work_entry_attendance or that depends on it can directly use the attendance_based field, while if we need to use code that is not dependant on it, we instead call a new _get_work_entry_source function that by defualt returns 'calendar' (the name of the Time Off option in the selection, but is then overridden in hr_work_entry_attendance to return 'attendance' if the attendance_based field is checked. Task: 6050497 Community PR: https://github.com/odoo/odoo/pull/254900
This update changes how tracking information is stored in email messages, resulting in significant space savings and faster loading times. By storing tracking data directly within the message body, the system avoids complex database queries and reduces code complexity, leading to improved performance and a simplified development process.
Original PR description
RATIONALE Independent study [1] recently showed that storing tracking values takes quite some db space for few "real usage". Storing tracking values directly in body html is therefore considered as…
RATIONALE
Independent study [1] recently showed that storing tracking values takes
quite some db space for few "real usage". Storing tracking values directly
in body html is therefore considered as an alternative to using a table with
fields holding field ID, information, old and new values in a structured
and easy-to-manipulate way.
According to the study author [2], advantages are
* up to 30% db space saved;
* faster read when chatter is loaded as we can remove queries required to
access tracking value table, as well as field-based group check that
ensure security at field level;
* faster write (which globally never happen in real life use cases);
* globally faster update due to not having index on tracking table to
update;
* easier search, allowing to search words in body instead of having to
search in body + in field_id / old_value / new_value of tracking
value model;
* less custom code for audit trail, which does simple html formatting
based on tracking values;
* less custom code for formatting. Having directly html allows to remove
code that fetches tracking values (protected model), formats it and send
it to frontend JS chatter, which in turn has to define a model and
formatting for those;
Disadvantages that should not be considered as disadvantages are
* no more field-based security. It is known since tracking introduction
that field with group should not be tracked [3];
* loss of translation support: search on translated field names for
example is not possible, as field name is stored translated. However
this is not considered as an issue, because you generally search on
values (content) which is often language independent. Translated values
search was not correctly supported with tracking values (e.g. selection
fields), and this is not going to be improved with html. We could have
improved tracking value translation support but it was not considered
as being worth it;
* potential loss of protection against update. Previously tracking values
were not accessible to anyone (except admins), unless going through
dedicated methods or controllers. Now being able to update body means
being able to update tracking values inside it. Protection can be added
but checking pre- and post- content of html fields is notoriously fragile
and more easily bypassed. This was not considered as a real issue even
for audit trail;
Although original study author explains that tracking value were never used
in Odoo, it is also worth pointing out that removing tracking value model
leads to several changes in various addons:
* duration mixin rewrite. This mixin computes time spend in stages for
heavy production models like crm.lead, project.task, helpdesk.ticket,
hr.applicant. It was previously computed based on tracking values, aka
no extra db usage. We now have to store this time information as
retrieving it in html is not really scalable. This means a new ever
growing fields on those models, storing time information in json.
* project burndownchart rewrite. It was also based on tracking values
and therefore needs a complete rewrite.
* mrp.production requires a new stored field to find the last start
production date, previously fetched (without performance issue
being reported) in tracking values;
* hr.leave.allocation requires a new stored field to store allocation
change for accrual, previously fetched (without performance issue
being reported) in tracking values;
* hr.recruitment.report rewrite, as it was based on tracking values and
now uses stored duration mixin values;
* tracking values were also used for sale.order log and tracking but
"time issues" lead to rewrite them as a custom model instead of
tracking values a few years ago (without clear insights on what
was really the issue, original author of this change being the same
as the one requesting removal of tracking values);
Other authors [4] tend to disagree with the study author, pointing out that
* people actually track fields with groups -> this may lead to security
issues, or having to stop tracking those fields. Study author discards
this usage, considered as advanced / too niche;
* having to store duration information, allocation details, mrp production
date, ... is going to negatively impacts db storage gains. Study author
considers those are negligible without providing any numerical
value;
* storing html means no easy chatter reformat, as well as useless noise
stored in db (html nodes, class names, ...). Study author points out
that his study shows at least 30% gain whatever the situation;
* easier leak of tracked values: each person having access to the
message has access to body, hence tracking values. Previously tracking
values were never accessible (except admins), only given through
dedicated controllers or methods (e.g. discuss store);
* tracking values are used in production environment notably when
analyzing issues (e.g. previous state of records, ...), having a stored
structured way of finding information is valuable in this case. Doing
same analysis in html is going to be harder, especially with non
translated field names, parsing html, ...
* gained db space is anyway negligible compared to a full production
db (e.g. optimistic estimated 50 Gb for a 3 Tb on odoo.com). This is
anyway going to be erased by ever-growing size of db (accumulated
messages, activities, ...);
All this taken into account it was decided by R&D head to move to html
usage for tracking values, given the numerous advantages it gives. However
in order to still allow advanced usage of tracking values, a now optional
module holds the mail.tracking.value table and records creation when
performing tracking. With that module feature should globally be equivalent
(minus the field-level groups security support) for advanced / technical
usage.
DETAILS
Please also refer to community commits.
**Commit 1: helpdesk: store stage durations according to company working hours**
-------
This commit updates helpdesk ticket stage durations based on the company’s
working hours. We now store the total working hours in duration_tracking,
which is used for ticket sla frozen hours instead of the tracking model.
Example: a ticket stays in a stage for 2 days. Previously, it recorded 24
hours, but now it stores 16 hours based on working hours.
This duration is used in sla policies, so there is no longer a need to
manually exclude non-working hours.
**Commit 2: hr_recruitment_reports: refactor recruitment stage analysis report**
--------
Use stage duration to determine how long an applicant stays in each stage
which was previously based on the tracking model.
hr_recruitment_stage_report: convert the report to use the duration_tracking
format. start and end dates are now computed based on the time spent in each
stage.
**Commit 3: account_followup, hr_payroll, helpdesk_stock: clean tracking & groups on fields**
-----
- Remove groups from fields to avoid restricting tracked values
- Add missing tracking=None where needed
**Commit 4: l10n_us_hr_payroll: store allocation data changes**
-----
Previously to this commit accrual is computed based on tracking values linked
to 'number_of_days' field previously to the requested date. As we are
migrating away from stored tracking values we now store dedicated
information on allocation itself.
New field is a JSON holding date-based changes. Overall computation and
behavior should stay the same as before.
REFERENCES
Also see odoo/odoo#248505 (and linked PRs) for preliminary work cleaning and
improving tracking mechanism.
Task-5260614
[1] cannot disclose it but it might come from a bigram who wants to remove
that table since (at least) 2017 and prefers to have each addon doing
some kind of custom tracking instead of a transversal approach;
[2] see 1;
[3] :shrug:
[4] globally most of R&D senior developers as depicted in January and February
internal guru meetings;
Co-Authored-By: Prakash Prajapati <ppr@odoo.com>
Co-Authored-By: Jigar Vaghela <jva@odoo.com>
Co-Authored-By: Fabien Pinckaers <fp@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>