Daily updates from Odoo
Monday, May 11, 2026
25 changes · master
New functionality added to Odoo
This update introduces the ability to link Point of Sale (POS) orders to rental sale orders, streamlining processes for businesses like hotels. Users can now associate POS transactions with specific room bookings, simplifying revenue tracking and inventory management. The system handles stock updates while accounting focuses on the core sale order.
Original PR description
This commit adds modules pos_sale_planning and pos_sale_renting_planning which provide a new feature to put a POS order on the sale order of a rental. It's actually a bit larger. We can put a POS…
This commit adds modules pos_sale_planning and pos_sale_renting_planning which provide a new feature to put a POS order on the sale order of a rental. It's actually a bit larger. We can put a POS order on a sale order linked to a slot linked to a resource. This is useful for example in a hotel scenario where you want to put some pos order on the checkout of a room. To do that, user have to create a payment method, select "link resource" and select the resources he wants. Then, in the point of sale, he will be able to select the payment method and the frontend will fetch the current opened slot linked to selected resource and ask the user on which slot/resource he wants to put the order. Then after the validation of the payment, the order lines will be consolidated by tax and added to the sale order linked to the slot. The accounting of the pos will not take into account those orders but the stock will. task-id: 6192655 Community PR: https://github.com/odoo/odoo/pull/263480
This update introduces a new, sticky dashboard within the rental order management system. It provides real-time counts of rental orders based on their status (Today, Late, etc.), streamlining workflow and offering a clearer overview for rental teams. The previous 'To Do Today' submenu has been removed to simplify the interface.
Original PR description
Add a sticky dashboard header to the rental orders list and kanban views showing live counts (Today, Late, In Progress, To Confirm, To Invoice). Clicking a card filters the view accordingly. Remove the "To Do Today" submenu in favor of the new dashboard. task-5358651
This pull request updates the .weblate.json file to include the translation for 'documents_project_sign'. This ensures that the Odoo Enterprise application is correctly localized for users in different languages, improving the user experience and supporting international expansion.
Original PR description
- Added `documents_project_sign` Forward-Port-Of: odoo/enterprise#115426 Forward-Port-Of: odoo/enterprise#115427
Enhancements to existing features
This update ensures the Unit of Measure is consistently displayed during Engineering Change Orders for BOM modifications – like adding or removing components or adjusting quantities. This improves clarity during reviews, reduces the risk of errors, and streamlines the BOM approval process.
Original PR description
- Currently, when users create `Engineering Change Orders` for a `BoM`, the Unit of Measure (UoM) is only displayed on the component change page when the UoM itself is modified. In other scenarios, such as `adding a component`, `removing a component`, or `updating the quantity` without changing the UoM the UoM is not shown, This lack of visibility can lead to confusion during BoM reviews and increases the risk of errors. - With this improvement, the UoM is consistently displayed for all component change scenarios, including adding component, removing component, or updating quantities. These changes provide clearer and more complete information during ECO reviews, helping users better understand BoM modifications and reducing the risk of mistakes. Task ID: [4394139](https://www.odoo.com/odoo/project/966/tasks/4394139)
This update addresses a specific payroll issue related to car BIK (Belgian vehicle identification number) taxes. It introduces a December-specific salary rule to correct overpayments made by employees, ensuring accurate tax calculations. This change improves payroll accuracy and compliance with Belgian regulations.
Original PR description
. Add a salary rule specific in December to make the regularization in case of employee have paid too much for the car bik task-6197625
This update modifies student wage calculations in Belgium to align with CP302 regulations. Specifically, the minimum wage is reduced by percentages based on the student's age (10% at 17, 20% at 16, and 30% at 15), ensuring accurate payroll processing for student employees.
Original PR description
In this commit, we included the CP302 work clothes fees salary and adjusted student wage rate calculation. - if the student age == 17, the min wage is reduced by 10% - if the student age == 16, the min wage is reduced by 20% - if the student age == 15, the min wage is reduced by 30% task-6036647
This update refines the Gantt view's appearance by removing unnecessary formatting. Specifically, it eliminates leading zeros from time displays and removes default ellipsis indicators when text overflows, resulting in a cleaner and more efficient use of screen space.
Original PR description
Two minor changes to save space and clean up the Gantt view: 1. Removed leading zeros from expected hours (e.g., "08h" to "8h") to save space inside the cells. 2. Removed the default "..." when text overflows on Gantt pills. The dots took up too much room on narrow blocks. task-6131562
This update simplifies how the system retrieves weight data from the scale. Previously, the system automatically checked for updates, but now users must manually click the 'get weight' button to fetch the current measurement. This change streamlines the process and improves user experience.
Original PR description
We simplify product get weight logic avoiding to poll new measures from the scale. We now need to click "get weight" in order to fetch the value directly.
This update enhances the grid view by disabling the 'Show weekends' button when the user selects the year scale. This prevents confusion as the grid only displays months at this scale, making the button irrelevant. This change improves the overall usability of the grid view.
Original PR description
In the grid view, when the user chooses the year scale, the view shows only months and not individual days. Since the `Show weekends` button has no effect in this case, it is disabled in this commit. <img width="901" height="273" alt="image" src="https://github.com/user-attachments/assets/2818e4b2-8a4d-4a58-802e-11e197917aa2" /> task-5164096
Resolved issues and error corrections
This update addresses minor visual inconsistencies in the calendar event views across different forms. Specifically, the resource selection field now takes up the full width of the modal, and a cropping issue with user counts in the Kanban view has been resolved. These changes enhance the overall user experience and consistency of the appointment scheduling system.
Original PR description
Purpose ======= Fix some small UI issues accross multiple calendar.event views Specification ============= In the quick create form view, extend the resources input so that it takes all the width of the modal like other fields. .o_tags_input elements are mw-100 but not w-100 like other inputs making them shorter than intended. In the kanban view, remove fixed width on "+ ..." users/resources count so that higher numbers aren't cropped. When calendar.event records has no name and a single attendee which is not a staff user, the event was renamed "attendee name - appointment type name". Changing that to name the event with the attendee name only, a filter/group by on the appointment types makes it easy to know which appointment type it's linked to. Task-6191731 Forward-Port-Of: odoo/enterprise#116420
This update resolves an issue where users couldn't edit documents after removing their ownership, even with editor permissions. The fix allows editing from the company folder and enables users to correct incorrect ownership assignments, improving document management flexibility.
Original PR description
How to reproduce: - Login as Marc Demo (not as admin) - Upload a document at the root of "My Drive" - Remove the owner of this document The document is no longer editable in the details view panel while the user has been added as editor. To solve the problem, we change the readonly condition in the detail panel to allow edition in the company folder also (even if not a manager). We also change the following: - we allow to move non folder document from company root folder (user_can_move) while the "protection" was applied also to non folder before. - we change the condition to update the owner. Now when there is no owner, a user with edit permission can change it. This allows to correct a wrong manipulation. Task-5881531 Forward-Port-Of: odoo/enterprise#116559 Forward-Port-Of: odoo/enterprise#106192
This update fixes an issue where subscription delivery dates were incorrectly displayed as the previous day due to timezone differences. The fix ensures delivery dates are accurately calculated based on the company's timezone, resolving a potential scheduling problem for subscription orders. This improves the reliability of delivery planning.
Original PR description
Steps to reproduce 1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. Create a sale order for a storable subscription product and confirm…
Steps to reproduce 1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. Create a sale order for a storable subscription product and confirm it. 3. Open the generated delivery order and check its Scheduled Date. Issue The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value (https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398). The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`. Solution Split the two cases explicitly: - First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow. - Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722). opw-6133831 Forward-Port-Of: odoo/enterprise#116593 Forward-Port-Of: odoo/enterprise#115100
A recent change removed configuration files used by the l10n_in_hr_payroll module, but the system continued to attempt to access them. This pull request corrects the code to remove these references, resolving an error that occurred when the 'Reset' button was clicked. This ensures the payroll module functions correctly.
Original PR description
Versiopn: - saas-19.3 Steps to reproduce: - Install the l10n_in_hr_payroll module - Create or update a rule parameter - Save it and click on “Reset” Issue: - A traceback (error) occurs Cause: - After this PR: https://github.com/odoo/enterprise/pull/107884 the files hr_salary_rule_ind_emp_data.xml and hr_salary_rule_worker_data.xml were removed. - However, the code still tries to use these files, which causes the error Fix: - Remove the references to these file paths from the code Task-6175296 Forward-Port-Of: odoo/enterprise#115616
This update adjusts payroll deductions for employees 60 or older. The system now stops NSSF contributions when an employee reaches 60 years, aligning with Kenyan regulations. A new test has been added to ensure this change functions correctly, particularly around the timing of the deduction stop.
Original PR description
[IMP] l10n_ke_payroll: stop NSSF deductions after 60
When the user is creating a payslip and if the age of employee is >=60 the NSSF deductions must stop
(If the 60 years is finished in 10th of March -> it will stop in April (deduction stop starts from next month))
Test:
Unit test is written to check stopping NSSF deductions with dynamic birthday.
task - 6074658
Forward-Port-Of: odoo/enterprise#115236This update ensures canteen cost calculations are accurate, even when employees don't have traditional worked day data. The change adds a simulation context, allowing the system to correctly estimate canteen costs based on employee configurations. This improves payroll accuracy for users in Belgium.
Original PR description
We add simulation context in the canteen cost condition, since we dont have worked day lines in that case Forward-Port-Of: odoo/enterprise#113907
This update ensures Odoo's Czech localization reports accurately comply with Czech tax regulations. Specifically, it implements hybrid rounding for VAT calculations – standard rounding for tax bases and rounding up to the nearest CZK for VAT amounts. This ensures accurate reporting and avoids potential issues with tax authorities.
Original PR description
In the czech localisation there are legal requirements to: - Use standard mathematical rounding for tax bases and subtotals - Round up to the nearest whole CZK for VAT Due/Tax Amounts - Calculated totals must be the sum of the previously rounded lines Which are not implemented in the cuurent report generation, The current change overrides the formula computation for these specific lines to comply with this legal requirement. task: 6081523
This update fixes a previous issue where helpdesk returns weren't available for orders shipped through dropshipping. Now, users can properly return dropshipped transfers directly from the helpdesk ticket, streamlining the returns process and improving customer service. This ensures consistent return functionality regardless of order fulfillment method.
Original PR description
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and…
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and quantity under the Purchase tab - Create a sale order for the product - Go to the Purchase stat button and confirm the order - Click on the Dropship stat button and validate the transfer - Open Helpdesk and create a new ticket for the same partner ### Issue: The "Returns" stat button is not visible for dropshipped deliveries. ### Current behaviour: - The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor. - With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket. ### Expected behaviour: Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO). ### Fix: The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket Issue:https://github.com/odoo/enterprise/pull/81378 task-4881338 Forward-Port-Of: odoo/enterprise#91402
This update resolves an issue where the automatic checkout feature would fail when an employee had multiple overtime entries on the same day, particularly when one entry lacked a defined checkout time. The fix ensures that the system correctly calculates and applies checkout times, preventing validation errors related to excessive overtime durations.
Original PR description
__ ## Short functional explanation of the error When an employee has multiple overtimes for the same day, including one that doesn't have a check-out date. When running the scheduled action…
__ ## Short functional explanation of the error When an employee has multiple overtimes for the same day, including one that doesn't have a check-out date. When running the scheduled action `Attendance: Automatically check-out employees`, an error occurs: `odoo.exceptions.ValidationError: Duration must be positive and cannot exceed 24 hours.` ## Reproduction Steps 1. Create an employee. Set their timezone to UTC and the Overtime Ruleset to Default Ruleset in the settings tab. In the Payroll tab, set a contract start date. 2. Set their Working Hours to a fixed 40 hours/week. Set the timezone of the Working Schedule to UTC. 3. Go to attendances and create 2 attendances on a Sunday: one from 06:00 to 06:01 and a second that starts at 06:02 but that doesn't have a checkout date. 4. Go to Settings and enable Automatic Checkout. Leave the Tolerance to 2 hours. 5. Enable debug mode and go to Scheduled Actions. Look for `Attendance: Automatically check-out employees` and run it manually. ### Expected behavior As the tolerance is 2 hours, the second attendance check-out time should be set at 08:01. ### Unexpected behavior An error occurs: `odoo.exceptions.ValidationError: Duration must be positive and cannot exceed 24 hours.` ## Origin of the issue We retrieve overtime intervals with the domain: https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_version.py#L34-L42 This will make us retrieve all the overtimes for a given day, even if overtimes belong to different attendances. However, this means that we will retrieve several times the same overtimes, as this piece of code is executed in this context: https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_attendance.py#L35 https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_attendance.py#L43 This results in the generation of intervals containing multiple times the same overtimes. We then sum their duration to later create work entries: https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_attendance.py#L47 As we try to create a work entry with too much overtime, that exceeds 24 hours, it raises a validation error. Moreover, as the overtime hours are always stored in UTC, it makes sense to always keep the timezone as UTC when performing a `_read_group` . __ opw-6036064 Forward-Port-Of: odoo/enterprise#116194
This update resolves a crash issue that occurred when creating point-of-sale orders with the pos_avatax module installed. The fix re-enabled a previous method to correctly identify the customer's shipping information, ensuring order creation proceeds smoothly. This improves stability and prevents disruptions for users.
Original PR description
Before this commit, when pos_avatax was installed, creating a pos order could crash because the pos order does not have the partner_shipping_id field. This commit re-adds the _get_avatax_ship_to_partner method as it was before the refactor https://github.com/odoo/enterprise/commit/0404086db567ee0595414263d36a3b7dceaa0dbe, which returns the partner_id for the pos order. The `_get_avatax_ship_to_partner` is overridden in `pos_avatax`. Since a `pos.order` does not have a `partner_shipping_id`, the overridden function only reads the partner_id. opw-6122280 Forward-Port-Of: odoo/enterprise#116682 Forward-Port-Of: odoo/enterprise#115840
This update addresses a potential instability issue in the HR Payroll module by eliminating a specific coding pattern. This change enhances the overall reliability and stability of payroll processing, reducing the risk of errors. The update was prompted by related discussions and fixes within the Odoo core development team.
Original PR description
See odoo/odoo#260982 See odoo/upgrade#10028 See odoo/upgrade-util#419
This update simplifies how quality points are applied to products and product categories. Previously, users could apply points to multiple categories, but now they must select one. Leaving the field blank now applies the quality point to all products or all product categories, providing a clearer and more streamlined process.
Original PR description
Previously, quality points could apply to products, product categories or both. Now the user has to pick one of the two. Picking one of the two options but leaving the field empty means it applies to all products or all product categories. Task ID: 5380755
This update fixes a rendering issue within Odoo's reporting modules, specifically related to how text fields handle directionality. The change ensures that text fields consistently use the Unicode BiDi algorithm to determine text direction, preventing inconsistencies in reports. This improves the accuracy and visual quality of reports.
Original PR description
`IrQwebFieldText` now injects `dir="auto"` on every rendered element so the Unicode BiDi algorithm can detect the correct base direction from the first strong character, rather than having it overridden by ancestor CSS `direction: ltr`. Since the test verifies actual rendered HTML output, the expected strings must reflect the new attribute the framework now emits for all text widget fields. opw-5884712
This update removes a restriction that previously required Lazada products to be 'storable'. When stock synchronization with Lazada is disabled (as is common), tracking stock levels is unnecessary. This change now allows businesses to list all product types on Lazada, regardless of whether they require stock management.
Original PR description
Lazada items previously required products to be of type 'storable'. This restriction is unnecessary when stock synchronization is disabled, since no stock tracking is performed in that case. opw-6173986 Forward-Port-Of: odoo/enterprise#116833 Forward-Port-Of: odoo/enterprise#116543
This update resolves a test failure caused by an expired document range error when invoice dates are set to 2027 or later. The team applied a temporary fix – freezing the test's time – to ensure the tests pass and the core functionality remains stable. This prevents potential disruptions during development.
Original PR description
Problem: Tests are failing from a ValidationError, signaling that the document range expired, when the invoice date is 2027 and onwards. To resolve the bug, freeze_time needs to be applied on the tests. Related PR: https://github.com/odoo/enterprise/pull/112814 runbot-build-error-243527 Forward-Port-Of: odoo/enterprise#116099
Features or functions removed from Odoo
This update aligns the Enterprise version of Odoo with recent changes in the Community edition. Specifically, MRP-related information has been removed from product documents, resulting in clearer and more consistent displays for ECOs. This simplifies the user experience and reduces potential confusion.
Original PR description
In the community, we are removing the product document from the BOM view and also the MRP-related items from the product document, so we are adapting those changes to align the enterprise with the community code. ECOs now consistently show only product-related documents, improving clarity and avoiding confusion. task: 4593207 Community PR: odoo/odoo#200949