Thursday, November 13, 2025
5 changes · saas-18.4
Enhancements to existing features
This change prevents the system’s public user account from being deleted. It ensures the login page remains available and avoids a server error that could block access to the database.
Original PR description
Steps to Reproduce:
1. Create a database without installing the Website module.
2. Navigate to archived users and delete the "Public User."
3. Attempt to log in to the database from another browser or incognito
mode.
4. An internal server error occurs because the public user does not
exist, making the login page inaccessible.
Issue:
Previously, it was possible to delete the public user, leading to an
internal server error due to its absence, which prevented public access
to the login page.
Solution:
- Implemented a restriction to prevent the deletion of the public user,
similar to portal and default users.
- Added a test case to validate this functionality and ensure the
public user cannot be deleted.
task-4423568
Forward-Port-Of: odoo/odoo#233328
Forward-Port-Of: odoo/odoo#196918Account tags used for Belgium’s 281.50 reporting now include the country on the tag itself. This makes the tags easier to group and helps reuse them in other reporting cases when needed.
Original PR description
Account tags for 281.50 are specific to Belgium. With this PR, the country is added to those tags, allowing easier group by and enabling their use in other cases as well. task-5236632 Forward-Port-Of: odoo/enterprise#98759
If a payment gets stuck while waiting for a terminal response, the cashiers now see a "force done" option. This prevents the point of sale from being blocked and lets staff continue serving customers without waiting on the device.
Original PR description
If a payment line is stuck in a waiting state (e.g. payment terminal not responding to a request), we now display the "force done" button, to avoid blocking the user. Forward-Port-Of: odoo/odoo#235244
The work order completion process now avoids repeating the same checks and updates for every item, which reduces unnecessary database work. This makes finishing large batches of manufacturing work orders much faster and more reliable.
Original PR description
- The `button_finish` method contained a variable intended to filter out moves whose `operation_id` matched the `operation_id` of the entire recordset of work orders passed to the function. However,…
- The `button_finish` method contained a variable intended to filter out moves whose `operation_id` matched the `operation_id` of the entire recordset of work orders passed to the function. However, this filtering was performed inside a loop iterating over all work orders, even though the result of the filtration did not depend on any single work order. Before this commit: - The filtration was executed repeatedly for each work order, despite being deterministic. - This unnecessary repetition caused performance degradation and multiple redundant updates to the `picked` field of the same moves, resulting in fake or redundant database writes. After this commit: - The filtration logic has been moved outside the iteration, ensuring that the update to the moves is performed only once, improving overall performance and preventing redundant updates. - The `end_all` method is now executed on the entire recordset of work orders at once, instead of being called individually for each iteration. The benchmark below is done on a recordset of workorders of size **500** and the number of moves returned from the filter were **100**. It set the picked field to be **True** for every workorder in the recordset, potentially triggering recomputation of some of the fields and doing more redundant SQL queries. opw-5092636 ### Benchmark Results | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **Memory Error** | **After this Commit** | **22 seconds** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233102
This update clears the payment/blackbox processing queue whenever point of sale data is reloaded. It helps avoid rare situations where repeated queued calls could loop unexpectedly and impact the checkout flow.
Original PR description
This commit adds a clear of the blackbox queue when reloading data. This could avoid potential unexpected deadloop of calls in the queue. Forward-Port-Of: odoo/enterprise#99252