Wednesday, July 15, 2026
9 changes · saas-19.2
Enhancements to existing features
The timesheet timer menu now opens with fewer delays by reusing already available information and avoiding unnecessary server calls. This makes daily time tracking feel quicker and smoother for employees, especially when the menu is opened often.
Original PR description
This PR removes some blocking RPC calls and caches information to make the loading of the systray as lightweight as possible. Changes include: - Move `field_get` to the lazy session info, so the field metadata is available client-side without a dedicated round-trip. - Cache the pre-filled form: it does not change as long as the task / project context stays the same, so it is computed once and reused. - Drop the `get_server_time` RPC and rely on the client-side clock. - Add a client-side systray cache service to avoid redundant requests. Task-6131386
Resolved issues and error corrections
The automated bank reconciliation process now gives failed items one more attempt before discarding them. This helps avoid losing reconciliation work when a temporary system issue, such as a database conflict, causes a first attempt to fail.
Original PR description
The auto reconcile cron drops the lines whenever they raise an error which is an issue for things like serialization errors. Now the code retries failed lines once before dropping them to make sure it's an issue with the lines. task-6273202 Forward-Port-Of: odoo/enterprise#119383
Features or functions removed from Odoo
This pull request reverses a recent change to Belgian salary contract mobility budget calculations. The update is being held back from this version so key users can validate it first in the main development version before it reaches this release line.
Original PR description
This reverts commit [692ecf81fe97d86d2f3196456dbb57ced90fe83c.](https://github.com/odoo/enterprise/pull/109845) Mobility budget should be done in master only to allow pre-testing by key users Task-6389002
Hong Kong IRD payroll reports now use the correct tax year based on an employee's start or leaving date. The change also ensures required departure reasons are included, helping companies avoid rejected IRD submissions during certification or filing.
Original PR description
As we now have complete support for IRD reports (in master), we started to try to get our system certified by the IRD.
A first submission highlighted a few issues that we are now fixing.
From 19.0:
- In IR56F, the RTN_ASS_YR should be the tax year in which the employee left the company. E.g. after april, the next year.
- In the same report, if the code for the cessation reason is 5 (other), the reason MUST be provided.
From 19.2:
- Same change has to be done when setting RTN_ASS_YR for IR56G
- A same change has to also be done for IR56E, based on the date the employee joined the company.
task-6332150
Forward-Port-Of: odoo/enterprise#124167
Forward-Port-Of: odoo/enterprise#121877This fix prevents the AI chat from crashing in screens where some action details are unavailable, such as Physical Inventory. Users can now ask AI questions from those views without hitting an error, improving reliability in day-to-day inventory workflows.
Original PR description
Steps to reproduce: ------------------------------------ 1. Go to Inventory>Operation> Physical Inventory. 2. Open the AI chat . 3. Ask the AI any question (e.g. Filtered entries with lot number 0005.). Observation: ------------------------------------ The AI request fails with the following error: RPC_ERROR 'NoneType' object has no attribute 'browse' Issue: ------------------------------------ When building the AI session context, the code assumes that `current_view_info` always contains an `action_id`. For this views, `action_id` is not present. As a result, `self.env.get(action.type)` returns `None`, and the subsequent call to `.browse()` raises a error, preventing the AI request from being processed. Solution: ------------------------------------ Validate that `action_id` exists and that the corresponding action record is valid before retrieving the current action and its search view. opw-6365175
This fix prevents the Belgian payroll app from failing during installation when required setup data is not loaded yet. It allows installations to continue normally on populated databases, reducing disruption for customers enabling the payroll module.
Original PR description
Currently during the installation process the compute is called before the data of the module is loaded. The compute uses a env.ref that searches for an external id that will only exist later on. this creates a traceback in populated databases, since the compute will be processed, and the app won't be installed. Here we cannot overwrite the auto_init since the field is not stored The only option left was to adapt the comupte to not throw a traceback in case the fields are not found, and instead proceed with the compute/installation opw-6340800
This fixes an issue where attendee emails could show an outdated event start date after a multi-day event was rescheduled. Event registration details now refresh correctly when event dates change, helping avoid confusing or incorrect communications to attendees.
Original PR description
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to…
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to attendee and Click on Send by Email Observation: ------------------------------------------------ The event start date displayed in the email body is not updated after the event dates are modified. Issue: ------------------------------------------------ In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58 However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f * `event_begin_date` is made stored for cohort view grouping * However, the base compute method only depends on `event_id` and `event_slot_id` https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180 * When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`) * Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work * Stored computed fields only recalculate when their explicit dependencies change Solution: ------------------------------------------------ * Corrected the dependencies of `_compute_event_begin_date` to recompute value on changing the date of the event opw-6284576 Forward-Port-Of: odoo/enterprise#120184
This update fixes an issue where online payments with cash rounding weren't calculating correctly. Now, when an order includes cash payments and cash rounding is enabled, the system accurately requests the correct online payment amount and properly marks the order as paid. This ensures accurate financial reporting and a smoother checkout experience for customers.
Original PR description
…nding When cash rounding is enabled with "Only for cash payment methods", an order partially paid in cash and completed with an online payment could neither request the correct online amount nor be…
…nding When cash rounding is enabled with "Only for cash payment methods", an order partially paid in cash and completed with an online payment could neither request the correct online amount nor be marked as paid. Steps to reproduce: - Enable cash rounding (e.g. 0.05, HALF-UP) with "Only for cash payment methods" - Create an order with a total of 15.28 - Add a cash payment of 10.00, then an online payment for the remainder The frontend requests 5.28 for the online payment, but as soon as the order contained a cash payment the server rounded the whole order total: get_and_set_online_payments_data() returned an unpaid amount of 5.30 (15.30 - 10.00), so the validation failed with "Invalid online payments". Even once the online payment of 5.28 was processed, the order remained stuck in draft with the money captured: _is_pos_order_paid() compared the paid amount (15.28) against the rounded total (15.30). Only the part of the order actually settled in cash must be rounded: non-cash payments (card, online, ...) always pay their exact share. - get_amount_unpaid() now returns the exact residual of the order when the rounding only applies to cash payment methods. - _get_rounded_amount() now only rounds the amount not covered by non-cash payments, resolving its old TODO. Cash-only orders and orders where the cash payment settles the rounded remainder are unaffected. opw-6314690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275305
This update resolves a crash in Point of Sale (PoS) when settling sales orders after archiving product attributes. Previously, archiving a product attribute alongside a sale order could cause an error. This change ensures PoS settlement remains stable and reliable, even when product attributes are archived.
Original PR description
When a product attribute line is used in a confirmed sale order, Odoo archives it (active=False) instead of deleting it when removed from the product template. If the corresponding product.attribute record is also archived, settling that sale order in PoS crashes with: TypeError: Cannot read properties of undefined (reading 'create_variant') opw-6315766 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274484 Forward-Port-Of: odoo/odoo#271778