Daily updates from Odoo
Wednesday, February 4, 2026
76 changes
25 changes
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#1052254 changes
Resolved issues and error corrections
This update resolves an issue where salary attachments would display an empty employee field after an employee was archived. The fix ensures that salary attachments continue to link to employees, even after they've been archived, improving data accuracy and reporting.
Original PR description
Steps To Reproduce: Create a salary attachment for an employee. Archive that employee. The corresponding salary attachment has an empty `Employee`. Issue: `employee_ids` many2many field doesn't take archived records into consideration, So when an employee is archived, it leads to emptying the record. Fix: Add active_test context to field definition and domain to form view of salary attachment so the employee remains on salary attachment and for new record creation, so it doesn't take archived employees. task-5438657 Forward-Port-Of: odoo/enterprise#106275 Forward-Port-Of: odoo/enterprise#102985
This update resolves an issue where uploading a new signature PDF would fail if the 'signature' item type (ID 1) was deleted. The problem stemmed from a recent change that created a dummy item to track roles, leading to an error when no item type was found. This fix ensures a smoother sign upload process.
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 an issue where the fuel card benefit was incorrectly enabled in the salary configurator when no company car was chosen. The fix ensures the field is initially disabled and remains so until a company car is selected, preventing data inconsistencies and simplifying the user experience. This improves data accuracy and reduces potential errors.
Original PR description
On first load of the salary configurator, the fuel-card benefit could appear enabled even when no company car was selected. The dependency logic reacted to in-page changes but did not initialize the field correctly on page load. Initialize the fuel-card field from the current car selection and keep it non-selectable until a car is chosen to prevent inconsistent packages. task-5156562 Forward-Port-Of: odoo/enterprise#97119
This update corrects an issue where project forms accessed through SmartButtons were initially displayed as uneditable. The team removed a setting that was causing this behavior, which was unexpectedly added. This ensures all project forms are correctly editable within Odoo.
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#10522511 changes
Resolved issues and error corrections
This update fixes an issue where the description field in the calendar popover wasn't wrapping text properly, leading to truncated information. The team added the 'text-wrap' class to the calendar view, ensuring descriptions are displayed cleanly and completely within the popover. This improves the user experience by providing full access to calendar event details.
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#246924
This update addresses an issue where a previously implemented tour was causing instability in nightly builds. The fix replaced the original tour with a more reliable version, resolving a recent set of errors and improving the overall stability of the MRP module.
Original PR description
Issue ----- The tour added in commit 6927265 was failing in nightly. The attempted fix in 246bf1d resolved the first problem but raised some new non-deterministic issues. ----- Errors 237956, 238469 & 238470
This update resolves a bug where images added to email templates were unexpectedly deleted upon saving. The issue stemmed from a problem with how the email editor tracked changes, leading to incorrect history management. The fix ensures images are correctly saved and re-added without being removed.
Original PR description
**Steps to reproduce:** - Install Email Marketing app - Create a new campaign with Subject and Recipients - Set plain text mail body - Add one image using /img or /image command - Save the template -…
**Steps to reproduce:**
- Install Email Marketing app
- Create a new campaign with Subject and Recipients
- Set plain text mail body
- Add one image using /img or /image command
- Save the template
- Remove the image
- Save the template
- Try to re-add an image, on save it will be deleted everytime
**Issue:**
During `commitChanges`, the history of the editor is in a wrong state which triggers a cleanup on
`this.wysiwyg.odooEditor.historyRevertCurrentStep();`.
This is caused by the `await saveCallback(element);` of `_onMediaDialogSave` which never resolve and never call its follow-up:
```js
this.odooEditor.historyUnpauseSteps();
this.odooEditor.historyStep();
```
The resolve is event-dependent and doesn't seem to be triggered in current versions:
`const event = $.Event("image_changed", {_complete: resolve});`
**Fix:**
Check that the current element is listening to the given event.
Might not be the proper fix as I wasn't able to reproduce the expected behavior with `image_changed` event.
related PR: https://github.com/odoo/odoo/pull/205594
opw-5245367
Forward-Port-Of: odoo/odoo#244396This update streamlines Odoo tests by disabling unnecessary device checks during testing. Previously, tests triggered frequent queries to detect device information, slowing down the testing process. This change improves test execution speed and efficiency without impacting core functionality.
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 ensures that users are always notified when they are mentioned in a sub-channel, regardless of their membership status. Previously, users wouldn't see sub-channels where they were mentioned but weren't members. This fix prevents missed notifications and improves communication within teams.
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#246423 Forward-Port-Of: odoo/odoo#237538
This update resolves an issue where salary attachments would display an empty employee field after an employee was archived. The fix ensures that salary attachments continue to link to employees, even after they've been archived, improving data accuracy and reporting.
Original PR description
Steps To Reproduce: Create a salary attachment for an employee. Archive that employee. The corresponding salary attachment has an empty `Employee`. Issue: `employee_ids` many2many field doesn't take archived records into consideration, So when an employee is archived, it leads to emptying the record. Fix: Add active_test context to field definition and domain to form view of salary attachment so the employee remains on salary attachment and for new record creation, so it doesn't take archived employees. task-5438657 Forward-Port-Of: odoo/enterprise#106275 Forward-Port-Of: odoo/enterprise#102985
This update corrects a bug in the salary configurator where the fuel card benefit would incorrectly appear enabled if no company car was selected. The fix ensures the field is properly initialized on initial load, preventing inconsistent data and ensuring the correct benefit options are displayed.
Original PR description
On first load of the salary configurator, the fuel-card benefit could appear enabled even when no company car was selected. The dependency logic reacted to in-page changes but did not initialize the field correctly on page load. Initialize the fuel-card field from the current car selection and keep it non-selectable until a car is chosen to prevent inconsistent packages. task-5156562 Forward-Port-Of: odoo/enterprise#97119
This update resolves a bug in the Odoo 18.3 website sale subscription test. The test was failing to correctly enable pricelists. A simple code change was made to the test itself to ensure pricelists are properly activated, improving test reliability.
Original PR description
In the current 18.3 configuration, the test for pricelists fails to properly enable the feature when initialising the test class. Added a write call enabling the feature to the test code itself. runbot error [222878](https://runbot.odoo.com/odoo/error/222878)
This update fixes an issue where the FAIA report incorrectly classified partners as suppliers instead of customers, particularly when credit notes were involved. The change allows partners to be correctly identified as both customers and suppliers, ensuring accurate reporting of financial balances. This resolves a discrepancy impacting the SAFT report generation.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create…
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924 Forward-Port-Of: odoo/enterprise#105893 Forward-Port-Of: odoo/enterprise#100749
This update resolves a bug that incorrectly flagged miscellaneous entries without deferred dates as incompatible with different entry generation methods. The fix ensures validation only applies when deferred dates are actually configured, improving usability for users managing general operations. This prevents unnecessary errors and streamlines the posting process.
Original PR description
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc…
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured. https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151 Steps To Reproduce: 1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped". 2. Go to Accounting Dashboard and create a new Miscellaneous Operation. 3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries). 4. Try to post the entry. 5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..." The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types. Commit that caused the issue: https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b Ticket [link](https://www.odoo.com/odoo/project.task/5486114) opw-5486114
This update corrects an issue where project forms accessed through SmartButtons were initially displayed as uneditable. The team removed a technical setting that was causing this behavior, ensuring all project forms now function correctly. This resolves a usability problem for users.
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#1052253 changes
Resolved issues and error corrections
This update resolves an issue where salary attachments would display an empty employee field after an employee was archived. The fix ensures that salary attachments accurately reflect the current employee status, preventing data inconsistencies and improving reporting accuracy. This change was made to maintain data integrity within the payroll system.
Original PR description
Steps To Reproduce: Create a salary attachment for an employee. Archive that employee. The corresponding salary attachment has an empty `Employee`. Issue: `employee_ids` many2many field doesn't take archived records into consideration, So when an employee is archived, it leads to emptying the record. Fix: Add active_test context to field definition and domain to form view of salary attachment so the employee remains on salary attachment and for new record creation, so it doesn't take archived employees. task-5438657 Forward-Port-Of: odoo/enterprise#106275 Forward-Port-Of: odoo/enterprise#102985
This update resolves an issue where the fuel card benefit was incorrectly enabled in the salary configurator when no company car was selected. The fix ensures the field is initially disabled until a car is chosen, preventing inconsistencies and simplifying the user experience. This improves data accuracy and reduces potential errors.
Original PR description
On first load of the salary configurator, the fuel-card benefit could appear enabled even when no company car was selected. The dependency logic reacted to in-page changes but did not initialize the field correctly on page load. Initialize the fuel-card field from the current car selection and keep it non-selectable until a car is chosen to prevent inconsistent packages. task-5156562 Forward-Port-Of: odoo/enterprise#97119
This update corrects an issue where project forms accessed through SmartButtons were initially displayed as uneditable. The fix removed a redundant setting that was causing this behavior, ensuring users can now properly interact with project forms. The root cause of the original 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#1052257 changes
Resolved issues and error corrections
This update resolves an issue where opening reports would cause a crash if a report action was triggered before the report data was fully loaded. The fix ensures that report actions can be reliably used during the report loading process, improving user experience and preventing unexpected errors.
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 prevents documents from automatically opening in a form view when accessed through various channels like direct links or systray notifications. Previously, users were unexpectedly directed to the document's form view, which has now been corrected to provide a smoother and more intuitive experience. This change improves usability and aligns with user expectations.
Original PR description
Users do not want to access the form view of the document by default. This PR solves three cases for accessing documents.document records that were not covered before: * From the basic path pattern `odoo/x/documents.document/<id>` * From a systray notification "Open Form View" * when we are not yet in Documents * when we already are in Documents * From the Discuss app, on the record's thread Tests for most of these are included. Additionally, make sure the document is selected on accessing from `_get_access_action`. Task-5386466 Forward-Port-Of: odoo/enterprise#106214 Forward-Port-Of: odoo/enterprise#104622
This update corrects an issue where uploading a new signature PDF would fail if the 'signature' item type (ID 1) was deleted. The problem stemmed from a recent change that created a dummy item for role recognition, leading to an error when no item type matched. This fix ensures smooth PDF uploads for signature creation.
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 an issue where IoT reports generated from Point of Sale (PoS) were failing due to PoS using incorrect identifiers. The fix filters out reports that don't use integer IDs, specifically those using string UUIDs, as these are not needed for PDF report generation. This ensures reliable report printing.
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 websites extract content, specifically addressing problems with robots.txt checks and content cleaning. The changes ensure accurate data collection from Odoo websites by refining noise removal and preventing errors in content extraction logic.
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 fixes an issue where malformed PDFs caused errors during the signature process. The system now attempts a more lenient PDF parsing method if the initial attempt fails, ensuring signatures can be processed more reliably. This improves the overall stability and functionality of the signature workflow.
Original PR description
Before this commit, opening some malformed PDFs failed during flattening because PyPDF2 strict parsing and form-field reads raised errors. After this commit, we try first parsing the PDF in the usual way and if we fail, we try again with strict=False. See https://pypdf.readthedocs.io/en/stable/user/robustness.html. task-5902859
The Odoo portal payment screen now displays a warning message when no payment providers are available, preventing the screen from scrolling to the bottom. This ensures users receive clear guidance and avoids a confusing user experience when payment options are unavailable. This resolves a previous issue where users didn't see any payment methods or warnings.
Original PR description
The portal payment screen incorrectly scrolls to the bottom when the Pay button is clicked, but no payment methods or warning message are shown. This happens when no payment provider is published. This PR fixes the issue by ensuring the "no provider" warning message appears in all cases. task-5388313 Forward-Port-Of: odoo/enterprise#101632
11 changes
Resolved issues and error corrections
This update resolves an issue where salary attachments would display an empty employee field after an employee was archived. The fix ensures that salary attachments accurately reflect the current employee status, preventing data inconsistencies and improving reporting accuracy. This change maintains data integrity for payroll records.
Original PR description
Steps To Reproduce: Create a salary attachment for an employee. Archive that employee. The corresponding salary attachment has an empty `Employee`. Issue: `employee_ids` many2many field doesn't take archived records into consideration, So when an employee is archived, it leads to emptying the record. Fix: Add active_test context to field definition and domain to form view of salary attachment so the employee remains on salary attachment and for new record creation, so it doesn't take archived employees. task-5438657 Forward-Port-Of: odoo/enterprise#106275 Forward-Port-Of: odoo/enterprise#102985
This update resolves an issue where uploading a new signature PDF would fail if the 'signature' item type (ID 1) was deleted. The problem stemmed from a previous change that created a dummy item to identify roles, leading to an error when no item type was found. This fix ensures a smooth sign upload process.
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 preventing users from viewing the package status for Lazada orders within picking and sale orders. The fix grants necessary access to the `lazada.order.item` model, which was previously restricted to 'Sales Administrator' users. This ensures all users can see the correct Lazada order information.
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.
This update resolves an issue where lengthy reconciled names on bank statements were being displayed as a long list of commas. The fix involves repositioning a text truncation element, resulting in a cleaner and more readable statement line display for users. This improves the overall user experience.
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#105674
Before this commit, opening some malformed PDF failed during flattening because PyPDF2 strict parsing and form-field reads raised errors. After this commit, we try first parsing the PDF in the usual way and if we fail, we try again with strict=False. See https://pypdf.readthedocs.io/en/stable/user/robustness.html. task-5902859
Original PR description
Before this commit, opening some malformed PDF failed during flattening because PyPDF2 strict parsing and form-field reads raised errors. After this commit, we try first parsing the PDF in the usual way and if we fail, we try again with strict=False. See https://pypdf.readthedocs.io/en/stable/user/robustness.html. task-5902859
This update resolves an issue where the printer selection wizard could generate errors when attempting to use printers that had been removed from the database. By filtering out printers without corresponding devices, the system now avoids these errors, ensuring a smoother user experience.
Original PR description
Printers saved by the selection wizard in local storage can correspond to records that no longer exist in the database (removed in the meantime). To avoid a traceback when creating the wizard with non- existing printers, we filter out the ones that don't correspond to any device.
This update fixes an issue where recurring prices on ecommerce product pages used incorrect grammar, specifically displaying billing periods in singular form. The change ensures that recurring prices always use the correct plural form, resulting in a more professional and user-friendly experience for customers.
Original PR description
Issue: - On ecommerce product pages, recurring prices displayed incorrect grammar. - Billing periods greater than one were shown in singular form (e.g. 'Every 6 month' instead of 'Every 6 months'). Fix: - Updated recurring price display logic to use plural period labels when the billing period value is greater than one. Impact: - Recurring prices now display correct and user-friendly grammar. taskid-5529937
This update fixes an issue causing payment terminal receipt text to display with unwanted styling (borders and light/dark mode). The fix removes a specific CSS file that was incorrectly applied to the POS, ensuring a cleaner and more professional receipt appearance. This improves the user experience for customers using the point-of-sale system.
Original PR description
The `pos_appointment` module includes all of the `html_editor` assets into POS, despite only a small subset of the functionality being used. One of these assets was an SCSS file that set code block styling on all `pre` elements. Since the POS uses `pre` elements to display the text from payment terminals on the receipt, it was causing this text to be drawn with a border box and light/dark mode styling. The fix is to remove this specific SCSS file from the POS bundle. It shouldn't affect `pos_appointment` functionality since the code editing plugin is not loaded. Before: <img width="325" height="694" alt="image" src="https://github.com/user-attachments/assets/1c23ee18-0832-496f-b69e-8d9e90b5ed73" /> After: <img width="337" height="700" alt="image" src="https://github.com/user-attachments/assets/2998e66f-c582-422b-b3c7-31bcb849e75b" />
This update resolves an issue where users with only sales access couldn't view invoices. The fix grants the 'salesman' group the necessary read permissions to the asset data, allowing them to correctly access and manage invoices within the Enterprise module. This ensures sales teams have full visibility into related financial transactions.
Original PR description
### Issue: User with sale access group cannot access invoices. #### Steps to reproduce: - Install demo data - In user setting, `Access Rights` tab, remove `Accounting` access and set `Sale` access to Administrator for user Demo. - Log in using Demo user. - Create a SO, and after confirming, create an invoice. - As you see, you will get access rights error. ### Cause: Group salesman doesn't have `read` access on `account.asset`. As a result on enterprise, `account.move._compute_asset_ids` fails: https://github.com/odoo/enterprise/blob/c366abe1d3423d5e184675b5fb786b5f401ae94f/account_asset/models/account_move.py#L320 Community PR: odoo/odoo#242516 Ticket [link](https://www.odoo.com/odoo/project.task/5461135) opw-5461135
This update fixes an issue where the employee's filling status wasn't updating correctly when the associated address state was changed. The system now dynamically adjusts the filling status based on the employee's working address location, ensuring accurate payroll calculations for states like Alabama. This resolves a discrepancy in state-based filling status updates.
Original PR description
to reproduce: ============= - create employee and set working address with state in CA - set filling status to match the state - in the address record change the state to AL (don't change the record in employee) - go back to employee form view, filling status is still the same problem: ======== currently we are relying on a constraint to check if the filling status is valid for the state in the working address. But `api.constrains` doesn't support dotted paths, so modifying `address_id.state_id` doesn't trigger it. solution: ========= make the filling status computated field depending on `address_id.state_id` opw-5878740
This update adjusts the way product prices are stored within Odoo, ensuring greater accuracy and consistency. The change addresses a technical issue identified in previous testing, improving the reliability of price calculations. This update primarily impacts the core functionality of product management.
Original PR description
Fix tests, related to https://github.com/odoo/odoo/pull/243987 task-4895014 Forward-Port-Of: odoo/enterprise#106203 Forward-Port-Of: odoo/enterprise#104728
10 changes
Resolved issues and error corrections
This update fixes a problem where automated tests relied on specific demo data, causing inconsistent results. The change ensures tests always use a consistent partner for searching, improving the reliability of our automated testing process. This enhances the overall stability and predictability of our website sales functionality.
Original PR description
As part of the forward part for [1] the shop mail tour was updated because the new demo partner was earlier alphabetically than the partner generated for the test, and tests run with demo data for CI in this version. The test should create a partner that will appear first in the m2o selection regardless of whether demo data is installed. [1]: 549708965924b17403ef7c8e6a6d5bc43af460c3 runbot-238406 Forward-Port-Of: odoo/odoo#245753
This update resolves a test failure in the restaurant POS booking process. The fix replaces a method used for general loading with one specifically designed to wait for RPC requests, ensuring the tour accurately reflects the system's behavior when booking and releasing tables. This improves the reliability of the test and the overall booking experience.
Original PR description
Fix failing tour `test_book_and_release_table` by replacing `waitForLoading`, which is intended for POS loading, with `waitRequest` to properly wait for RPC requests. Error-227652 Task-5897383
This update fixes an issue where vendor bill labels on payable lines were not correctly populated when the Payment Reference was empty. Now, the payable line label automatically displays the Bill Reference when no Payment Reference is provided, and updates accordingly when the Payment Reference is changed. This ensures accurate labeling of vendor bills for better reporting and reconciliation.
Original PR description
Before PR: - On vendor bills and refunds, if the Payment Reference is empty, a placeholder saying `Use Bill Reference` is shown. But the Bill reference is still not written on the Payable line, making the label empty. - When Payment Reference is set, updating the Payment Reference does not update the payable line label. After PR: - The payable line label is now populated with the Bill Reference when the Payment Reference is empty. - Now, when Payment Reference is set, updating the Payment Reference updates the payable line label. - Modified the test cases which were failing due to an empty label. Related PR (Enterprise) : https://github.com/odoo/enterprise/pull/91535 Task : 4982864
This update replaces the SFU (Server-Side File Upload) bundle with version 1.3.3, addressing a technical update to improve the performance and stability of file uploads within Odoo. This change ensures continued optimal functionality for users uploading and managing files.
Original PR description
https://github.com/odoo/sfu/releases/tag/v1.3.3 Forward-Port-Of: odoo/odoo#244971
This update resolves an issue where the POS ID wasn't being correctly transmitted to the blackbox during v1 CleanCash integration. The fix ensures accurate data transmission, improving the reliability of the fiscal data reporting process. Additionally, a security enhancement restricts blackbox device selection to the Fiscal Data Module in POS configuration settings.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448
This update resolves an issue where tickets in 'folded' (closed) stages were incorrectly displayed in the helpdesk email plugin. The fix ensures that closed tickets are filtered out, preventing them from appearing in the plugin's results and improving the user experience. This ensures users only see active tickets.
Original PR description
**Steps to reproduce:** - Install Mail_plugin - Setup the outlook mail plugin in Outlook - Once connected, click on a mail from a contact on the database - Click on the Odoo Inbox Addin. action - Under the contact 5 related tickets are showed - Create 5 tickets with priority and put them in folded stage (closed) - Create new normal tickets - User can't see new tickets in the plugin **Issue:** The search is done on priority and then id ordering, this means that tickets in folded stages (closed) which have a high priority are always showed first. Tickets in a folded stage are considered as closed, so they should not appear anymore in the contact data to avoid displaying them indefintely. **Fix:** Adapted search domain and removed fold attribute in the answer. opw-5075477
This update resolves a problem with Indian GST reports where test cases were failing due to a recent change in how payable lines are labeled. The test cases have been updated to now correctly account for the new label format that includes the bill reference, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864
A bug was causing incorrect order quantities to be sent to the kitchen when using the numpad in the POS Restaurant Preparation Display module. This was resolved by adding a brief delay to ensure the quantity is updated before the order is submitted, preventing errors in the kitchen display.
Original PR description
TASK: [#5897381](https://www.odoo.com/odoo/project/1737/tasks/5897381) --- Inside tour tests environment for POS Restaurant Preparation Display module, when using the numpad to change the quantity of a product in the POS and sending the order to the kitchen immediately after, there is a chance that the quantity is not updated in time. This could lead to sending an order with an incorrect quantity to the kitchen display. As a result, the test `test_payment_does_not_cancel_display_orders` was failing. We add a small delay after using the numpad to ensure the quantity is updated before sending the order.
This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems on their end. The change now excludes these zero-price products from the sync process, ensuring smoother integration with UrbanPiper and preventing potential errors.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272
This update fixes an issue in the French P&L report where accounts 65 were incorrectly categorized. The accounts have been moved to the 'Other Expenses' line, ensuring accurate financial reporting and alignment with French accounting standards. This improves the clarity and reliability of the financial data.
Original PR description
On the french P&L, accounts 65 are refferenced in the line 'Other purchases and external charges' but this is not where those accounts need to be, they need to be part of the line 'Other Expenses' task-5446018 Forward-Port-Of: odoo/enterprise#103357
5 changes
Resolved issues and error corrections
This update fixes a tax code error for 0% EU S transactions in Italy. The code was incorrectly assigned based on whether the transaction was for goods or services. This change ensures accurate tax calculations for intra-community supplies, aligning with Italian tax regulations.
Original PR description
In Italy, the code depends strictly on whether the transaction is for Goods or Services. N3.2 is for Intra-community supply of GOODS (Cessioni Intracomunitarie di beni) N2.1 is for Intra-community supply of SERVICES (Prestazioni di Servizi) This commit fixes the exoneration code on the 0% EU S tax from N3.2 to N2.1. task-5870894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where a duplicate skill was incorrectly added to an employee's resume after a validation error occurred during skill selection. The fix ensures that changes to the virtual record are discarded when a validation error is triggered, preventing unintended skill additions and maintaining data integrity.
Original PR description
Steps to reproduce: --------------------------------- 1. Install `hr_skills` module 2. Open the Employees app and open any employee record 3. Go to the Resume tab 4. In the Skills section, click Add…
Steps to reproduce: --------------------------------- 1. Install `hr_skills` module 2. Open the Employees app and open any employee record 3. Go to the Resume tab 4. In the Skills section, click Add for any skill type 5. Select a skill that is already added to the resume 6. Click Save & Close in the Select Skills wizard 7. A validation error is displayed, click Close 8. Close the Select Skills wizard. Observation: --------------------------------- After closing the wizard, another default skill is added to the resume even though a validation error was raised. Issue: --------------------------------- In the following code: https://github.com/odoo/odoo/blob/57c1c510425dcd491c794a0262063db398348640/addons/hr_skills/static/src/fields/skills_one2many/skills_one2many.js#L79-L82 During record save, the validation error scenario was not handled properly. When a validation error occurred, changes made to the virtual record were not discarded, causing the initial (invalid) changes to be incorrectly retained instead of being rolled back Solution: --------------------------------- When a validation error occurs while adding a skill, discard all changes made to the virtual record before throwing the error. This ensures that no unintended skill is added. opw-5423196
This update resolves an issue preventing portal users from downloading slides documents when using a CDN. Previously, a login requirement on the CDN blocked access. The fix adds a new route to ensure slides can be accessed via CDN, aligning with documented CDN configurations and expected public content availability.
Original PR description
Currently if you have a cdn configured to the route '/web/content' and you try to download files in a e-learning course as a portal user, you won't be able to. You get a not found error instead since you are not logged in in the cdn server, so no access to the resource. Given that configuring a cdn to this route is in our documentation and that other contents on that route are expected to be public (so available trough cdn) this is unexpected behaviour. This adds a route to slides that calls the same method as the old one, so that you can cdn that route and this will still work opw-4918546
This update fixes an issue where text in the checkout card was difficult to read on mobile devices when a dark website background was used. The change adjusts color contrast for muted text, ensuring all amounts (Subtotal, Taxes, Total) are clearly visible regardless of the background color. This improves the user experience and prevents potential confusion during the checkout process.
Original PR description
Prior to this commit, when a dark background color was defined, some text elements in the checkout card were not readable on mobile. Steps to reproduce: - Switch the website background to a dark color. - Add a product to the cart. - Go to the cart checkout page. - Switch to mobile view. - Observe the text next to the amounts (Subtotal, Taxes, Total) inside the cart summary card. This commit adjusts the colors of muted text inside the checkout card to ensure sufficient contrast, regardless of the background color. task-5881568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in the French Profit & Loss report where accounts 65 were incorrectly categorized. They have now been moved to the 'Other Expenses' line, ensuring accurate financial reporting and alignment with French accounting standards. This improves the clarity and reliability of financial data for French users.
Original PR description
On the french P&L, accounts 65 are refferenced in the line 'Other purchases and external charges' but this is not where those accounts need to be, they need to be part of the line 'Other Expenses' task-5446018