Daily updates from Odoo
Monday, December 1, 2025
20 changes · 18.0
Enhancements to existing features
This update replaces the specific "Uruware" name in the Odoo settings with a generic "UCFE Provider" label for the electronic invoicing provider. This ensures customers contact Odoo support for assistance and maintains a consistent configuration for Uruguayan users. The core functionality remains unchanged.
Original PR description
Before: -In the Settings > Uruguay Localization section, electronic invoicing provider was shown as "Uruware". -This could lead customers to contact Uruware directly instead of Odoo support. After: -Replaced all mentions of `Uruware` with generic name, `UCFE Provider`. -Updated labels and descriptions in both testing and production sections. -The overall configuration and functionality remain unchanged. Impact: -Removes direct provider references from the interface. -Ensures customers contact Odoo support for any assistance. -Keeps the configuration clear and consistent for Uruguayan users. task-5244539 Forward-Port-Of: odoo/enterprise#99065
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key data changes. A new feature has been added specifically for Belgium, leveraging the VAT number to streamline the Peppol identifier process through the company registry endpoint. This improves data accuracy and simplifies integration for Belgian businesses.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. task: 5172378
Resolved issues and error corrections
This update resolves an issue preventing MRP users from correctly validating manufacturing orders with project accounting. The fix ensures the system handles analytic account access properly, allowing users to assign serial numbers and complete work order validation without encountering access errors. This improves the efficiency of project costing and reporting.
Original PR description
Steps to reproduce: - Create a storable product with the following BoM: - Tracking: Serial number - Component “C1”: - Sales price: $10 - Cost: $20 - Operation: OP1 (60 min) - Add any analytic…
Steps to reproduce:
- Create a storable product with the following BoM:
- Tracking: Serial number
- Component “C1”:
- Sales price: $10
- Cost: $20
- Operation: OP1 (60 min)
- Add any analytic distribution
- Give the following access rights to Marc Demo:
- Manufacturing: User
- Timesheets: User
- Log in as Marc Demo
- Confirm the MO
- Start the work order
- Try to assign a new serial number using the "+" button
Problem:
```An access error is raised:
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Marc Demo (id=6) doesn't have 'write' access to:
Analytic Line (account.analytic.line)
```
Since the user has no access to analytic accounts, calling
`_prepare_analytic_lines()` attempts to modify an existing analytic line
amount, which triggers the access error.
Solution:
Because analytic lines are created using `sudo()`, we also need to
call `_prepare_analytic_lines()` with `sudo()` to avoid write-access
violations.
opw-5258044
Forward-Port-Of: odoo/odoo#237174This update resolves a bug that prevented the generation of SAFT files when journal entries lacked a partner but included receivable accounts. The fix ensures accurate SAFT export functionality, particularly for localized accounting systems like l10n_dk. This prevents export failures and maintains compliance.
Original PR description
If we try to export a SAF-T file when a line doesn't have any partner but having a receivable account, then a traceback is displayed.
(Backport of #98240)
How to reproduce?
1. Use a company with a localization using SAF-T (e.g. l10n_dk)
2. Create and post a journal entry with no partner, and with a line having a receivable account.
3. Go on the general ledger, and export in the SAF-T format
opw-5260937
Forward-Port-Of: odoo/enterprise#100296This update resolves an issue where duplicating an approver within an approval request caused a system error. The fix prevents the same user from being linked to multiple approvers, eliminating the traceback and ensuring approval requests function correctly. This improves stability and prevents disruptions to the approval workflow.
Original PR description
When User duplicates the approver for any approval request and tries to open that approval request, A traceback will appear. Steps to reproduce the error: - Activate the developer mode - Go to Approvals > Create a new approval request > add any approver > Save - Click on the ``View`` button in the approver line - Now, In the Form view > Actions > Duplicate - Go back to that approval request through breadcrumbs Traceback: ``` ValueError: Expected singleton: approval.approver(1, 3) ``` https://github.com/odoo/enterprise/blob/83b6c0e1c052b08bd23c5e009773b5a3148ddeec/approvals/models/approval_request.py#L270 When the customer duplicates the approver, ``user_id`` will be also duplicated. So, Now Same User is linked with multiple approver. So, It will lead to the above traceback. sentry-6642840799
This update resolves an issue preventing payroll officers from accessing salary offer details. The fix prevents access errors when officers attempt to view offers, ensuring they can continue generating salaries without needing recruitment permissions. This improves workflow efficiency for the payroll team.
Original PR description
steps to reproduce: - Install l10n_be_hr_contract_salary - Log in as a payroll officer (without recruitment rights) - Go to Payroll > Contracts > Offers - Open any offer - Notice an 'Access Error' appears: You are not allowed to access 'Candidate' (hr.candidate) records. cause: The module tries to read `employee_id.candidate_id.partner_id` in offer computations. Since payroll officers lack recruitment rights accessing `hr.candidate` triggers an access error. fix: Wrap candidate access in try/except to handle missing permissions. - If accessible, candidate partner data is used as before. - If not accessible, skip without raising an error. This allows payroll officers to open and generate salary offers without requiring recruitment rights. task - 5039712
This update fixes a bug where changes to spreadsheet sale inputs were unexpectedly lost due to system updates or user actions. Now, changes made to the input are reliably saved, ensuring data accuracy and a smoother user experience. This resolves a previous issue impacting data consistency.
Original PR description
Currently, the FieldSync record input suffers from two issues: 1) The input value can be reset by parasitic renders While the user is inputting a value, if they did not confirm it and a global render occurs (other user joining the session, dragging the mouse on the grid), the input value will be reset to the one stored in the plugin, therefore erasing the last change of the user 2) In Chrome-based navigators, users can change the value of the input by using their mouse scrolling wheel. Such action *does not* trigger an `onChange` event; which means that the new value is never directly saved. Both issues are addressed in this commit by keeping an internal state inside the component `FieldSyncSidePanel` and ensure this state is properly reflected in the plugin once we stop editing the input. Task-5123069
This update resolves an issue where the Odoo shell command wouldn't consistently start due to problems with imported tools. Specifically, the `hw_drivers` module caused errors when not actively used. This change ensures the Odoo shell starts reliably, improving developer workflow and command execution.
Original PR description
Description of the issue/feature this PR addresses: Not all tools imported in addons that have a `cli` directory may be installed on the system when that module is not used. Importing it will result in errors such as missing modules. In case of `hw_drivers`, there are hardcoded paths for the iot box. Current behavior before PR: Failing to start `odoo-bin shell` because of hw_drivers code. Desired behavior after PR is merged: Start commands. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231151
This update resolves an issue preventing MRP users (like those with Timesheet access) from correctly validating manufacturing orders. The fix ensures the system properly handles analytic account access when creating serial numbers, preventing access errors and allowing for accurate order management. This improves the usability of the manufacturing process for a wider range of users.
Original PR description
Steps to reproduce: - Create a storable product with the following BoM: - Tracking: Serial number - Component “C1”: - Sales price: $10 - Cost: $20 - Operation: OP1 (60 min) - Add any analytic…
Steps to reproduce:
- Create a storable product with the following BoM:
- Tracking: Serial number
- Component “C1”:
- Sales price: $10
- Cost: $20
- Operation: OP1 (60 min)
- Add any analytic distribution
- Give the following access rights to Marc Demo:
- Manufacturing: User
- Timesheets: User
- Log in as Marc Demo
- Confirm the MO
- Start the work order
- Try to assign a new serial number using the "+" button
Problem:
```An access error is raised:
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Marc Demo (id=6) doesn't have 'write' access to:
Analytic Line (account.analytic.line)
```
Since the user has no access to analytic accounts, calling
`_prepare_analytic_lines()` attempts to modify an existing analytic line
amount, which triggers the access error.
Solution:
Because analytic lines are created using `sudo()`, we also need to
call `_prepare_analytic_lines()` with `sudo()` to avoid write-access
violations.
opw-5258044
Forward-Port-Of: odoo/enterprise#100476This update corrects a bug where discounts from purchase orders were incorrectly being added to sale orders during import. The change ensures sale orders always reflect a discount of 0, aligning with expected business logic. A new check has been implemented to prevent this issue in future versions.
Original PR description
Discounts are always sent by `_retrieve_line_vals` in `account_edi_ubl_cii` In Sale orders, discounts aren't expected to be automatically imported from the purchase order, it should always be 0. `test_so_import_product_from_po` didn't use to fail because discount wasn't checked until the recent refactor https://github.com/odoo/odoo/pull/190310 Check was added in 18.0 to avoid this error in the future. Steps to reproduce: - Disable discount in sale app - Create a PO with a discount on any POL - Enable discounts - Import SO from PO Issue: Discount is added to the Sale order lines. Runbot: 232724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a critical issue that caused the generation of payroll export files to fail. The fix corrects a naming discrepancy in the code, ensuring accurate retrieval of employee data. A new test suite has been implemented to guarantee the reliability of the export process.
Original PR description
The export generation crashed due to a mismatch between field names — the code was referencing employee_ids, while the model actually defines employee_id. Since the Prisma code is now stored on the employee model, the logic was updated to correctly access the employee_id field and retrieve the related Prisma code. Additionally, a comprehensive test suite was added to validate Prisma code behavior, including: - validation of code length for employees, companies, and work entry types, - handling of codes across different companies, - and the complete Prisma export flow (from work entry creation and validation to export file generation). task-5153727
This update optimizes how Odoo calculates mobility budgets for Belgian HR contracts. By switching to a more efficient 'binary search' method, the calculation process is now significantly faster, particularly for larger datasets. This results in quicker reporting and improved system performance.
Original PR description
- optimized the method `_compute_l10n_be_mobility_budget_amount` to use binary search instead of linear loop task-id: 5173389
This fix resolves an issue where stock valuations were incorrect after splitting a purchase order receipt into a batch and validating the batch. The problem stemmed from how the system calculated values during batch validation, leading to miscalculated stock values. This update ensures accurate stock valuations are generated when using batch billing.
Original PR description
…n batch billed on ordered qty **Problem:** When the picking of a purchase order (of a product billed on ordered quantity) is split into different moves and put in a batch, at batch validation, svls…
…n batch billed on ordered qty
**Problem:**
When the picking of a purchase order (of a product billed on ordered quantity) is split into different
moves and put in a batch, at batch validation, svls are created with the wrong values.
**Steps to reproduce:**
- enable "Batch, Wave & Cluster Transfers" settings
- create a storable product with a standard price of 1
- set the category as avco
- in the Purchase tab select the control policy as
"on ordered quantities"
- create and confirm a purchase order for 50 of this product
- on the Receipt, change the quantity to 20 and split the
picking
- go back the the PO and create and confirm a bill for
the full amount
- click on the receipt smart button
- select the two pickings and then the 'Action' button
- select add to batch
- check 'new batch transfer' and confirm
- open the batch and validate it
- open stock valuation
**Current behavior:**
the newly created svls have total values of
50 and 50.10
**Expected behavior:**
it should be 20 and 30
**Cause of the issue:**
When the batch is validated, _action_done is called
on the two stock moves.
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/stock/models/stock_picking.py#L1258
In the stock_account override:
- first the super method is called
As a consequence the state of the two moves becomes 'done'
and the qty_received of the linked purchase order line becomes 50.
- then product_price_update_before_done is called before creating
the svls.
Inside product_price_update_before_done we call _get_price_unit.
In the purchase_stock override of _get_price_unit :
- because the super method of action_done was already called,
qty_received of the purchase order line is 50, so _get_qty_received_without_self
will return 30.
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L50
So received_qty is 30 and later remaining_qty will be 20
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L86
- but because no svl was created yet receipt_value will stay 0 and later
remaining_value will be 50
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L55-L63
Therefore price_unit will be 2.5 (50/20) instead of 1
**fix**
We do not take into account the move(s) of the
same batch in the remaining value (because svls are not created yet)
so we should not take them into account in the remaining quantity.
opw-5179581This update resolves an issue where Sale Orders with lot-tracked products were incorrectly duplicated during import into POS. The fix prevents unnecessary line splits based on unit of measure, ensuring accurate order processing and avoiding data inconsistencies. This improves the reliability of the POS system when handling lot-based inventory.
Original PR description
## Issue: After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines ## Cause: In the…
## Issue: After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines ## Cause: In the `settleSO` function, the line is first split because the UoM differs and is not `pos_groupable` Among the default UoMs, only Units, Pack of 6, and Dozen have `is_pos_groupable` = True, meaning most other UoMs will trigger a line split After duplicating the line due to the UoM split, an additional line is then added for each lot to link, causing duplicate entries in the POS order ## Steps to reproduce: - In Settings, enable Lots & Serial Numbers and Units of Measure & Packagings - Create a Product (Tracking: Lot, Sale Unit: g) - Update the Quantity On Hand (Lot: "LOT", Quantity: 5) - Create and confirm a Sale Order for the product (Quantity: 2) - Open POS and import the SO - Before the fix, there is 3 lines (2x no lots, 1x with lot + qty 2 ## Other issues: - The discount was not imported on the lot lines - Some lines were missing when importing lines where part of the quantity had no available lot - (This fix was already made in PR: https://github.com/odoo/odoo/pull/229075/files but was not forward-ported) opw-5018295
This update reverts recent changes to the event sale report that were causing database compatibility problems. The fix previously intended to include PoS-sold tickets, but this resulted in errors for some Odoo databases. This reversion ensures stability and continued functionality of the event sale reporting feature.
Original PR description
This recent commit is causing dependencies issues in some Odoo database that rely on the pos_event_sale module. To maintain stability and ensure compatibility, reverting the recent changes made to the event sale reports and related files. Original commit: https://github.com/odoo/odoo/pull/226544/commits/e968ff178a0f0d11949dfac67b98e1b8acf771b0 Add event registration sold through PoS to the event sale report. Steps to reproduce: ------------------- * Create an event with tickets * Sell a ticket through the PoS * Go to the event sale report > Observation: The ticket sold through PoS is not included in the report Why the fix: ------------ We modify the SQL query of the event sale report to include event registrations sold through PoS. We also make sure to remove duplicates from the original query. opw-4935195
This update resolves an issue where the 'I agree' button on the website's cookie bar stopped working when its font size was adjusted. The fix corrects a coding error that prevented the button from correctly triggering the cookie acceptance process, ensuring the cookie bar remains functional across different font size settings.
Original PR description
The "I agree" button in the cookie bar would stop working if its font size was changed. Steps to reproduce: =================== - Enable the cookie bar in website settings. - Go to the website and…
The "I agree" button in the cookie bar would stop working if its font size was changed.
Steps to reproduce:
===================
- Enable the cookie bar in website settings.
- Go to the website and enter Edit mode.
- Click on the cookie bar.
- Select the "I agree" button's text and change its font size.
- Save and visit the page as a guest (e.g., in a private window).
- Click on the "I agree" button text.
-> The maps doesn't show and the Cookie bar disappear.
Cause:
======
Applying a font size to the button's text wraps that text within a `<span>` element.
The event listener for accepting cookies is attached to the elements with IDs `#cookies-consent-essential` and `#cookies-consent-all`. in that case it ID `cookies-consent-essential` exist in the parent element. However, the code was checking the ID of `event.target`. When a user clicks directly on the newly created
`<span>`, `event.target` refers to the `<span>` itself, not the element who owns the event.
Since the `<span>` does not have the required ID ('cookies-consent-all'), the condition to accept the cookies was false.
Solution:
=========
Use `event.currentTarget` instead of `event.target`.
Unlike `event.target`, `event.currentTarget` always refers to the element to which the event handler was attached—in.
check:
https://developer.mozilla.org/en-US/docs/Web/API/Event/currentTarget
opw-5004645
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an installation issue with the l10n_AR module caused by a Python 3.10 compatibility problem. The demo data used a syntax that's no longer valid in Python 3.10, preventing successful installation. This fix ensures the demo data functions correctly with the latest Python version.
Original PR description
**Steps to reproduce:**
- Use Python 3.10
- Install l10n_ar
**Issue:**
The installation fails with a SyntaxError.
**Cause:**
Some demo data use the following format for the taxes definition:
`ref(f'account.{ref('base.company_ri')}_ri_tax_vat_0_compras')`
However, in python 3.10, a quote cannot be used inside f''.
opw-5376152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects a bug where credit notes weren't automatically generating deferred revenue entries. The system was incorrectly using a setting designed for invoices. Now, credit notes will correctly create deferred revenue entries when configured to 'On bill validation', ensuring accurate accounting for deferrals.
Original PR description
The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do. As a result, deferred entries for credit notes are not created when expected. Steps to reproduce: - Go to Accounting → Configuration → Settings. - In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped - In the Deferred Revenue Entries section, set Generate entries to: On bill validation - Navigate to Accounting → Customers → Credit Notes. - Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line). - Validate the credit note. - No deferred revenue entries are created. Ticket [link](https://www.odoo.com/odoo/project.task/5187051) opw-5187051 Forward-Port-Of: odoo/enterprise#100211
This update fixes a technical issue that prevented the 'fuel_type' field in employee contracts from being properly translated. By changing how the field's options are defined, this update ensures all translations are correctly displayed, improving the user experience for our Belgian customers.
Original PR description
The selection field `fuel_type` in the `hr.contract` model was not properly translatable, because it used a function yielding static strings for the options. This commit changes the field to use the variable directly, allowing them to be translated. Forward-Port-Of: odoo/enterprise#100748
This update fixes an issue where short feedback messages were incorrectly wrapping the last word, creating a messy layout. The change ensures that feedback messages display cleanly, especially when combined with the rating image, resulting in a better user experience. This backport addresses a minor visual inconsistency.
Original PR description
**Current behavior before PR:** - Short feedback wraps the last word unnecessary.  **Desired behavior after PR is merged:** - Short messages wrapped unnecessarily due to block-level element conflicting with floated rating image. This fix ensures cleaner inline layout.  Backport of this: [Commit](https://github.com/odoo/odoo/commit/52a1913ea7082655009c9eca1201c8c42e4e4037) task-[4788428](https://www.odoo.com/odoo/project/1519/tasks/4788428) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215577