Tuesday, May 12, 2026
8 changes · saas-18.4
Resolved issues and error corrections
This update corrects a UI issue where the `l10n_co_edi_ubl` field on the Units of Measure form was missing its label, causing confusion for users. The fix ensures the field is clearly labeled, improving form usability and data entry accuracy within the CO Company settings.
Original PR description
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. -…
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. - Navigate to Invoicing > Settings. - Enable `Units of Measure & Packagings`. - Open `Units & Packagings` and click `New`. **Observation:** The `l10n_co_edi_ubl` field appears between the `Quantity` label and its corresponding field, but its own label is not visible. <img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" /> **Root Cause:** The inherited view [1] inserts the field `l10n_co_edi_ubl` before `relative_factor` in the base view [2]. In the base view, `relative_factor` is wrapped inside a `<div>` with a shared label (`Quantity`). Since the new field is inserted inside this structure, it inherits the same layout without having its own label, resulting in the label being hidden. **Fix:** This commit updates the view to ensure that the field `l10n_co_edi_ubl` is properly displayed with its own label, avoiding UI confusion and improving form clarity. **After:** <img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" /> [1]: https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13 [2]: https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34 opw-6180769 Forward-Port-Of: odoo/enterprise#115933
The 'Waiting for Me' filter in the Sign app was previously fetching all documents instead of only those requiring the current user's signature. This update corrects a technical issue caused by an ORM optimization, ensuring the filter functions as intended, displaying only relevant documents for users to sign.
Original PR description
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature. Steps to reproduce: 1) Install…
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.
Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me
Observed Behavior:
All the documents are fetched.
Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.
Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown
From:
`('need_my_signature', '=', True)]`
To:
`[('need_my_signature', 'in', [True])]`
This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.
As a result, instead of filtering documents, all documents are returned.
[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108
[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177
Fix:
Corrected the return domain logic to fetch the correct documents.
opw-6026935
Forward-Port-Of: odoo/enterprise#113760This update fixes an issue where PDF Manager action names appeared awkwardly due to a styling class. The change removes this class, resulting in cleaner and more professional-looking action names within the PDF Manager interface. This improves the overall user experience.
Original PR description
Previously, pdf_manager actions used class "text-uppercase". Action names looked awkward. In this commit, we remove the class and properly display action names. task-6159317 Forward-Port-Of: odoo/enterprise#116382
This update fixes an issue where partners sharing the same VAT number, but with individual turnovers below €250, were incorrectly excluded from VAT reports. The change groups partners by VAT number and includes them in the report if their combined turnover exceeds the threshold, ensuring accurate reporting of VAT obligations.
Original PR description
When having different partners with the same vat number and their individual turnover values are less than the threshold they were not included in the partner vat listing report even though if the total turnover for their vat number is above the threshold. This commit handles this case by grouping by vat number and if the total turnover for a vat number is above the threshold then it will be shown in the report with another level beneath it to show the partners having this vat number even if their individual turnovers are below the threshold. task-6133010 Forward-Port-Of: odoo/enterprise#116495 Forward-Port-Of: odoo/enterprise#115251
This update fixes an issue where the project timesheet forecast report incorrectly included public holidays from other companies, leading to inaccurate planned hour calculations. The fix ensures that only public holidays related to the specific company creating the planning slot are considered, improving forecast accuracy and reporting.
Original PR description
## Steps to reproduce: - Install project_timesheet_forecast module - Create a public holiday in one company - In another company create a planning slot for an employee that overlaps with the holiday - Go to Timesheets/Planning analysis report - Notice the report is not showing planned hours for the employee on the day of the public holiday ## Cause: When filtering the resource_calendar_leaves we don't check for the company so any public holiday in any company will be taken into account even if it doesn't affect the employee ## Fix: Exclude holidays that has different company than the planning slot opw-5027070 Forward-Port-Of: odoo/enterprise#116263
This update fixes an issue where Swedish financial data from SIE files was being incorrectly imported due to encoding differences. The import process has been corrected to properly handle the Swedish characters, ensuring accurate data transfer for Swedish companies using the Enterprise system. This resolves a data discrepancy related to account numbers.
Original PR description
Issue: Non-ASCII charatcter from sie file were lost on import. Steps to reproduce: - in a Swedish company - import the SIE4 exemple file from sie website: https://sie.se/wp-content/uploads/2024/01/SIE4-Exempelfil-Sample-file-1.zip Current behavior: - The account 1090 is imported as "vriga imm anl tillg" instead of "Övriga imm anl tillg" Expected behavior: - The account 1090 is imported as "Övriga imm anl tillg" Cause: CP437 uses 8 bits to represent data. Ö is \x99. However, file was imported using either UTF-8 or ISO-8859-1, where Ö is \xC396 and \x99 doesn't link to anything. This commit update the test file as it was save in cp437 but read as UTF-8. opw-6167408 Forward-Port-Of: odoo/enterprise#116722
This update fixes an issue where importing changes to a sold subscription product bypassed a necessary warning. Now, when a product's subscription type is altered via import, a warning is automatically displayed, preventing unintended modifications to existing sales records. This ensures data integrity and prevents incorrect subscription settings.
Original PR description
__ ## Short functional explanation of the error When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription…
__ ## Short functional explanation of the error When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior: when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised. ## Reproduction Steps Make sure you have debug mode enabled. 1. Create a product, and check the Subscription box. 2. Click on Orders and create a Quotation with this product, then confirm. 3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export. 4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded. 5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes. 6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import. ### Expected behavior A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold. ### Unexpected behavior The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised. ## Origin of the issue Nothing prevents the import from occurring in that case. __ opw-6143789 Forward-Port-Of: odoo/enterprise#116922 Forward-Port-Of: odoo/enterprise#115046
This update fixes an issue where newly created stock batches were incorrectly named 'New' instead of following the standard 'BATCH/<TYPE>/000NN' naming convention. The fix ensures batches are correctly named, improving data consistency and reporting accuracy within the delivery order process.
Original PR description
Steps to reproduce 1. Open the Barcode app > Operations > Delivery Orders. 2. Switch to the "Batches" tab. 3. Create a new one. Issue The created batch keeps the placeholder name "New" instead of…
Steps to reproduce
1. Open the Barcode app > Operations > Delivery Orders.
2. Switch to the "Batches" tab.
3. Create a new one.
Issue
The created batch keeps the placeholder name "New" instead of being
renamed to `BATCH/<TYPE>/000NN`.
The barcode kanban "New" button calls `open_new_batch_picking`, which
runs `Batch.create({})` while the action context carries
`default_picking_type_id` set by `stock.picking.type._get_action` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock/models/stock_picking.py#L432.
Since `vals` itself doesn't carry `picking_type_id`, the lookup in
`stock.picking.batch.create()` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock_picking_batch/models/stock_picking_batch.py#L181
returns an empty recordset, so the sequence-based rename branch is
skipped and the name stays at the field default `'New'`. The
subsequent `super().create` then applies the context default, so the
batch is correctly linked to a picking type but with the wrong name.
opw-6168320