Friday, January 16, 2026
14 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing a document from a record they couldn't access. The fix ensures the system verifies read access to the related record before redirecting, improving the signing process for all users.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#104161 Forward-Port-Of: odoo/enterprise#100961
A customer modified their ‘Gift Card’ and ‘E-Wallet’ products to use them as stock items. This created an inventory inconsistency. This fix prevents these products from being automatically converted back to service-type products, resolving the issue and ensuring accurate stock counts.
Original PR description
The customer changed the service-type products “Gift Card” and “E-Wallet” to storable products and used them in stock. May be they could use as physical gift cards, and physical e-wallets for company. As a result, these products now have on-hand quantities, which creates an issue. After the upgrade, they will be converted back to service-type products, causing an on-hand quantity inconsistency in the test case. To avoid this error, we need to keep these products as storable. TO do that we have to mark them noupdate. This is a customer-specific change, but since we have received many similar requests, we should consider making a generic fix if possible. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242555 Forward-Port-Of: odoo/odoo#237517
This update corrects a bug in how the system determines if a stock location is a child of another. The fix replaces a potentially misleading comparison with a more reliable check, preventing errors in location-based processes. This ensures accurate stock management and avoids potential disruptions to workflows.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update fixes an issue that occurred when users deleted combo choices linked to products and then attempted to load sample data in the Furniture Point of Sale (PoS). The change prevents a parsing error that would block the demo data from loading, ensuring a smooth experience for users.
Original PR description
When combo choices associated with products are deleted and the user attempts to load sample data in the Furniture PoS, a traceback occurs. Steps to reproduce the error: - Install ``point_of_sale``…
When combo choices associated with products are deleted and the user attempts to load sample data in the Furniture PoS, a traceback occurs. Steps to reproduce the error: - Install ``point_of_sale`` module without demo data - Go to Point of Sale > Click on Furniture > Open Register > Load Sample > Close register - Go to Point of Sale > Products > Combo choices > Delete all combo choices - Go to Settings > Restrict Categories > Unset all categories > Save - Go to Point of Sale > Dashboard > Furniture > Open Register > Load Sample Traceback: ```py ParseError: while parsing /home/odoo/src/odoo/19.0/addons/product/data/product_demo.xml:905 A combo product must contain at least 1 combo choice. ``` https://github.com/odoo/odoo/blob/c81e50d3b8f0ffc0297c97b06afd77e2c92ad508/addons/point_of_sale/models/pos_config.py#L1025 When clicking Load Sample button in the Furniture PoS, the ``_load_onboarding_furniture_demo_data`` method loads the ``data/product_demo.xml`` file. If the combo choices linked to products have been deleted, loading the following record triggers the above traceback. https://github.com/odoo/odoo/blob/c81e50d3b8f0ffc0297c97b06afd77e2c92ad508/addons/product/data/product_demo.xml#L664-L671 Solution: Restrict deletion of combo choices if they are linked to any products. sentry-6943167929 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users with limited access to the Appraisal module would encounter errors when loading sample data. The problem stemmed from the sample data attempting to create records within the Recruitment module, which required broader permissions. This fix ensures the data load process is stable for users with the Appraisal module access.
Original PR description
The system will crash when user try to load sample data in appraisal. **Steps to produce:-** - Install `Appraisals` and `Recruitment` module. - Make a new user with access right of administrator to…
The system will crash when user try to load sample data in appraisal.
**Steps to produce:-**
- Install `Appraisals` and `Recruitment` module.
- Make a new user with access right of administrator to `only Appraisals`.
- Login with new user.
- `Appraisals > Load sample data`.
**Error:-**
```py
AccessError: You are not allowed to create 'Job Position' (hr.job) records.
This operation is allowed for the following groups:
- Recruitment/Officer: Manage all applicants
ParseError: while parsing /home/odoo/src/odoo/saas-18.4/addons/hr/data/scenarios/hr_scenario.xml:21, somewhere inside <record id="job_consultant" model="hr.job" forcecreate="1">
<field name="name">Consultant</field>
<field name="no_of_recruitment">5</field>
<field name="contract_type_id" ref="hr.contract_type_interim"/>
<field name="description">We are currently looking for someone like that to join our Consultant team.</field>
</record>
ValueError: ParseError('while parsing /home/odoo/src/odoo/saas-18.4/addons/hr/data/scenarios/hr_scenario.xml:21, somewhere inside\n<record id="job_consultant" model="hr.job" forcecreate="1">\n <field name="name">Consultant</field>\n <field name="no_of_recruitment">5</field>\n <field name="contract_type_id" ref="hr.contract_type_interim"/>\n <field name="description">We are currently looking for someone like that to join our Consultant team.</field>\n </record>') while evaluating
'action = model._load_demo_data()'
```
**Root Cause:-**
- When a user is granted access rights only for the Appraisal module and attempts to load sample data for it, an error occurs. This happens because the sample data at [1] includes the `creation of records` related to the `Recruitment module`. Since the user does not have the required access rights for Recruitment, the system raises a permission error.
**Solution:-**
- In this commit, we resolve the issue by using `sudo()` while loading the data.
[1]: https://github.com/odoo/odoo/blob/fabfeb55c56fbc7136bd1c3a72e9d6ee99f39714/addons/hr/data/scenarios/hr_scenario.xml#L21-L26
**sentry-6795776877**
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where placeholder hint text in the HTML editor would wrap awkwardly onto multiple lines when the screen was narrow. Now, the text is correctly truncated when space is limited, ensuring a cleaner and more consistent user experience across different screen sizes. This improves readability and visual appeal.
Original PR description
Description of the issue this PR addresses: - The placeholder hint text wraps onto multiple lines when the cell width is reduced. - When there is insufficient horizontal space, the text should be truncated rather than wrapped. task-5480080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243603 Forward-Port-Of: odoo/odoo#243006
This update corrects a technical issue that caused tracebacks when generating the Follow-up Report, specifically related to how customer statements were processed. It now ensures that General entries are automatically set to 'no_followup', with an exception for payments originating from Point of Sale (POS) systems. This improves report stability and accuracy.
Original PR description
* Fix traceback when opening the follow-up report and customer statement. * General(MISC) entries should be no_followup by default. Except entries coming from pos should not be excluded from follow-ups. Forward-Port-Of: odoo/enterprise#104433
This update removes an unnecessary warning related to credit notes from the GSTR report. Previously, the warning interfered with credit note processing, particularly when a credit note was confirmed after an invoice. Now, the warning is automatically cleared when the credit note is fully posted and checked.
Original PR description
This **PR** removes the credit note warning from the GSTR report, as it is not required at the report level. Additionally, when this warning is present on an invoice and the credit note is confirmed, the credit note is set to not checked. The warning will only be cleared once the credit note is posted and checked task-5469000 Forward-Port-Of: odoo/enterprise#104518 Forward-Port-Of: odoo/enterprise#102106
This update corrects a technical issue that was causing error messages when using Razorpay payment processing within the Point of Sale (POS) system. The fix removes a problematic attempt to access sudo functionality, which wasn't applicable to the Razorpay payment request object. This ensures smoother and more reliable payment processing for Indian users.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634 Forward-Port-Of: odoo/odoo#244177
A bug was causing overdue invoices to appear twice in PDF follow-up reports. This update corrects a technical issue within the invoicing process, ensuring invoices are printed only once in these reports. This improves the accuracy and clarity of follow-up reminders for customers.
Original PR description
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this…
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this Partner then in the "Accounting" sheet, - Choose follow-up as manual, - Click on send, - In the wizard select Print and "Join invoices" ### Current behavior: The PDF display the reminder, the invoice, the report and the invoice again. ### Expected behavior: Invoice should appear only once in the follow-up PDF. ### Cause : When manually sending the follow-up, the wizard attaches the invoices to the follow-up. Then in `_get_followup_attachments`, it attaches the report, template attachments and the invoices again. In a manual follow up, it should be possible to choose which invoices are sent. The method `_get_invoices_to_print` ensure this by looking at the options' attachment. Therefore, it's not possible to clear the attachment field before fetching the invoices. opw-5368870 Forward-Port-Of: odoo/enterprise#102516
This update resolves an issue preventing stable IoT Box responses from being correctly read. By adding a check for a 'result' key in the data, the system now reliably processes data from these terminals, ensuring consistent and accurate reporting. This improves the overall stability and functionality of the IoT integration.
Original PR description
We now read data in result key if it exists to ensure readability of stable IoT Box responses. Forward-Port-Of: odoo/enterprise#104360 Forward-Port-Of: odoo/enterprise#104113
This update corrects a data inconsistency in Odoo, reflecting Bulgaria's recent adoption of the Euro as its official currency. Previously, Bulgaria was linked to the Bulgarian Lev (BGN). Now, it's correctly associated with the Euro (EUR), ensuring accurate financial reporting and data processing for transactions in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update ensures that manually set currency rates on customer invoices (especially in German and Hungarian) are correctly applied during the invoice posting process. Previously, the system automatically replaced these rates with standard exchange rates, leading to potential inaccuracies. This fix maintains the user's intended rate, improving invoice accuracy and financial reporting.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update resolves a potential error in the accounting module that could occur when calculating tax adjustments. The change ensures the system handles the scenario where all factors are zero, preventing a traceback and maintaining accurate financial calculations. This improves system stability and reliability.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616