Daily updates from Odoo
Monday, November 17, 2025
11 changes · master
Resolved issues and error corrections
Regular users can now receive VoIP calls without the system crashing when contact details are matched to the call. The fix keeps call records protected from user tampering while allowing the application to update the linked contact safely.
Original PR description
In order to prevent users from tampering with their voip.call records, they aren't given direct write access to them. This leads to crashes in the get_contact_info function, which attempts to update the partner_id field of call records. This commit resolves the issue by switching to sudo mode for setting the partner_id. Forward-Port-Of: odoo/enterprise#99429
Fixed an issue where entering certain barcode values, especially URN-style codes, could cause the barcode scanning screen to fail. This improves reliability for warehouse and manufacturing users when manually entering or scanning barcodes.
Original PR description
This error occurs while entering the barcode number. Steps to reproduce: --- - Install `stock_barcode` module(without demo) - Setting > Barcode > Set Barcode Nomenclature = `Default GS1 Nomenclature`…
This error occurs while entering the barcode number. Steps to reproduce: --- - Install `stock_barcode` module(without demo) - Setting > Barcode > Set Barcode Nomenclature = `Default GS1 Nomenclature` - Barcode > click on `Scan or tap` > Enter a barcode(barcode number should startwith `urn` (eg: "urn:epc:tag:sgtin-96 : 3.0614141.038656.0")) > Apply Traceback: --- `KeyError: 'rule'` (with GS1 Nomenclature) `AttributeError: 'list' object has no attribute 'get'` (without GS1 Nomenclature) At [1], we expect the key `rule` to be present in the result, but this key is never set in the return statement at [2]. Since [1] also relies on the result’s type, a new key value `type` has been added in this [commit] to address that. This commit ensures that the correct keys are passed in the result dictionary. [1]- https://github.com/odoo/enterprise/blob/b001e9cc2af0f800e2a7965b61aa9b9c5bd4e89e/stock_barcode/controllers/stock_barcode.py#L29-L31 [2]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/barcodes/models/barcode_nomenclature.py#L174-L189 [commit]: https://github.com/odoo/odoo/commit/1394fa161a6fcf77b4443cbf784ad7dd635e7f9e#diff-be2a58d0591614180295c070396ff487f4bc04bf33aad2829d7bfab4671a792cR60 sentry-6992944243 Forward-Port-Of: odoo/enterprise#98761
French FEC imports now use less memory when matching imported records to existing partners. This helps companies with very large partner databases avoid import failures and complete the process more reliably.
Original PR description
### Description: When importing an FEC, Odoo will fetch all the partners to link the new imported records to the existing partners. The issue is that it triggers the prefetching of all the fields of the partners (304k partners in their case), causing a memory error. To avoid that, we can just fetch the field that we need (e.g. "name" and "ref"). ### Reference: opw-5153555 Forward-Port-Of: odoo/enterprise#98483
This fixes an issue where regular users could be blocked from signing a document because the system looked up the wrong user record. The signing flow tests now run as a regular user as well, helping catch permission problems that administrators would not see.
Original PR description
By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard. The issue is that, on the model `res.partner`, the field `user_id` is the…
By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard.
The issue is that, on the model `res.partner`, the field `user_id` is the Salesperson associated to this Contact, whereas the field `user_ids` contain the `res.users` that inherit this Contact, and `main_user_id` is the most appropriate User of `user_ids` when we need only one.
When testing as admin, all fields are the admin user, whereas when testing as Laurie Poiret (or any regular user), the Salesperson is still the admin while `main_user_id` is Laurie Poiret.
A regular user can access only its own `sign_signature` field, while an administrator can access the `sign_signature` of all users, so this bug remained undetected:
On a runbot, log in as `admin` to change the sales person of Marc Demo to Mitchel Admin, then log in as `demo` and click on "Sign Now" on the `Rental_Agreement.pdf` template.
You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.
Operation: read
User: 5
Groups: allowed for groups 'Role / Administrator'
Forward-Port-Of: odoo/enterprise#99408Helpdesk refunds now create credit notes for only the product chosen by the user, instead of including every product from the original sales order. Product selection is also narrowed to items related to the sales order, reducing mistakes and speeding up after-sales processing.
Original PR description
_ ## Short functional explanation of the error Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we…
_ ## Short functional explanation of the error Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund. Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO. ## Reproduction Steps 1. Create a SO containing 2 different products and confirm it. 2. Create a regular invoice and confirm. 3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams. 4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds". 5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned. 6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund. 7. Click on reverse. ### Expected behavior A credit note containing only the specified product to refund should be created. ### Unexpected behavior The created credit note contains both products originally present on the SO. ## Origin of the issue When issuing a refund from helpdesk_stock_account, this piece of code is called: https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17 which calls the ```reverse_moves``` method in the helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on. Finally, we arrive in the account_move.py file. In the ```_reverse_moves``` of this file, we can see the code: https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947 where we simply copy all the lines of the move in the SO without filtering them. As a result, we get the lines of the product we don't want to refund __ opw-5148789 Forward-Port-Of: odoo/enterprise#99477 Forward-Port-Of: odoo/enterprise#98771
Fixed an access problem that blocked non-admin users from creating Mexico Global Invoices. Regular accounting users can now complete the process and generate the required Global CFDI document without needing administrator permissions.
Original PR description
## Issue: When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised: `Sorry, you are not allowed to access this document` ## Cause: This commit change the…
## Issue: When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised: `Sorry, you are not allowed to access this document` ## Cause: This commit change the attachment creation to use the SUPERUSER: https://github.com/odoo/enterprise/pull/95197 However, updating `attachment.res_id` then required `base.group_system` access rights, preventing regular users from modifying the attachment As a result, non-admin users (like demo) triggered an access error during Global Invoice creation ## Steps to reproduce: - Switch to the MX company - Create a product with an UNSPSC Category (Accounting Tab) - Create and Confirm an Invoice for the product (enable CFDI to public) - Connect as Demo - Go in Accounting > Customers > Invoices - Toggle the last created invoice checkbox - Actions > Create Global Invoice - Before the fix, the Access Error is displayed - Check in the invoice Chatter for the Global CFDI document creation success opw-5181925 Forward-Port-Of: odoo/enterprise#98218
Archiving a company no longer causes access errors when users open the Documents app. The change ensures document folders are filtered to those the user is allowed to access, improving reliability in multi-company setups.
Original PR description
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it…
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it **Issue:** The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`: `folders = accessible_records.filtered(lambda d: d.type == 'folder')` This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched. **Fix:** Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere. For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows. opw-4931278 Forward-Port-Of: odoo/enterprise#99126 Forward-Port-Of: odoo/enterprise#96817
Mexican electronic invoices now report local fixed-amount taxes using the configured amount instead of multiplying it by 100. This prevents incorrect tax values in CFDI XML files and helps businesses issue compliant invoices.
Original PR description
Steps to reproduce: 1. With an MX Company setup configure a new tax as follows - Tax Computation: Fixed - SAT Tax Type: Local - Factor Type: Cuota - Amount: 5 2. Create a customer invoice with the tax 3. Generate CFDI Issue: In the XML the ImpuestosLocales node contains `<implocal:TrasladosLocales ImpLocTrasladado="VAT 0%" Importe="20.00" TasadeTraslado="500.00"/>` The tax fixed amount was multiplied by 100 This occurs because we don't check if the tax is fixed when normalizing the amount opw-5132807 Forward-Port-Of: odoo/enterprise#99431 Forward-Port-Of: odoo/enterprise#98988
Quick replace actions in the work entries Gantt view now show the proper error when users try to change validated entries. This prevents silent failures and makes it clear whether a validated entry cannot be modified or deleted.
Original PR description
Issue: Work entry quick replace buttons in gantt view didn't show error messages when trying to modify validated entries. The JavaScript was filtering out validated entries client-side and preventing server-side validation from triggering. Steps to Reproduce: - Open work entries gantt view - Select validated work entries - Click quick replace buttons (work entry type change) - No error message appears, operation silently fails Fixes: - Removed client-side filtering to allow all entries (including validated) to reach server validation - Added server-side check to distinguish modification vs deletion operations - Server now shows appropriate error message: "This work entry is validated. You can't modify it." for modifications vs "This work entry is validated. You can't delete it." for deletions Task ID: 5075615
This fix reverts a recent change that moved Belgium private car benefits into salary rules because that approach could not support required manual and folded benefit handling. Belgian payroll and salary package flows now use the previous field-based behavior, reducing the risk of incorrect or confusing car benefit calculations.
Original PR description
*: l10n_be_hr_contract_salary,l10n_be_hr_payroll,
l10n_be_hr_payroll_fleet,test_l10n_be_hr_payroll_account
In this PR, the migration of private car benefit from a field into a salary rule was reverted, since it caused issues because a salary rule cannot currently be folded or manual, since these are fields, and the salary rules currently don't allow that(salary rules depending on normal fields). In the future, when we have a structure for manual and fold salary rule for other salary rule, this might be readdressed. (Note: This might still not be possible, since other benefits that are fields have a manual on a field, and this benefit also needs this field as manual field/rule).
task-5236589Fixed an issue that could prevent active employees with valid contracts from showing in the pay run wizard, especially in newly created databases. This helps payroll teams prepare pay runs reliably without missing eligible employees.
Original PR description
Addressed the issue where employees were missing in the pay run wizard for new databases. Fixed _get_valid_version_ids to use self.env.company.id as a fallback when self.company_id is empty. task-5240136