Saturday, June 27, 2026
5 changes · saas-19.3
Enhancements to existing features
The Point of Sale has been updated to support the new Belgian blackbox v2 requirements. This mostly restructures internal POS flows so local Belgian rules can control payment, cashier, receipt, and order-synchronization behavior without disrupting standard use.
Original PR description
Note: this PR is a forward of https://github.com/odoo/odoo/pull/229692 Refactor several POS core methods into overridable hooks so that l10n_be_pos_blackbox (v2) can intercept and extend critical…
Note: this PR is a forward of https://github.com/odoo/odoo/pull/229692 Refactor several POS core methods into overridable hooks so that l10n_be_pos_blackbox (v2) can intercept and extend critical flows to implement the new blackbox requirements. point_of_sale: - pos_store.js: extract posBackOnline(), openCashbox(), getSelfOrderToPrint(), and resetCashier() as dedicated methods; setCashier() now returns a boolean; preSyncAllOrders() now returns the orders array, and the sync loop skips an order when it returns falsy (allows blackbox to block premature syncing); add orderReceiptComponent class property so the receipt component can be substituted by submodules. - order_payment_validation.js: extract canPrintReceipt getter (makes it overridable); fix absolute import path for error_handlers; fix typo "occured" → "occurred". - pos_session.py: load product.template / product.product before account.tax in _load_pos_data_models to satisfy the blackbox data dependency order; include account_move id in the invoice list returned by the session sales-details report. pos_hr: - Split setCashier() into setCashier() + setCashierUpdateSession() so the session-update side-effect can be called independently by the blackbox during clock-in/out flows. Return true from setCashier() consistently with the base method. pos_loyalty: - Override displayPrice on order lines so gift-card trigger products always display a positive price, even when the order is a refund. pos_restaurant: - Refactor mergeOrders() into _mergeOrders() + _mergeLines() private helpers; add getLinesToMerge() hook so blackbox can filter which lines participate in a merge; mergeOrders() now returns the destination order; extract syncRestoredOrders() for overridability; replace the while-loop-with-guard-counter with a plain for-of loop. pos_self_order: - Add orderReceiptComponent property; extract handleKioskSessionStatusChange() so the kiosk status-change behaviour can be overridden by the blackbox self-order bridge. enterprise PR: https://github.com/odoo/enterprise/pull/121799 task-id: 5864870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This change fixes an access issue that could block database users from synchronizing their databases. It ensures the correct permission check is applied so the process completes without unnecessary errors.
Original PR description
The aim of this commit is to allow the databases_user to synchronize their databases. Context: The commit https://github.com/odoo/odoo/commit/846eb51a02baaf2e4f6e6780f8d0ceb23322c38b introduced a change of behavior in stable that performs some more check on access rights. Before this commit: The checks introduced by the commit resulted in an access error. There wasn't any groups on the action itself resulting in a check of the access right "write" on the model. As the model is `project.project` and a databases_user might not be granted write access on the project itself, it resulted in an access error. After this commit: The flow continues smoothly. As the action has now a group set on it, this is checked first and match the proper access right. opw-6329058 Forward-Port-Of: odoo/enterprise#121589
This update prevents a traceback that could appear when users open a billing target in Timesheets. It ensures the required leave information is available so the screen opens correctly and the billing rate indicators continue to work as expected.
Original PR description
Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `leave_date_to` and `current_leave_id` field, change made from odoo/odoo@0496ed1 and https://github.com/odoo/odoo/commit/4b5089694436aa00254666e10cd2106b21adfe2b - Thus unavailability of field causing the traceback. Fix: - Add a related field for leave_date_to from which we get the value. Forward-Port-Of: odoo/enterprise#121888 Forward-Port-Of: odoo/enterprise#121571
This update makes sure amounts sent to Cashmatic payment machines are always calculated using a fixed 100-cent unit. It prevents mismatches with currencies that do not follow the machine’s expected decimal handling, helping payments be processed correctly.
Original PR description
Despite its API description, the Cashmatic machine always operates with 2 decimal places regardless of the currency. According to the Cashmatic head developer, only 2-decimal currencies are supported, with the sole exception of Chilean Peso (CLP) which has no decimals but is still handled with a fixed 100 cents-per-unit factor. Replace `Math.pow(10, currency.decimal_places)` with a `CENTS_PER_UNIT` constant set to 100 to make this assumption explicit. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272465
Subscription reports now exclude non-recurring products when calculating recurring revenue totals such as MRR and YRR. This prevents inflated figures if someone removes the default recurring filter in the reporting view.
Original PR description
While investigating a support ticket, we noticed that in subscription reports, recurring revenue values (MRR and YRR) are implicitly calculated for non-recurring products. This doesn't cause a direct problem when using the default search domains applied in Subscription > Reporting > Subscription > Pivot view, because a "Recurring" filter is pre-applied. But if the end user removes said filter, they might accidentally fudge the MRR and YRR numbers because the non-recurring products will contributed to the relevant grouping sums. We fix this by adding a CASE clause to explicitly ignore non-recurring products when calculating the report field for MRR and YRR , i.e. only consider `t.recurring_invoice = TRUE`. OPW-6315091 Forward-Port-Of: odoo/enterprise#121566