Tuesday, May 5, 2026
23 changes · saas-18.2
Resolved issues and error corrections
Fixes an error that could block assigning a recruiter to a job position when the Payroll app is not installed. Recruitment teams can now use the job position workflow consistently regardless of whether Payroll is enabled.
Original PR description
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_kanban view to ensure the field is consistently available for domain evaluation regardless of other installed modules. **Task:** 6106143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website menu flow now waits for an expanding menu to finish appearing before moving on. This reduces inconsistent behavior, especially in automated checks, and helps prevent other navigation menus from closing unexpectedly.
Original PR description
[FIX] website: wait for extra menu to fully render before continuing When clicking on the extra menu item, a Bootstrap dropdown is displayed with a transition. Because this transition takes time, it can lead to undeterministic behavior especially in tests. For example, if a tour clicks on the extra menu item and then clicks on the "Site" button in the navbar, the dropdown transition may still be in progress. This can cause the "Site" dropdown to close prematurely. runbot-240955 Forward-Port-Of: odoo/odoo#261721 Forward-Port-Of: odoo/odoo#261179
This update adjusts a manufacturing test so it no longer depends on an enterprise-only component. It helps keep community edition validation reliable and prevents avoidable test failures during development and release checks.
Original PR description
The test `test_multi_lot_component_consumption` relies on `move_raw_line_ids`, which is initialized by the `stock_barcode_mrp` module. This module is only available in enterprise, causing the test to fail in community setups. https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/mrp/tests/test_consume_component.py#L494 runbot-242612 Forward-Port-Of: odoo/odoo#261816
Employees who only have Timesheets access can now open details for projects assigned to them without seeing an access error. This prevents disruption when recording or reviewing time on customer projects while keeping access limited to the relevant project information.
Original PR description
### Steps to reproduce: - Download 'Sales', 'Project', 'Employees', and 'Timesheets' apps - Create an employee and link them to a user that doesn't have any access rights except to 'Timesheets =…
### Steps to reproduce:
- Download 'Sales', 'Project', 'Employees', and 'Timesheets' apps
- Create an employee and link them to a user that doesn't have any access rights except to 'Timesheets = User:own timesheets'
- In Sales, create a service with the following specifications:
- 'Create on Order' is 'Project'
- 'Invoicing Policy' is 'Based on Timesheets'
- Create a new quotation that requests this service and click 'Confirm'
- In 'Project' > 'Configuration' > 'Projects', choose the newly created project and add a line that has the new employee in the 'Invoicing' tab
- Log in as that employee and go to 'Timesheets'
- Create a new entry for the newly created project
- Click the project's name
> Access Error: You are not allowed to access 'Collaborators in project shared'
(project.collaborator) records.
### Cause of Issue:
This happens because the user doesn't have access rights to the 'Project' app, hence they don't have access to `collaborator_ids` which are retrieved here. https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/project/models/project_project.py#L1113-L1120
### Fix:
Since an access to the 'Projects' app isn't necessary to view a project assigned to you, `sudo()` is necessary for hr_timesheet users without project access rights.
opw-6074833
Forward-Port-Of: odoo/odoo#258370This change ensures vendor bills and other journal entries appear in the correct payment status group when users group or filter records by payment status. It prevents the same bill from showing in multiple groups, improving accuracy in accounting views and reducing confusion during invoice review.
Original PR description
Step to reproduce - create a vendor bill, for say 100$ i.e Bill 1 - post it - go to journal entry menu - group by: "status_in_payment" - expand the lines Observation: - after group by, suppose we get 2 groups in journal entry (Draft, Not Paid) - when we expand. Bill 1 is present in both group (Bill 1 should be in Not paid) - in each group we get all the records Cause: - `status_in_payment` is a compute field, for web_search to work, this fields need a `search` method which is absent here. - in this case, we just set domain = [] - hence, we got above unexpected results https://github.com/odoo/odoo/blob/e7f4a88432d9696800d1f2b9e28bf92320c97422/odoo/osv/expression.py#L1179-L1187 Fix: - Add the search method for this fields opw-6109572 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259131
This fixes an accounting test that could fail because invoice payment status differs between environments. The test now uses the system's expected payment-state logic instead of assuming one fixed result, improving reliability without changing business behavior.
Original PR description
Community edition tests fail because payment status after registration can be (`paid` or `in_payment` depending on environment), while the test assumes a fixed value. so instead of hardcoding the state, we use `_get_invoice_in_payment_state` which return required state, depending on environment we are Runbot [link](https://runbot.odoo.com/odoo/error/243480) runbot-error:243480 Forward-Port-Of: odoo/odoo#262501
Discuss now correctly prioritizes contacts whose email addresses start with the user's search terms. This makes search results more relevant and helps users find the intended contact faster.
Original PR description
In Discuss, the function used to sort partners prioritizes those whose email addresses start with the search terms. However, due to an error in the programming of the corresponding condition, this check could never be true. This commit adjusts the condition so that it behaves as expected. Forward-Port-Of: odoo/odoo#262583
Creating a new company from customer or vendor lookup now follows the same rules as the contact form autocomplete. DnB industry information is no longer saved as partner tags, keeping contact records cleaner and more consistent.
Original PR description
Partner Autocomplete was updated so DnB industry data (UNSPSC) is no longer stored on Partner Tags. That behavior was applied to the name/VAT char widget, but creating a company from a Partner…
Partner Autocomplete was updated so DnB industry data (UNSPSC) is no longer stored on Partner Tags. That behavior was applied to the name/VAT char widget, but creating a company from a Partner many2one (e.g. customer/vendor on an invoice) still used the old path: calling an IAP suggestion `iap_partner_autocomplete_add_tags` Steps to reproduce: ------------------- * Open a customer invoice (draft). * On Customer, search a company name and pick a Partner Autocomplete line to create a new company. * Save the quick-create dialog. > Observation: The new contact still had Partner Tags populated from DnB industry data (UNSPSC), unlike contacts created or enriched from the contact form autocomplete. (see video on ticket to avoid using more IAP credits) Why the fix: ------------ Align `res_partner_many2one` with `field_partner_autocomplete`: do not call `iap_partner_autocomplete_add_tags`. From task-5373200, industries from DnB must no longer be added as Partner Tags. opw-5972360 Forward-Port-Of: odoo/odoo#260078
This fixes an internal error that could occur when Odoo prepares and reuses certain data filters optimized for performance. The change helps keep backend operations stable without changing how users work with the system.
Original PR description
Description of the issue/feature this PR addresses: `Domain` objects cannot be hashed when their value contains some `OrderedSet`, which are introduced by optimizations. 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
This change updates a manufacturing test so it no longer depends on an Enterprise-only barcode feature. It helps keep community edition quality checks reliable and prevents false test failures during development and releases.
Original PR description
The test `test_multi_lot_component_consumption` relies on `move_raw_line_ids`, which is initialized by the `stock_barcode_mrp` module. This module is only available in enterprise, causing the test to fail in community setups. https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/mrp/tests/test_consume_component.py#L481 runbot-242612 Forward-Port-Of: odoo/odoo#260424
The search bar’s custom group-by option now highlights correctly when users hover over it. It can also be reached again with keyboard navigation, improving accessibility and consistency in the menu.
Original PR description
The CustomGroupByItem select was missing the `o-navigable` class, so the navigation system never registered it. On hover, it would not receive the `focus` class, which ensures proper styling of dropdown items. The fix also restores the ability to reach the CustomGroupByItem select with keynav. task-6108677 Forward-Port-Of: odoo/odoo#260675
Vendor bill imports now correctly apply allowances to products priced at zero when additional charges are present. This prevents mismatches between XML invoice totals and Odoo totals, reducing manual correction during bill processing.
Original PR description
Allowances for Product with price as 0.00 aren't applied Step to reproduce: - import vendor bill from an XML having a product: - price: 0.00 - charge: any positive amount - allowance: any positive amount Current behavior: - allowance isn't apply resulting in a difference between the XML total and Odoo total Cause of the issue: Before this commit the discount was applied as a percent of price only. Having a price as 0 prevent doing so. opw-5499525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247938
Fixed an issue where choosing cash on a payment terminal during a Razorpay POS transaction could cause an error and interrupt checkout. The update makes the payment flow more reliable by safely handling missing terminal values before processing them.
Original PR description
Steps: - Open a POS configuration with the Razorpay payment method set to all payment modes. - Process an order and initiate a Razorpay transaction. - Select a cash payment option on the terminal. Issue: - A traceback occurs with the error: `Cannot read properties of null (reading 'replace')`. Cause: - The code attempts to call the replace method on a null value. Fix: - Ensure the replace method is called only when the value is a valid string. Task-6190355
The Belgian Peppol partner validity check no longer tries an outdated identifier format when an endpoint is not found. This keeps validation aligned with the currently used Belgian identifier and avoids unnecessary recalculation during checks.
Original PR description
When adding peppol, we didn't know if we needed to use the 9925:BE or 0208. Therefore, we switched between them if the endpoint was not found. This has no more use today as we use 0208. opw-5976574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261081 Forward-Port-Of: odoo/odoo#258297
This update corrects a bug that prevented users from saving accounting settings when GST registration was unregistered. The fix ensures the system correctly checks GST registration status, preventing a 'Missing Required Fields' error and allowing users to configure the module properly. This improves the usability of the Invoicing module for businesses operating in India.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001
This update resolves an issue where multiple users were incorrectly added to WhatsApp discussion channels after a message was sent. The fix ensures that only the user who initiated the conversation is added to the channel, preventing unnecessary notifications and channel clutter. This improves the user experience and channel management efficiency.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138 Forward-Port-Of: odoo/enterprise#102452
This update resolves a problem with the CSV export for Dutch Intrastat reporting, which was broken following a recent technical update. The fix addresses an incorrect formatting of 'Commodity flow' data and ensures the database is up-to-date before generating the report, improving data accuracy for reporting.
Original PR description
Since the technical refactoring of intrastat in 18.0, the csv export in `l10n_nl_intrastat` seems broken. Here is the fixes done in this commit: 1. `Commodity flow` is supposed to be a single diggit (6 or 7) but an empty blank space was hidden. 2. Switching the condition on `country_origin_code` as it was the opposite 3. Add a `flush_all` before calling the report during the export, to be sure the database is up to date. opw-5799126 Forward-Port-Of: odoo/enterprise#115791
This update resolves an issue where users could accidentally select customers from different companies within the Helpdesk module. The fix adds a restriction to the customer selection field, ensuring users only see customers within their assigned company. This improves data accuracy and prevents potential errors in ticket management.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
This update resolves an issue causing incorrect rounding when importing purchase orders processed through OCR. The fix restores the original rounding precision, aligning with the intended functionality for EDI processing, rather than the OCR process. This ensures accurate financial data import.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116021
This update fixes an error in how VAT reimbursement moves are calculated when carrying over unclaimed tax amounts. The previous calculation incorrectly used data from the previous month's tax report, leading to inaccurate reimbursement amounts. This ensures accurate VAT reporting and proper reimbursement processing.
Original PR description
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and…
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and post a bill in May containing a VAT amount. - Create and post a bill in June containing a VAT amount. - Create a VAT return for May to carry over the VAT amount to the next month. - Create a VAT return for June, requesting the full VAT amount to be reimbursed. - Validate and send the June VAT return. - Check the generated reimbursement move Issue: Line values does not correspond to anything real/tangible. It occurs because when computing the ratio for the move we check the last tax report entry, where we find the amount of tax from the past months and a line balancing the last month that should not be taken into account. The "Balance tax current account (receivable)" line from the tax closing entry is mistakenly picked up as a tax carried forward line, throwing off the amounts. opw-5961836 Forward-Port-Of: odoo/enterprise#115451
This update resolves an issue where error messages from the Danish tax reporting system (l10n_dk_rsu) could cause unexpected errors. The fix ensures that error messages are handled correctly, preventing system crashes and improving the reliability of tax report generation. This resolves a technical bug related to data type mismatches.
Original PR description
before this commit, if the SKU server was returning an error message, the error handler would raise an exception because of the lazyTranslate. The reason is that `join()` expects an actual sting as argument, not a lazy string. This commit adds some tests for the error case and fixes the error due to the lazytranslate in the error codes. opw-6171466 Forward-Port-Of: odoo/enterprise#115515
This update fixes a minor typo in the French Profit & Loss report. The term "exceptionnel" was incorrectly using masculine form when it should be feminine to accurately reflect charges. This ensures correct reporting and compliance for French accounting standards.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges.
This update resolves an error in the Luxembourg VAT reports (FAIA) caused by a missing required TaxType element ('TVA'). The fix ensures the reports comply with Luxembourg tax regulations, preventing export failures. This was triggered by a customer report and verified against XSD files.
Original PR description
This is one of several commits fixing the FAIA xml export. The customer in ticket [opw-5427296](https://www.odoo.com/odoo/unassigned-tasks/5427296) received several errors which mention that the `TaxType` element should be 'TVA'. This is corroborated by one of these elements in the XSD files for the FAIA report. The XSD files can be found at the link below. https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-6118272 [link](https://www.odoo.com/odoo/project.task/6118272) Forward-Port-Of: odoo/enterprise#113720