Wednesday, February 4, 2026
25 changes · saas-19.1
Resolved issues and error corrections
This update resolves an error that occurred when users created reminders in the calendar module. The issue stemmed from a recent change in how selection fields are handled, specifically when clearing the 'Type' field. This fix ensures the system correctly processes this action, preventing the error and allowing users to successfully create reminders.
Original PR description
Currently, an error occurs when user creates a reminder. **Steps to Reproduce:** - Install the `calendar` module. - Go to `Calendar` > `Configuration` > `Reminders`. - Create a `new reminder` and…
Currently, an error occurs when user creates a reminder.
**Steps to Reproduce:**
- Install the `calendar` module.
- Go to `Calendar` > `Configuration` > `Reminders`.
- Create a `new reminder` and clear the `Type` field.
`KeyError: False`
**Cause**:
- Error started occurring in 19.0 due to a change in selection field behavior. Since change https://github.com/odoo/odoo/pull/214422/commits/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef, selection fields no longer display an “empty” value.
- To remove a value from a selection field, the user must clear the field, similar to a many2one field.
- When the Type field is cleared, its value becomes False, which raise the error here [1].
**Fix:**
- This commit ensures that when the alarm type is False, display_alarm_type is set to an empty value
similar to the display interval [2].
- Since both fields are required, once they are set again, the correct name is computed accordingly.
[1]: https://github.com/odoo/odoo/blob/2ee2f7678ed262036ee8cf8719ceafd3d69d4062/addons/calendar/models/calendar_alarm.py#L72-L74
[2]: https://github.com/odoo/odoo/blob/97e90f14ea40e4dc8645f845ef78eb579bb3e8dc/addons/calendar/models/calendar_alarm.py#L71
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243526This update fixes an issue where the loyalty program button was incorrectly highlighted when rewards weren't available. Now, the button will only appear if the user has valid rewards, providing a cleaner and more accurate representation of the loyalty program options for customers.
Original PR description
Before this commit: ========= - The more control button was being highlighted even if rewards were not available. After this commit: ========= - The more control button will be highlighted if only valid rewards are there. task-5438708 Forward-Port-Of: odoo/odoo#241976
This update fixes a visual inconsistency in video link previews, specifically for YouTube videos. Previously, thumbnails left blank spaces, resulting in a broken layout. Now, thumbnails consistently fill the container, ensuring a uniform and professional appearance for all video previews.
Original PR description
**Purpose of this PR:** Before this commit, video thumbnails from youtube left blank spaces in the container, creating inconsistent layouts across different video links. After this commit, thumbnails consistently fill the entire container, ensuring uniform appearance for all video link previews. **Before/After:** <img width="533" height="407" alt="image" src="https://github.com/user-attachments/assets/ce2ba872-27b7-4be5-9d85-fbbe6f272e14" /> <img width="481" height="386" alt="image" src="https://github.com/user-attachments/assets/523f5d16-2983-49c1-9dcc-01adb4284e56" /> task-5424534 Forward-Port-Of: odoo/odoo#246856 Forward-Port-Of: odoo/odoo#244176
This update corrects a random test failure related to how Odoo's datetime fields are rendered in editable list views. The fix ensures consistent rendering of the date picker, preventing unexpected UI behavior. This improves the stability and reliability of the web application.
Original PR description
This commit fixes two unit tests involving the datetime field which are randomly failing since [1]. In the first one, we add a record in an editable list view. The first field is automatically…
This commit fixes two unit tests involving the datetime field which are randomly failing since [1].
In the first one, we add a record in an editable list view. The first field is automatically focused (in `onMounted`). Before this commit, the first field was the datetime. When it is focused, the datetime field re-renders itself (from a `<button>` to an `<input>` with datepicker). The test failed when those two renderings were done within the same animationFrame, which was rare but possible. We fix the test by moving `foo` field before `date`, that way, the date field is never focused, and we can properly assert the default date value.
In the second one, again in an editable list, we select a date in the picker, and we then assert that the field is rendered with a `<button>` whose text is correct. The test sometimes failed because there was no button (the field was still displaying an `<input>`). When the value is selected, an update is done in the model, which triggers a re-rendering. At that moment, the picker still states that there's an `activeInput` ("date"), so the field is rendered with an input. The picker state is only updated afterwards, so there's another rendering, where `picker.activeInput` is "", which leads to the expected `<button>` being rendered. However, that rendering can happen in another animationFrame, thus triggering the issue. This commit fixes it by simply waiting for the button to be displayed.
[1] https://github.com/odoo/odoo/pull/218387
runbot error-238437 (1)
runbot error-238758 (2)
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#247026This update fixes a technical issue that prevented loyalty rewards from applying correctly when associated products were archived or invalid. The system now intelligently skips loading these rewards, ensuring a smoother and more reliable experience for users. This improves the overall stability of the POS loyalty program.
Original PR description
Steps: --------- - Install pos_loyalty. - Add a product to a loyalty reward’s reward product, or assign a product tag with no actual products as a reward product tag. - Archive/delete the reward product. - Open session. Issue: ---------- - A traceback appears when attempting to apply the affected reward, due to the archived/deleted or invalid reward product is being loaded in the POS. FIX: ----------- - Skip loading loyalty rewards whose reward product is archived/deleted or whose reward product tag contains no valid products. Task-5226654 Forward-Port-Of: odoo/odoo#242776 Forward-Port-Of: odoo/odoo#235081
This update resolves a slow loading issue for custom fonts on the Odoo website, particularly when users upload large images. The change optimizes a key process to reduce the time it takes to apply custom fonts, improving the user experience and preventing timeouts.
Original PR description
Steps: - Install `website` - Open website editor - Themes -> Font Family -> Add a Custom font - Choose a random font from the list - Uncheck "Serve font from Google servers" - Save and Reload - Timeout in case of *.odoo.com because it can take a very long time (more than two minutes) This commit improves `make_scss_customization`, because there is a regex that scans the file several times to find the user_values.scss hook in our case. This regex can easily be improved by checking only the beginning of lines after spaces instead of checking all characters. from ```py updatedFileContent = re.sub(r'( *)(.*hook.*)', r'\1%s\1\2' % replacement, updatedFileContent) ``` to ```py updatedFileContent = re.sub(r'^( *)(.*hook.*)', r'\1%s\1\2' % replacement, updatedFileContent, count=1, flags=re.MULTILINE) ``` opw-5178930 Forward-Port-Of: odoo/odoo#245907
This update fixes a validation error preventing employees from requesting time off when using a 2-week calendar schedule. The issue stemmed from visual calendar lines used for formatting that were incorrectly impacting date calculations. This change ensures accurate PTO requests are processed for all calendar types.
Original PR description
Steps to reproduce: - Choose France as the company location, and download "France - Work Entries Time Off" module. - From Employees > Configuration > Settings > French Time Off Localization, select…
Steps to reproduce: - Choose France as the company location, and download "France - Work Entries Time Off" module. - From Employees > Configuration > Settings > French Time Off Localization, select Paid time Off. - Create a new employee and a new contract (in running state) for that employee that starts on 01/01/2025. - While in the contract screen, create a new schedule that has 2 weeks calendar and Europe/Paris timezone. - From Time Off > Management > Allocations, allocate 1+ paid time off days for the newly created employee that's valid from 01/01/2025. - From the employee's profile > Time Off, try to take a Monday off. Issue: - The user gets a Validation error stating that the "start date" is later than the "end date". Fix: - In a 2 weeks calendar, there are 2 lines that are there to separate the first week from the second week (for aesthetic purposes). These lines have "hour_from" and "hour_to" = 0, which are taken into account when calulating the minimum hour to start the day off. - Add a check to remove lines from calendar that are just there for display purposes. opw-5387347 Forward-Port-Of: odoo/odoo#246565 Forward-Port-Of: odoo/odoo#246094
This update streamlines Odoo tests by disabling unnecessary device checks during testing. Previously, tests triggered frequent queries to detect device changes, slowing down the testing process. This fix improves test performance and efficiency without impacting the core functionality of Odoo.
Original PR description
In tests, when using `authenticate`, we create a session. When this session is retrieved (for example because we use `url_open`), we detect a new device and insert a log. The consequence is that a query is performed in many tests and that is not necessary. The fix consists of disabling the `res.device.log` feature by default in tests. task-5894825 Forward-Port-Of: odoo/odoo#246445
This update resolves an issue where a specific filter in the Accounting app was failing due to an unsupported operator ('any') in how it searched for analytic distribution accounts. The change converts 'any' to 'in' and 'not any' to 'not in', aligning with standard relational field behavior and ensuring the filter works correctly. This prevents errors and allows users to accurately filter journal items based on their analytic distribution.
Original PR description
`distribution_analytic_account_ids` is a virtual relational field backed by the `JSON` field `analytic_distribution`. Its custom search method did not handle the `any` / `not any` operators, causing…
`distribution_analytic_account_ids` is a virtual relational field backed by the `JSON` field `analytic_distribution`. Its custom search method did not handle the `any` / `not any` operators, causing domains like:
```py
('distribution_analytic_account_ids', 'any', <analytic.account domain>)
```
to fail during domain optimization with errors such as:
```py
ValueError: Cannot use 'any' with non-relational fields in condition ('analytic_distribution', 'any', [('plan_id', 'in', [2])])
```
This commit adds support for relational semantics in `_search_distribution_analytic_account_ids` by resolving the RHS domain on `account.analytic.account` into ids and converting:
- `any` → `in`
- `not any` → `not in`
This aligns the behavior with relational field expectations while keeping the logic at the field search level instead of modifying domain internals.
**Steps to reproduce:**
- Created a `v19` db and install Accounting app
- Navigate to `journal items` menu
- Add the custom filter: `[("distribution_analytic_account_ids.plan_id", "in", [2])]`
- In logs you will see:
```py
ValueError: Cannot use 'any' with non-relational fields in condition ('analytic_distribution', 'any', [('plan_id', 'in', [2])])
```
- In UI it will pop up domain is invalid.
opw-5875337
upg-3855669
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246965This update corrects a technical issue where overtime calculations were imprecise due to storing minutes as 'minute and twelve seconds'. This change ensures more accurate overtime totals, particularly when processing large attendance records for reporting and balance calculations. It improves the reliability of our HR data.
Original PR description
### Current behavior: Overtime hours are stored with a two-decimal point precision. This means a minute is stored as a minute and twelve seconds in the worst case, which would amplify the overtime given or taken on a particular attendance. This is problematic when aggregating the records for large datasets to compute the balance or for reporting ### Expected behavior: A minute should be stored closer to its real decimal value to minimize the error in aggregations as a minute and 1.2 seconds opw-5422827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244962
This update resolves an issue where the website preview would briefly delay after a hover, causing a slight lag for users. The fix ensures previews revert instantly as text is typed, preventing data loss. This enhancement improves the overall user experience when customizing website elements.
Original PR description
With commit aa3a2a694930d077aab5ff55e72655cc453a64ff, the delay of one animation frame in the preview of `templatePreviewableWebsiteConfig` is not necessary anymore. This was the only preview with a delay that can be triggered by hovering a button (the others needs to open a dropdown or input in text field). With commit be032732d1f5d1f7b28da3fa7bf19bffbef4a46d, previews are reverted as soon as the user starts typing, to avoid loosing the typed text when the preview is reverted. But this does not handle completely previews that are async: they may revert just after the first character is typed, and thus loose that character. This commit eliminates async preview that can be triggered while keeping focus in the editor. task-5493193 Forward-Port-Of: odoo/odoo#243727
This update prevents a situation where users in different branches could create the same tax name. Previously, Odoo only checked for duplicates within a user's visible branches. Now, Odoo checks all branches to guarantee that tax names are unique, avoiding potential errors and data inconsistencies when managing taxes across multiple company locations.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243364 Forward-Port-Of: odoo/odoo#243185
This update fixes a bug where users weren't receiving notifications for sub-channels they were mentioned in, but weren't officially members of. The change automatically adds these users to the sub-channel, ensuring they receive pinned notifications and don't miss important updates.
Original PR description
Before this commit, when a user was mentioned in a sub-channel they were not member of, the sub-channel would not appear in their sidebar. This could lead to some missed pings. This commit fixes the issue by automatically adding mentioned users to the sub-channel, ensuring it is pinned to their sidebar. task-5233958 Forward-Port-Of: odoo/odoo#246822 Forward-Port-Of: odoo/odoo#237538
This update fixes an issue where the description field in the calendar popover wasn't wrapping text properly, causing long descriptions to overflow and be difficult to read. The change adds a 'text-wrap' class to the description field, ensuring that descriptions are displayed neatly and fully within the popover window. This improves the user experience when viewing calendar events with detailed notes.
Original PR description
Changes done: - [x] `calendar`: Add `class="text-wrap"` in the description field of the calendar view to use it in the popover - [x] `web`: Define the appropriate class in the calendar popover field **Before** <img width="548" height="428" alt="antes" src="https://github.com/user-attachments/assets/77060ee6-30a1-47ed-8ba4-d5c2baa33fe3" /> **After** <img width="559" height="627" alt="despues" src="https://github.com/user-attachments/assets/cc9dfb47-3f98-4b5b-80c2-c3e5c15df0b0" /> @Tecnativa TT60670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247111 Forward-Port-Of: odoo/odoo#246924
This update resolves a crash that occurred when users attempted to access report settings while a report was still loading. The issue stemmed from attempting to access data before it was fully available, leading to a system error. This change ensures reports load correctly and settings can be accessed without causing a crash.
Original PR description
When a report was loading if a reportAction was used and no report already was loaded before, it would crash. This happened because we tried to get the context from the data which were not yet loaded. To reproduce: - switch to debug mode (?debug=1) - add a 5s delay in _get_lines - when a report is opening, try to click on the settings cog that appear in debug mode Forward-Port-Of: odoo/enterprise#103636
This update resolves an issue where the automatic signer selection during a tour could fail, leading to incorrect assignments. By directly selecting the signer with the exact name, the system now reliably assigns signers, ensuring accurate tour execution. This fix was triggered by a test failure and improves the overall tour experience.
Original PR description
The method of clicking on the first child in the autocomplete is correct but sometimes brings about problems. In particular, if the test is too fast the search doesn't keep up, so either nothing or the wrong result gets selected. By instead choosing the child with the exact Name that we want, we ensure the correct selection. This solves the following: Runbot Error: 237717
This update corrects a bug that prevented users from uploading new PDFs to sign when the 'signature' item type (ID 1) was deleted. The issue stemmed from a recent change that created a dummy item for role recognition, leading to an error if no item type was found. This fix ensures smooth sign upload functionality.
Original PR description
steps to reproduce :
- delete the sign.item.type with id 1 ("signature")
- try to upload a new pdf to sign
The issue appears since PR 91189 that creates a dummy item to recognize roles that can be vacuumed.
Since the item type of the dummy item is irrelevant, we now just try to find the first one we can to fill in the dummy item with an Error if none is exists.
Forward-Port-Of: odoo/enterprise#106219
Forward-Port-Of: odoo/enterprise#106138This update resolves a problem where IoT reports generated from Point of Sale (PoS) were failing due to PoS using incorrect identifiers. The fix filters out reports that aren't meant to be rendered as PDFs, ensuring reliable report generation.
Original PR description
Rendering IoT reports from PoS is failing because of PoS using string uuids as `res_ids`. As they are not required to render pdf reports, we filter them out. Forward-Port-Of: odoo/enterprise#106277
This update fixes issues with how Odoo's website content is scraped, ensuring accurate data retrieval. Specifically, it addresses problems with robots.txt blocking and cleaning up unwanted website elements like popups, improving the overall quality of the website data.
Original PR description
## Fix Summary - Include the instance's base URL in internal domains to allow bypassing robots.txt checks for sites that have no domain. - Fix the scraper's cleaning logic to prevent content containers deletion edge cases on Odoo websites. - Refine noise removal for Odoo websites (popups, cookie bars, etc.). Forward-Port-Of: odoo/enterprise#106237
This update reactivated previously disabled tests related to MRP work orders, ensuring proper functionality. Specifically, tests now verify that users with limited access can still complete work orders and that the system correctly handles scenarios involving analytic accounting. The changes include a fix for a setup issue related to user creation.
Original PR description
Bring back all tests temporarily disabled by [1] `.test_mrp_aa_employee_without_account_rights` `.test_user_can_complete_workorder_despite_project_restrictions` Use lowest rights level. This explains the needed `sudo` in: `/project_mrp_workorder_account:MrpWorkcenterProductivity.write` [1] https://github.com/odoo/enterprise/commit/be6eb5e22283e952554b1bab435a7113f3061e23 Forward-Port-Of: odoo/enterprise#105626
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised: ``` Odoo Warning You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed. ``` ### Steps to reproduce: - Create a product tracked by qua
Original PR description
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an…
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised: ``` Odoo Warning You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed. ``` ### Steps to reproduce: - Create a product tracked by quantity - Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point) - Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1) - Click on Order - Open the created MO and the Shop Floor (Remove the filters to see the WO) - Complete the Quality Point - Modify the Reordering Rule (Min/Max: 2) - Click on Order - the error should be raised ### Cause: The MO to update is retrieved here: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57 Using a domain defined in this function: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153 In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor because this commit ensures that clicking a card starts the timer and changes the state to `progress`: https://github.com/odoo/enterprise/pull/84425/commits/67c2127424ef3a1eb4794edd2c262b94ef186561 However, it could still theoretically be triggered under specific conditions In 19.0, the new stock.reference system (https://github.com/odoo/odoo/pull/212679) ensures the MO is detected as different, so a new one is always created opw-5012588 Forward-Port-Of: odoo/enterprise#104158 Forward-Port-Of: odoo/enterprise#101313
This update resolves an issue preventing users from viewing Lazada order package status within Odoo. The fix grants necessary access to the 'Lazada Order Item' model for users with Sales and Inventory permissions, ensuring accurate order tracking. Users needing access should contact their administrator.
Original PR description
Versions -------- - 19.0+ Steps ----- Two issues: 1. Create a new user with `Sales "User: Own Documents Only"` rights, and `Inventory "User"`. 2. Try to access any picking or sale order. Issue ----- ``` Failed to read field stock.move.lazada_order_item_ids You are not allowed to access 'Lazada Order Item' (lazada.order.item) records. This operation is allowed for the following groups: - Sales/Administrator Contact your administrator to request access if necessary. ``` Cause ----- Both the picking form view and the sale order form view need access to the `lazada.order.item` model to display the pacakge status on Lazada. However, all Lazada specific models are only accessible with Sales "Administrator" rights. Solution -------- Add read access to `lazada.order.item` for stock and sales users. Forward-Port-Of: odoo/enterprise#105889
This update fixes an issue where lengthy reconciled names on bank statements were being displayed as a long list of commas. The change moves a key component to resolve this truncation problem, ensuring statements are displayed cleanly and accurately. This improves the user experience when reviewing financial transactions.
Original PR description
When we have a lot of reconciled names, it can happens that you just have a long list of comma. It's because the text truncate was misplaced. This commit will fix this by moving the text truncate no task id Forward-Port-Of: odoo/enterprise#106242 Forward-Port-Of: odoo/enterprise#105674
This update resolves a bug that caused incorrect schedule calculations when using planning-based work entries, particularly with material-type resources. The fix restricts schedule computations to only include employee time slots directly associated with the current employee, ensuring accurate time tracking and reporting.
Original PR description
Steps to reproduce: - Set the work entry source to planning for an employee. - Create an attendance for that employee. Issue: - Errors occurred when planning slots linked to material-type resources were included in schedule computation. Fix: - Restrict planning slots used for schedule computation to records whose employee_id belongs to self.ids. task-5476771 Forward-Port-Of: odoo/enterprise#103951
This update corrects a minor issue where project forms accessed through SmartButtons were initially displayed as uneditable. The fix removes a setting that was incorrectly preventing edits, ensuring users can now properly manage projects. The cause of this setting is currently unknown.
Original PR description
Issue: When navigating to any form view related to an FSM Project via
SmartButtons, they are loaded as uneditable
Solution: Remove "edit":False in _update_action_context method
Note: It is unknown why this was added in the first place, since
removing it does not cause any crashes
opw-5413753
Forward-Port-Of: odoo/enterprise#105225