Tuesday, January 27, 2026
25 changes · 19.0
Resolved issues and error corrections
This fix prevents an unexpected system error when users create or edit inherited views with incomplete XPath instructions. Instead, Odoo now shows a clear validation message explaining that the required XPath expression is missing, making the issue easier to correct.
Original PR description
Currently, an error occurs when a user creates an inherited view. **Steps to Reproduce:** - Go to `Settings > Technical > User Interface > Views`. - Create a new view by entering `name` and selecting…
Currently, an error occurs when a user creates an inherited view.
**Steps to Reproduce:**
- Go to `Settings > Technical > User Interface > Views`.
- Create a new view by entering `name` and selecting any `inherited view`.
- In the `Architecture`, enter the below code:
```
<xpath position="replace">
<field name="name"/>
</xpath>
```
- Now save the view.
`TypeError: Argument must be bytes or unicode, got 'NoneType'`
Cause:
As we can see, when the user enters an xpath without the expr attribute, and when it goes to find the inherited node [1]. Since the expr is missing, its value becomes None [2]. Passing this None as an argument [3] causes the error.
This commit ensures that when a user creates or edits a view with an xpath that is missing the expr attribute, a ValidationError is raised indicating that the expr attribute is missing in the XPath.
[1]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L145
[2]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L76
[3]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L78
[4]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/addons/base/models/ir_ui_view.py#L377-L384
sentry-7161414430
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242203This fixes an internal Mail app test that could fail unpredictably when checking whether opening a conversation marks inbox messages as read. The change improves release stability by making the automated test wait for the initial message loading step and verifying both read-marking paths.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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#244693
This fixes a rare issue where certain printer connection records could lose their disconnect tracking information. The change helps keep IoT printer monitoring stable and avoids an unexpected error during connection checks.
Original PR description
This commit fixes an edge-case between the disconnect counter logic, and the logic added in odoo/odoo#224200 to prevent printers switching between `lpd` and `socket` protocols. In this case, a device is returned that only has the `identifier` key set. Because the driver has already been instantiated, this didn't break anything before, but now it also clears the `disconnect_counter` key, leading to a traceback on the next iteration of the interface when it tries to check the `disconnect_counter`. The fix is simply to include the `disconnect_counter` as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245719
This fixes inconsistent pricelist handling when creating customers in or outside configured country groups. Customers will no longer appear to have a manually assigned pricelist when they are simply using the default, reducing confusion and keeping pricing records cleaner.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4.…
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4. create a new partner in a EU country; 5. create a new partner outside a EU country; 6. create a new partner without a country. Issue ----- Inconsistent behavior: - EU partner has no `specific_property_product_pricelist` value set, as it's identical to the default `property_product_pricelist`. - The other partners do have a `specific_property_product_pricelist` value set to the default value, as if a user manually assigned them. Cause ----- In the `_inverse_product_pricelist` method, the `default_for_country` pricelist is an empty recordset if the partner has no `country_id` or none of the pricelists have a country groups with the partner's `country_id` in it. Solution -------- Introduce a `_get_country_pricelist_multi` method that can be used by `_get_partner_pricelist_multi` and `_inverse_product_pricelist` to ensure that they both return the same result for any given country (including none), and use this as the `default_for_country`. > [!Note] > An alternative approach could be to replace the `_inverse_product_pricelist` method with an `onchange` method, as the docstring of the `_get_partner_pricelist_multi` method states: >> First, the pricelist of the specific property (res_id set), this one is created when saving a pricelist on the partner form view. > > This suggests a behavior that more closely resembles the purpose of an `onchange` method, instead of an `inverse`. opw-5385213 Enterprise PR: https://github.com/odoo/enterprise/pull/103116 (only modifies a test) Forward-Port-Of: odoo/odoo#245681 Forward-Port-Of: odoo/odoo#241736
This fix makes Odoo return the embedded action after it is created or updated, helping related workflows immediately use the latest action data. It reduces the chance of follow-up steps relying on missing or outdated information in the web interface.
Original PR description
This commit modifies the `set_embedded_actions_setting` function to return the updated / created embedded action. Enterprise PR: https://github.com/odoo/enterprise/pull/101924 task:5388717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a rounding error in Argentine purchase withholding calculations when tax rounding is set per tax. Businesses will now see the expected withholding amount on vendor payments, helping avoid small but important discrepancies in accounting records.
Original PR description
Steps to reproduce: - Set company to (AR) Responsable Inscripto - In Accounting > Settings, choose Round per Tax as the rounding method. - Go to Accounting > Taxes, duplicate IIBB WTH CABA 0%, and set Amount to 4.5%. - Open partner ADHOC SA, in the accounting tab add the new tax in Purchase Withholding - Create a new vendor Bill to vendor ADHOC SA with unit price 156,087.00 - Confirm and open Payment wizard Issue: Withholding amount is 7023.91, but it should be 7023.92 It occurs that the computed amount is 7023.915. Then when the tax repartition values are computed, the value is rounded and rounding difference are redistributed in the tax lines, so it seems the value has been rounded down. opw-5154585 Forward-Port-Of: odoo/odoo#241633
The chat window fold and close buttons now visually react when users hover over them. This makes the controls easier to identify and click while keeping them slightly less prominent when not in use.
Original PR description
These 2 buttons had no hover effect, compared to other buttons like the "start a call". The lack of hover effect makes it harder to click on these buttons. This commit reduces slightly the opacity of button when not hovered, so that they are highlighted on hover from change to 100% opacity. The reduced opacity also makes these buttons slightly less visible, which is actually an improvement. Before / After (hover on "x") <img width="383" height="48" alt="Screenshot 2026-01-26 at 17 25 10" src="https://github.com/user-attachments/assets/7d4578cc-fcde-44b6-91e9-e0956e789c54" /> <img width="380" height="49" alt="Screenshot 2026-01-26 at 17 14 40" src="https://github.com/user-attachments/assets/e8f3690e-4202-4afd-85a5-d1459b13946e" />
Delivery orders no longer fail when a user adds a product line but leaves the product unselected before editing order details. This prevents a disruptive error and lets warehouse teams continue updating deliveries normally.
Original PR description
Currently, an error occurs when a user edits a delivery order after adding a product line, but without selecting any product. **Steps to Reproduce:** 1. Install the **Stock** module. 2. Create a new Delivery Order and click **"Mark as To-do"**. 3. Click **"Add a product"**, but do not select any product. 4. Change the 'Scheduled Date' or 'Delivery Address'. Video Ref: [LINK](https://drive.google.com/file/d/1v_MZ0nfNa_lzTjV1gChchCw4g_aKzP-8/view?usp=drive_link) **Error:** `ValueError - Expected singleton: uom.uom()` **Cause:** When a stock move is created without a product, `move.product_id` remains empty, which leads to the singleton error during product availability computation. **Fix:** This commit adds a check before performing the UOM comparison. sentry-7173331233
This fixes an issue in the website editor where undo and redo shortcuts could stop working after closing the translation color-code explanation dialog. Editors translating website pages can now continue making changes and use keyboard undo reliably, reducing frustration and avoiding lost editing time.
Original PR description
The builder uses `useHotkey` to bind the shortcuts for undo/redo. But when entering translate mode, if the dialog about color code appears, the hotkeys are associated with the active element of the dialog, and thus are skipped on dispatch when in the builder (and the dialog is closed). This commit shows the dialog in `onMounted` of the builder, instead of `onWillStart`, so that the dialog appears just after (instead of just before) the hotkeys are bound to the active element. Steps to reproduce: - On a DB with a website in several languages - Open the website builder in translate mode - Discard the dialog explaining the color code. This is the dialog needed to trigger the bug. If the dialog does not appear, try with a new private window - Do some edits in the page - Click in the sidebar (otherwise keys are handled in the iframe) - Press `ctrl+z` - Bug: it does not "undo" task-5481935 Forward-Port-Of: odoo/odoo#243137
The Mail app now lets canned response descriptions use the full available space instead of being squeezed into a narrow panel. This makes saved replies easier to browse and select in Discuss and chat windows, improving day-to-day message handling.
Original PR description
Canned responses have an arbitrary small width limit in the navigable list panel. Due to this restriction, the description of the canned response is barely readable. This commit makes it take the whole available width. task-5873810 || Before | After| | ------------- | ------------- | -----| |Discuss|<img width="832" height="318" alt="image" src="https://github.com/user-attachments/assets/4671ea44-7687-442a-a14c-1c56c3851930" /> |<img width="839" height="331" alt="image" src="https://github.com/user-attachments/assets/7fde9d8c-9682-43e5-b1b4-9a303331f445" />| |Chat window|<img width="453" height="437" alt="image" src="https://github.com/user-attachments/assets/c2b255f6-2552-4739-9a5d-d22e8c257a07" />|<img width="410" height="610" alt="image" src="https://github.com/user-attachments/assets/b8097f1b-04f4-4a3e-b11f-021bfcb9398e" />|
This update resolves an error that prevented the creation of new contract templates in the US payroll module. The issue stemmed from a constraint requiring a filing status, which was incorrectly applied to templates. The change ensures that the filing status is correctly set through employee data, aligning with the system's intended functionality.
Original PR description
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is…
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is empty..." A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules. This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee. We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee. The constraint will now only raise when loading a contract template on the employee or editing the field through the employee. [1] odoo/enterprise#83136 opw-5458566 Forward-Port-Of: odoo/enterprise#104990
This update corrects a technical issue that was causing an error message to appear on the TFN dashboard, specifically related to employee TFN status reporting. The fix ensures accurate warning calculations for employees applying for TFNs, improving payroll reporting reliability. This update was part of a larger upgrade process.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_au_hr_payroll. 2. Enable multi-company and switch to an AU company. 3. Change an existing employee’s company to the AU company ([employee…
Steps to reproduce:
-------------------
1. Install l10n_au_hr_payroll.
2. Enable multi-company and switch to an AU company.
3. Change an existing employee’s company to the AU company
([employee created more than 28 days ago](https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/l10n_au_hr_payroll/data/hr_payroll_dashboard_warning_data.xml#L31)).
4. Under the payroll tab, set the TFN Status to:
"Employee applied for TFN but didn't receive it yet, less than 28 days ago".
5. Open Payroll.
Issue:
--------
A traceback occurred:
```
Error: NameError("name 'invalid_employees' is not defined")
```
Cause:
------
The evaluation code computes `warning_count` using
an undefined `invalid_employees` variable.
Solution:
---------
Define `invalid_employees` before using it to compute
`warning_count` and `warning_records`.
**NOTE:**
The [upgrade script](https://github.com/odoo/upgrade/blob/ed5bc3fd99ef6fba4bc7162934df36396ae9fc3f/migrations/l10n_au_hr_payroll/saas~18.4.1.0/end-migrate.py#L30) is already available from version 18 to 19.
opw-5459998
Forward-Port-Of: odoo/enterprise#103777This update ensures that when a new partner is created during a shared sign request, the partner's name is automatically set to the signer's name, rather than relying on their email address. This improves data accuracy and consistency for shared agreements, simplifying record-keeping and reporting.
Original PR description
Version: - saas-18.2 Steps to reproduce: - Create a shared sign request. - Open the shared signing link and complete the signature process. - During signing, a new partner gets created for the signer if not already exists. Before: - When the user signs the shared sign request and a new partner is created, the partner name is not set and email is used as name. After: - Now, when a user signs a shared sign request and a new partner is created, the system automatically sets the partner name using the signer name. task-5776339 Forward-Port-Of: odoo/enterprise#105271 Forward-Port-Of: odoo/enterprise#104869
This update ensures the Helpdesk dashboard's styling is consistent with other Odoo dashboards. Specifically, the conditional formatting and border styles for the Top Customers pivot have been adjusted to match the overall design, improving the dashboard's visual appeal and user experience.
Original PR description
## Description - The Top Customers pivot shows 10 rows, but the conditional format covered only 9. Extend the CF range so the last row is formatted. - Adjust border ranges so the helpdesk dashboard matches the styling used in other dashboards. Task: [5448434](https://www.odoo.com/odoo/project/2328/tasks/5448434) Forward-Port-Of: odoo/enterprise#103284 Forward-Port-Of: odoo/enterprise#103019
This update resolves an issue where extremely high IDs in Odoo's commission reports could cause errors. By using a bitwise operation instead of multiplication, the system now correctly handles large IDs, ensuring accurate report generation and preventing potential data corruption. This improves the stability and reliability of the commission reporting functionality.
Original PR description
Before this commit, we had issues on odoo.com when the ids of the account move, account move line, sale order or sle order line were too high. We would end up with ids bigger than BIGINT limit. This commit ensure it does not happen anymore by using bitwise operation on ids istead of multiplying the values. task-5423978
This update resolves an issue preventing bookings from being scheduled for the last hour of the day. The fix corrects a technical error that was incorrectly treating the end of the day as unavailable, now allowing users to book appointments until 23:00. This ensures full utilization of resource slots.
Original PR description
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to…
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to the website page of the appointment - Last slot is not showing (23:00-00:00) **Issue:** When computing the appointment slots of a resource using time range, the end of day is considered as an unavaibility resource slot with this interval in `_get_unavailable_intervals`: `i_start = 23:59:59.999999` `i_stop = 00:00` this conflicts with the given range (23:00-00:00) in `self._slot_availability_is_resource_available` It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)` is converted to `time.max` (23:59:59.999999) by: `day_to = datetime.combine(day, float_to_time(attendance.hour_to))` This introduces the microsecond unavaibility at the end of the day, which blocks the booking. (it's working properly for availability on users appointments) **Fix:** Changed the condition so that 23:59:59.999999 is considered as equal to 00:00. opw-5163892 Forward-Port-Of: odoo/enterprise#104927 Forward-Port-Of: odoo/enterprise#100853
This update corrects a discrepancy in a test related to how subscription pricelists are ordered. The change ensures that pricelists are correctly prioritized based on their sequence and ID, regardless of whether a partner has a country assigned. This resolves a technical issue that didn't impact business operations.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit a840e4250666 changed a `sale_subscription` test as pricelist ordering was changed. Before, it was `sequence asc, id desc`, now it is `sequence asc, id asc`. However, in the updated tests, it expects the first pricelist created with sequence 4 to be before the second pricelist with sequence 2. This was only happening due to default pricelists getting set as the `specific_property_product_pricelist` if the partner has no country assigned to them. Solution -------- As the behavior is now identical for partners with or without a country assigned to them, we can resolved the test setup by giving both pricelists an identical sequence, making the ordering fall back on `id` like a840e4250666 intended. opw-5385213 Related: https://github.com/odoo/odoo/pull/241736 Forward-Port-Of: odoo/enterprise#105475 Forward-Port-Of: odoo/enterprise#103116
This update resolves a test failure in the web_studio module caused by a missing dependency. The test was incorrectly checking for models that weren't part of the installed modules, specifically due to the `account_edi` module. The fix ensures the test accurately reflects the installed modules and handles missing dependencies gracefully.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list. Forward-Port-Of: odoo/enterprise#105408 Forward-Port-Of: odoo/enterprise#104879
This update fixes a potential issue where applicants could incorrectly reopen expired or fully-signed job offers. The change prevents access to these offers, ensuring data integrity and preventing applicants from attempting to re-sign outdated offers. This improves the overall offer management process.
Original PR description
This commit improves the offer validation logic to avoid invalid or unintended signature attempts. Fixes included: - Block access to offers that are already fully signed, preventing applicants from reopening the link and unintentionally reverting the offer to a partially signed state. These changes ensure that expired or fully processed offers no longer expose active signature links and that offer validity is consistently enforced at the database level. task-5405456 Forward-Port-Of: odoo/enterprise#103734 Forward-Port-Of: odoo/enterprise#101834
This update resolves a bug that caused the follow-up report to crash when users unfolded partner lines while prefix groups were enabled. The fix corrects an error in how the report processed data, ensuring stability and reliable report generation for all users.
Original PR description
When prefix groups were enabled, and a prefix group line had been unfolded, the report crashed when trying to unfold the partner. This happened because res_ids_map is computed for each of the unfolded lines, including the prefix groups one, which then had no 'res.partner' key, causing a key error. Forward-Port-Of: odoo/enterprise#105525
This update resolves an issue where outdated sign requests were incorrectly sending notifications to users with mismatched email addresses. The fix ensures that 'next documents to be signed' are only sent to signees with verified email contacts, improving the accuracy and reliability of the sign request process. This prevents unnecessary notifications and streamlines communication.
Original PR description
This commits fix the problem where the `signer_email` field of old sign items don't have a value defined then showed up as "next documents to be signed" for other users, even when the email doesn't match. task-5487349
This update resolves an issue where duplicate order warnings appeared when upselling subscriptions. The change specifically excludes upsell quotes from the duplicate order check, ensuring that these quotes are correctly processed without unnecessary alerts. This improves the user experience and prevents potential disruptions to the sales workflow.
Original PR description
Version: - 19.0 Steps to reproduce: 1. Create a subscription. 2. Set a customer reference 3. Confirm the subscription and create an invoice. 4. Upsell the subscription to generate a upsell quote (state '7_upsell'). Issue: A duplicate order warning is displayed when upsell a subscription Solution: Exclude upsell quotes (`subscription_state == '7_upsell'`) from the duplicate order check in `_fetch_duplicate_orders`. This prevents incorrect warnings when creating or opening upsell quotes. taskid-5438769
This update fixes an issue where applicant stage changes weren't correctly displayed in the recruitment reports module. The fix ensures that stage change messages appear with the correct 'Stage changed' label and uses the accurate stage name 'Qualification' instead of 'Initial Qualification'.
Original PR description
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't…
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't show "Stage changed" label 4. Review mail.tracking.value records for applicant stage changes 5. Observe incorrect stage name "Initial Qualification" instead of "Qualification" Bug cause: mail.message records for applicant stage changes were missing the subtype_id field, which defaults to an incorrect subtype (mt_note instead of mt_applicant_stage_changed). This caused the messages to be treated as internal notes rather than stage change notifications. Additionally, mail.tracking.value records used "Initial Qualification" as the old_value_char or new_value_char, which doesn't match the actual stage name defined in hr_recruitment module. The correct stage name is simply "Qualification" (ref: hr_recruitment.stage_job1). Solution: - Add subtype_id field with reference to hr_recruitment.mt_applicant_stage_changed to all mail.message records that track applicant stage transitions - This ensures stage change events are properly identified and displayed in chatter with the correct "Stage changed" label - Update old_value_char and new_value_char fields in mail.tracking.value records to use the correct stage name "Qualification" instead of "Initial Qualification" - Ensures consistency with actual stage names and proper display in applicant chatter history Affected records: 20 mail.message records in hr_recruitment_reports_demo.xml Task Id:5454691
This update resolves a technical issue that could cause errors when generating Peruvian VAT (PE) reports. The fix ensures that the system handles cases where a required text field is missing, preventing a traceback and ensuring accurate report generation. This improves the reliability of the odoo Enterprise module for businesses operating in Peru.
Original PR description
Forward-Port-Of: odoo/enterprise#105462
This update addresses a potential issue where deleted records in Odoo could still be accessed, leading to errors. The fix ensures that related records are checked for existence before accessing data from deleted records, primarily due to how cascade deletions are handled in the database. This enhances data integrity and stability.
Original PR description
In order to be defensive we have to check records linked to messages, notifications or activities exist before checking related information like display_name, or even to skip them in various flows. This happens notably due to DB-level cascade deletion that does not remove side records linked through (model, res_id) pairs. It implies some additional exist queries. Task-5138556 Forward-Port-Of: odoo/enterprise#104538 Forward-Port-Of: odoo/enterprise#101185