Tuesday, August 4, 2026
10 changes · saas-19.4
Enhancements to existing features
The Timesheet Timeline view now shows assistant suggestions in true chronological order instead of sorting them by title. It also displays each suggestion's start time, making it easier for users to review and enter timesheets accurately.
Original PR description
Forward-Port-Of: odoo/enterprise#125574 Forward-Port-Of: odoo/enterprise#122862
Payroll batch processing has been optimized by removing unnecessary work entry generation and reducing repeated processing during payslip calculations. This should make large payroll runs noticeably faster, especially when computing many payslips at once.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/124776 without the populate blueprint. Forward-Port-Of: odoo/enterprise#126561 Forward-Port-Of: odoo/enterprise#125288
Resolved issues and error corrections
This fix updates Belgian hospitality payroll so CP302 eco-vouchers are prorated according to the correct full-time and part-time rules. It helps ensure employees receive the right voucher amount when they work part of the year, work part-time, or have unpaid absences.
Original PR description
Per the CP302 rules:
- Full-time, incomplete year: 250 × complete_months/12 + 250 × working_days/divisor for any partial month at start/end.
- Part-time: 250 × working_days/divisor. Days are counted as-is ("each daily service = 1 day regardless of duration"), so work_time_rate is not applied to the day count.
- Divisor: 260 (5-day week) or 312 (6-day week).
- Working days use `get_work_duration_data(compute_leaves=False)` so public holidays stay assimilated; only unpaid absences are deducted.
task-6375105
Forward-Port-Of: odoo/enterprise#124297Quotations created from repair orders linked to helpdesk tickets now correctly use the salesperson assigned to the customer. This prevents sales ownership from being left blank, helping teams keep follow-up and reporting accurate.
Original PR description
Currently, when a quotation is created from a repair order generated from a helpdesk ticket, the salesperson is not set on the quotation even if the customer has a salesperson assigned. **Steps to…
Currently, when a quotation is created from a repair order generated from a helpdesk ticket, the salesperson is not set on the quotation even if the customer has a salesperson assigned. **Steps to Reproduce:** - Install `helpdesk_repair`. - Go to `Helpdesk` > `Configuration` > `Helpdesk Teams`. - Open a team recod and enable `Repairs`. - Create a `contact/customer` with a `salesperson` assigned. - Go to `Helpdesk`, create a ticket for that `customer`, and select the `helpdesk team` configured above. - Click `Repair`, then click `Create Quotation`. - Open the quotation and check the `Salesperson` field in the `Other Info` tab. **Current behavior:** The Salesperson field on the quotation remains empty. **Expected behavior:** The Salesperson field on the quotation should inherit the salesperson assigned to the selected customer/contact. **Cause of the issue:** When a repair order is created from a helpdesk ticket, default_user_id [1] is passed in the context . This value is propagated when creating the repair order [2] . Later, when creating the quotation from the repair order [3], the same context is reused. Because default_user_id is already present in the context, it overrides the precomputation of user_id from the customer. As a result, user_id is initialized with an empty value and remains unset. **Fix:** This commit ensures that default_user_id is removed from the context before creating the sale order. Without a default value for user_id, the field is correctly precomputed from the selected customer, and the salesperson is properly assigned. [1]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L52 [2]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L36-L40 [3]: https://github.com/odoo/odoo/blob/29328b8fccff833c14de317b51f3b4e5a8c40f75/addons/repair/models/repair.py#L357 opw-6344939 Forward-Port-Of: odoo/enterprise#126310 Forward-Port-Of: odoo/enterprise#122980
Non-admin CRM users can once again create leads from business card pictures when the related feature is available. The change fixes an overly restrictive dropdown permission check while still showing access messages when users lack rights for actions tied to a specific model.
Original PR description
**Steps to reproduce:** - Go to CRM app as an internal user (non-admin) - Click on Generate button - Can't create leads from business card pictures - Only setting the user as admin enables it (was…
**Steps to reproduce:** - Go to CRM app as an internal user (non-admin) - Click on Generate button - Can't create leads from business card pictures - Only setting the user as admin enables it (was working fine in previous versions) **Issue:** Dropdown action is restricted to admin only by default using `hasAccess`. If there is a corresponding model on the `LeadGenerationDropdown` it is later changed according to the current user access rights using `await user.checkAccessRight(model, "create")`. **Fix:** Default `hasAccess` to `True` as there is no related model for the lead generation of business cards. (Note: could also provide the missing model ?) - Installation should be restricted to the admin. - Access message should be shown to the user if he doesn't have enough rights to the related model. - Non-admin users should be able to use the feature if no model is provided and the related app is available. dropdown: https://github.com/odoo/odoo/commit/978019522746ccb971eeb15c5d9530e438b7d2f3 business card: https://github.com/odoo/enterprise/commit/48a9cba24cb51b11a08dd9c0ff1291e15232260f opw-6258689 Forward-Port-Of: odoo/enterprise#121682
The cart now prevents customers from increasing rental product quantities beyond what is available for the selected rental dates. Availability is also rechecked when rental dates are changed, helping avoid overbooking planned service resources.
Original PR description
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning…
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. Add as much product "test" to the cart as possible (the quantity is limited) 7. Open the cart 8. You can increase the amount of the product regardless of its availability Issue: We don't check the renting availabilities to limit the maximum quantity of the product Solution: Check that the new quantity of the product is available in `_verify_updated_quantity` for the specified dates. We also need to check the availability of the product when we modify the rental dates opw-6274035 Forward-Port-Of: odoo/enterprise#126275 Forward-Port-Of: odoo/enterprise#123056
Preparation ticket printing for Belgian self-order point of sale now uses the OBOX device instead of the point-of-sale terminal. This fixes the printing flow so tickets are handled by the compliant blackbox setup, reducing operational issues for affected restaurants and shops.
Original PR description
Impression of preparation ticket are now handled via the OBOX instead of the PoS terminal. See https://github.com/odoo/enterprise/pull/125348 Forward-Port-Of: odoo/enterprise#126611
Preparation tickets and receipts now load the styling and information they need after the receipt printing refactor. This restores the expected printed layout, brings back missing receipt data such as customer notes, and improves the point-of-sale customer and kitchen workflow.
Original PR description
..., pos_restaurant, pos_self_order, pos_urban_piper --- During the refactor of the receipt printing system, some CSS classes were no longer loaded with preparation tickets. As a result, preparation tickets lost part of their original styling. To restore the expected rendering, ensure all required classes are properly loaded while keeping the loading minimal. Additionally, some receipt data were missing after the refactor and some UI elements could be improved. This commit restores the missing data and improves the overall UI. It also fixes an issue where customer notes were not printed on the receipt. Templates checked: * point_of_sale.pos_order_change_receipt * point_of_sale.pos_order_change_receipt_line --- Task: https://www.odoo.com/odoo/project/1737/tasks/6133403 Refacto: https://github.com/odoo/odoo/pull/244395 Forward-Port-Of: odoo/enterprise#124603 Forward-Port-Of: odoo/enterprise#118782
This fixes how Indian localization reports classify transaction types for POS and other non-purchase entries. Existing databases are updated so prior records use the corrected classification, improving report accuracy.
Original PR description
Description: In #118297 non-sales journal moves were considered purchase moves during l10n_in_transaction_type computation, which is not correct for POS moves as their journal is of type 'general'. Fix: Compare only the purchase journal moves state against the partner state. Other moves treated as sales and their state compared against the company state. Add a migration script to update existing databases. opw-638646 Forward-Port-Of: odoo/enterprise#125697
Restaurant orders using German Fiskaly certification now send the first added item to the Kitchen Display immediately. This prevents kitchen staff from missing new orders until a second item is added, improving order visibility and service flow.
Original PR description
**Step To Reproduce:** 1. Configure a POS with German Fiskaly (l10n_de_pos_cert), Restaurant, and Kitchen Display (pos_preparation_display). 2. Create a new order in the POS and add the first…
**Step To Reproduce:** 1. Configure a POS with German Fiskaly (l10n_de_pos_cert), Restaurant, and Kitchen Display (pos_preparation_display). 2. Create a new order in the POS and add the first product. 3. Observe that the order does not appear on the Kitchen Display. 4. Add a second product to the same order. 5. Observe that the order now appears on the Kitchen Display. **Issue:** The first product of a new restaurant order is not synchronised with the Kitchen Display when the German Fiskaly localisation is enabled. **Reason:** `syncAllOrders()` only processes orders returned by `getPendingOrder()` and ignores orders explicitly passed through `options.orders`. After the initial Fiskaly synchronisation, the order is serialised and removed from the pending queue. Consequently, the Preparation Display synchronisation receives no orders from `getPendingOrder()`, preventing the order from reaching the backend. **Solution:** Update `syncAllOrders()` to prioritize the orders explicitly provided through `options.orders`. When `options.orders` is not available, fall back to the existing behavior by synchronizing the orders from `orderToCreate` and `orderToUpdate`. opw-6321376 Forward-Port-Of: odoo/enterprise#125743