Tuesday, March 3, 2026
7 changes · saas-18.3
Resolved issues and error corrections
This update corrects a minor issue in the Documents app where the action name displayed when creating account moves wasn't specific to the document type. Now, when creating a Vendor Bill from a document, the action name will correctly show as 'Vendor Bills', ensuring clarity and ease of use for users. This improves the overall user experience within the Documents app.
Original PR description
Previously, creating account moves from the Documents app opened the account.move list view with a static `Invoices` title, which was not explicit for all move types. Steps to reproduce: 1. Select suitable PDFs in Document App. 2. Click on `Vendor Bill`. 3. See the name of action (below Breadcrumbs) should be `Vendor Bills` instead of `Invoices` This fix adds and uses a mapping based on move_type to set the correct action name (e.g., Vendor Bills) after record creation. task-5983372 Forward-Port-Of: odoo/enterprise#109180
This update corrects a technical issue in the Hungarian tax audit export process. Previously, changes to invoice data were unintentionally saved to the database, despite attempts to roll them back. By ensuring data is flushed to the database before and after savepoints, this fix prevents incorrect data updates and maintains data integrity.
Original PR description
At the moment, the Hungarian tax audit export wizard's `action_export` creates a savepoint with `flush=False`. The intention of this savepoint is to roll back the changes to `l10n_hu_edi_invoice_chain` once the savepoint exits. But because the changes to `l10n_hu_edi_invoice_chain` stay in cache, and the cache is not flushed before the savepoint is created nor cleared afterwards, those changes end up being committed to DB. Which is precisely what the savepoint was there to prevent. Solution: we use `flush=True` to make sure the cache is flushed before and cleared after the savepoint. task-none Forward-Port-Of: odoo/odoo#251322 Forward-Port-Of: odoo/odoo#250971
This update resolves an issue where related fields within many2one chains were incorrectly displaying the wrong related model. Specifically, when creating chains with duplicate field names, the popover would show incorrect field options. This change ensures accurate field selection and improves the usability of many2one relationships.
Original PR description
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected. Steps to reproduce 1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b), model_b.x_studio_test(relation=other_model)`. 2. Create a related field on model_a and click the related icon for the test field. 3. The popover will now be displaying the fields for other_model instead of model_b. Cause: This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). Solution: Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`. opw-ticket 5459944
This update fixes a technical issue that caused a traceback when using the chatbot while the website editor was active. The fix ensures the necessary data fields are available in all Odoo contexts, preventing the error and improving stability. This resolves a potential disruption for users interacting with the chatbot.
Original PR description
Using a chatbot while the website editor is active triggers a traceback. The issue occurs because bus notifications containing `Chatbot` model data are also received by the backend bundle. In the backend bundle, the `Thread` model did not define the `chatbot` field, so the inverse thread relation on the `Chatbot` model could not be resolved, leading to a crash. This commit adds the chatbot field to the core bundle so it is available in all contexts and prevents the traceback. Steps to reproduce: - Goto localhost:8069/@/contactus - Start chatbot - Answer any question -> traceback task-5924295
A bug causing a division-by-zero error in the 'Split' wizard has been fixed. This issue occurred when the 'Max Batch Size' was set to zero, preventing users from correctly splitting manufacturing orders. This fix ensures the wizard functions reliably.
Original PR description
Steps to reproduce: - Install `mrp` module - Create a Manufacturing order - Server Action > Open the `Split` wizard - Set the `Max Batch Size` to `0` Traceback: `ZeroDivisionError: float division by zero` Backporting this [commit], as the error still exists in older versions. [commit]: https://github.com/odoo/odoo/pull/208275/changes/5546689200b7349754cf77bf4dbe7151315a3bfa
This update resolves an issue where the system was incorrectly checking user trust permissions on multiple records instead of a single one. This change ensures accurate authorization processes within the accounting modules, improving data integrity and security.
Original PR description
In some cases, the check was done on multiple records, though the method should be called on one and only one record. Forward-Port-Of: odoo/odoo#251589 Forward-Port-Of: odoo/odoo#251457
This update addresses a potential issue in the transmission of Swiss payroll data. Specifically, a warning message was previously displayed for negative AVS (Authorize Payment Verification System) scores, which could be misleading. This change ensures a standard warning level is used, improving the clarity and reliability of the reporting process.
Original PR description
Forward-Port-Of: odoo/enterprise#109046