Daily updates from Odoo
Monday, June 22, 2026
157 changes
25 changes
Resolved issues and error corrections
This update resolves an issue where focusing on the end date within a daterange widget incorrectly modified the start date. The fix ensures that the correct date field is updated when a user interacts with the input fields, improving data accuracy and reliability. This change was made to address a reported bug and enhance the user experience.
Original PR description
When a daterange widget is used (e.g., `deferred_start_date` coupled with `deferred_end_date`), focusing on the end date input was incorrectly modifying the start date field. This occurred because the `focusin` event was resolving the field name from the parent widget rather than the specific input focused. This commit updates `onFocusFieldWidget` and `getFullFieldName` to accept and evaluate the specific `event.target`. For `o_field_daterange` widgets, it now extracts the correct field name from the target's `data-field` attribute, ensuring the correct date field is updated. opw-6250048 Forward-Port-Of: odoo/enterprise#121033 Forward-Port-Of: odoo/enterprise#120684
This update clarifies the visual feedback when hovering over scrollbars in the HTML editor's syntax highlighting. Previously, a text cursor appeared, which was confusing. Now, the default cursor is displayed, providing a clearer indication that the scrollbar is for navigation only.
Original PR description
Current behavior before PR: - When a syntax highlighting block contained a scrollbar, hovering over the scrollbar displayed a text cursor. This was misleading because the text cursor suggests text interaction, while the scrollbar is only used for scrolling. Desired behavior after PR is merged: - The default cursor is now shown when hovering over the scrollbar, avoiding this confusion. task- 6295899 Forward-Port-Of: odoo/odoo#269728
This update resolves a technical issue where Odoo would crash when attempting to calculate work hours for dates without associated calendar attendance. The fix ensures that the system returns 0 hours for these dates, preventing the error and maintaining accurate time tracking.
Original PR description
If we call the method _get_duration_based_work_hours_on_date on a date we are not supposed to work and that have no resource calendar attendance linked, it will crash. This commit fixes the issue by returning 0 hours in that specific case. 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
This update fixes a limitation in the CRM Lead data enrichment process. Previously, changes made to enriched lead records couldn't be saved. Now, updated records are returned, allowing users to accurately reflect the latest information and avoid data discrepancies. This ensures data consistency and improves the reliability of CRM reporting.
Original PR description
Return the enriched records to allow overrides. task-id: 5186595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270244
This update fixes an issue where sending a chat request would automatically add users to the website live chat channel, leading to unwanted notifications. Now, sending a chat request only initiates the conversation without adding the user to the channel, improving user experience and reducing noise.
Original PR description
Sending a chat request to a visitor should not add the user to the website live chat channel. this prevents users from receiving unrelated future live chat conversations. task-6314123 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem preventing certain manufacturing tests from running correctly when only the 'mrp' module is installed. The fix ensures the necessary product routes are available during test setup, allowing for consistent and reliable testing of the manufacturing workflow. This improves the stability and accuracy of our manufacturing test suite.
Original PR description
Launch any test of the `TestMultistepManufacturingWarehouse` by installing only mrp and teh setupCalss will fail since `route_ids` is not present in the view of the `product.template` as there is no product selectable routes with only mrp installed: https://github.com/odoo/odoo/blob/66127f790ec591456c2a562b7c224f81e6ec7b57/addons/stock/views/product_views.xml#L210-L220 However, products are created and edited using the Form class in the setupClass: https://github.com/odoo/odoo/blob/66127f790ec591456c2a562b7c224f81e6ec7b57/addons/mrp/tests/test_warehouse_multistep_manufacturing.py#L22-L40 runbot-238777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270363
This update fixes an issue in the Data Recycle app where record IDs were incorrectly summed and displayed alongside group names, causing truncation and unreadability. The change removes the unnecessary aggregation of record IDs, resulting in a cleaner and more informative display when grouping records.
Original PR description
## Issue In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which: 1. truncates the name and count of the groups 2. does…
## Issue
In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)
<img width="720" height="281" alt="115492" src="https://github.com/user-attachments/assets/567902af-b356-4a0a-8b1e-2ed101a2eba3" />
## Steps to reproduce
1. Install *Data Recycle* (`data_recycle`)
2. In Data Cleaning > Configuration > Recycle Records, create a new rule:
- Any name
- Model: *Contact*
- Filter: *Name contains G* (or anything else that matches some records)
4. Click the *Run Now* button in the upper left corner
5. In Data Cleaning > Recyle Records, group the records by any field (e.g., *Model*)
6. **The name of the group (Contact) is truncated, making it and the record count unreadable. This is due to the sum of Record ID being displayed in the same row, even though that information is irrelevant.**
## Cause
Similarly to related enterprise PR https://github.com/odoo/enterprise/pull/115492, the *Record ID* field of the `data_recycle.record` model uses the default `sum` aggregator.
https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/addons/data_recycle/models/data_recycle_record.py#L17
related: https://github.com/odoo/enterprise/pull/115492
opw-6219824
Forward-Port-Of: odoo/odoo#265163This update resolves an issue in the Data Cleaning app where grouping records resulted in the record ID being incorrectly summed and displayed alongside group names, leading to truncated names and inaccurate counts. This change ensures group headers accurately reflect the number of records within each group.
Original PR description
## Issue In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which: 1. truncates the name and count of the groups 2. does…
## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)
<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />
## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
- Any name
- Model: *Contact*
- Rule:
- Field to Clean: *Name (Contact)*
- Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**
## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:
https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23
This causes the IDs to be summed up and appear in the group headers.
## After
<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />
related: https://github.com/odoo/odoo/pull/265163
opw-6166623
Forward-Port-Of: odoo/enterprise#115492This update ensures that purchase order prices correctly preserve the precision of small product costs, like those below the standard currency decimal. Previously, prices were rounded, leading to inaccurate calculations. This change aligns purchase order pricing with sales order pricing, improving data accuracy and financial reporting.
Original PR description
Commit 07da917f6e331 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased. For…
Commit 07da917f6e331 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased. For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`. However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision. This is inconsistent with sales: sale order lines preserve very small unit prices correctly. **Current behavior before PR:** A product with `standard_price = 0.001235` keeps that value on the product form. When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost. The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line. **Desired behavior after PR is merged:** Purchase order lines preserve the computed unit price precision, just like sale order lines already do. A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269413 Forward-Port-Of: odoo/odoo#267941
This update fixes an issue where product costs weren't correctly converted to the POS currency. Previously, product costs were stored in separate currencies, leading to potential inaccuracies in pricing. This change ensures all product costs are accurately converted, improving the reliability of sales data in the Point of Sale system.
Original PR description
When loading products in the POS, both the sale price and the cost were converted to the POS currency using `currency_id`. However a product stores its sale price and its cost in two potentially different currencies: `currency_id` (company currency, falling back to the main company) and `cost_currency_id` (company currency, falling back to the current company). opw-6297452 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269829
This update resolves a technical error that prevented the notification popover from displaying correctly when adding a follower to an event. The issue stemmed from a missing 'res_partner_id' field, which caused a comparison error. This fix ensures that the notification popover functions correctly for all users, regardless of whether a partner ID is present.
Original PR description
# How to reproduce - Create an Event registration - Add a follower - Click on the enveloppe icon next to the sender's name in the chatter # The problem A traceback appears # Cause of the issue When…
# How to reproduce - Create an Event registration - Add a follower - Click on the enveloppe icon next to the sender's name in the chatter # The problem A traceback appears # Cause of the issue When clicking on the enveloppe, we display the `message_notification_popover` that calls `isFollowerNotification` to filter follower notifications from other ones. This function compares the ids of the followers of the notification to it's res_partner_id : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/static/src/core/common/notification_model.js#L101-L105 But in our case res_partner_id is undefined because it is not a required field and it will not be set in the case of mass_mailing : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/models/mail_notification.py#L23-L27 opw-6178443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265263
A bug preventing users from adding cover images to Knowledge articles has been resolved. The issue stemmed from a missing callback function during the upload process, causing the upload to fail. This update ensures cover images can now be successfully added, improving the article creation workflow.
Original PR description
Steps to reproduce: 1. Install Knowledge. 2. Create an article. 3. Open the more actions menu. 4. Click "Add Cover". 5. Upload a cover image. Issue: - The upload crashes with the following traceback:…
Steps to reproduce: 1. Install Knowledge. 2. Create an article. 3. Open the more actions menu. 4. Click "Add Cover". 5. Upload a cover image. Issue: - The upload crashes with the following traceback: `Uncaught Promise > this.props.setAbortUploadsCallback is not a function` Cause: - `KnowledgeCoverSelector` extends the html_editor `ImageSelector`, whose upload flow registers an abort callback through setAbortUploadsCallback. The generic MediaDialog provides this callback, but KnowledgeCoverDialog renders KnowledgeCoverSelector directly and did not pass it. As a result, the inherited upload flow called a missing prop. Solution: - Pass setAbortUploadsCallback from KnowledgeCoverDialog to KnowledgeCoverSelector and abort pending uploads when the cover dialog is discarded. Alternative approach: - Make ImageSelector tolerate callers that do not provide setAbortUploadsCallback by calling it with optional chaining. opw-6176716 Forward-Port-Of: odoo/enterprise#120467 Forward-Port-Of: odoo/enterprise#116906
This update resolves an issue preventing correct XML export of balance sheets for Luxembourg companies (l10n_lu_reports) in version 19.3. The system now automatically includes a 'date_from' field, aligning with the updated balance sheet format introduced in 19.2, ensuring accurate financial reporting.
Original PR description
Steps to reproduce: - setup a LU company - go to balance sheet - export the xml file - validate the wizard -> Traceback, because the code expects the options to contain the date_from, which is no longer the case since 19.2 as the balance sheet has by default only a date_to. The solution is therefore to define it for the export to the beginning of the fiscal year. Forward-Port-Of: odoo/enterprise#120843
This update fixes an issue where marking a work order as 'done' multiple times caused an error. Previously, users could repeatedly set work orders to 'done' status, now the system correctly handles this scenario, ensuring data integrity and preventing unexpected errors. This improves the reliability of the manufacturing workflow.
Original PR description
When setting the done state on an already done WO, a traceback is raised. Steps to reproduce the error: - Install ``mrp_workorder`` module with demo data - Go to Manufacturing > Open any confirmed MO…
When setting the done state on an already done WO, a traceback is raised. Steps to reproduce the error: - Install ``mrp_workorder`` module with demo data - Go to Manufacturing > Open any confirmed MO > In Work Orders Tab, Set the status to Done, again set the status to Done Traceback: ```py UnboundLocalError: cannot access local variable 'wo' where it is not associated with a value ``` As long as the MO is not in the done state, the dropdown for the workorder status remains visible, allowing users to mark an already done WO as done again. In this case, the WO is not added to "ids_to_update" list at [1], so ``action_mark_as_done`` is called on an empty workorder recordset at [2], For ``self`` containing no records, ``wo`` is never defined, leading to the above traceback from the following line. https://github.com/odoo/enterprise/blob/3c4f44f316625f3315d176adfad5e1f1a6bea00a/mrp_workorder/models/mrp_workorder.py#L842 [1]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L168-L176 [2]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L184-L185 sentry-7477198216
This update clarifies timesheet reporting by changing how the automated rule for GitHub Pull Requests is displayed. Previously, the rule showed the Pull Request ID, which was confusing for users. Now, the rule displays the Pull Request name, making it easier to connect the event to the relevant project or task.
Original PR description
Before this commit, the AW Rule used in Timesheets Assistant will display the id of the Github Pull request and the repository but that information is not always clear for the user to know which project/task is related to that PR. This commit changes the AW rule for Github to display the name of the pull request instead to have more context to easily match the project/task to the event created by that rule. task-6306166 Forward-Port-Of: odoo/enterprise#120676
This change fixes a bug that prevented users from correctly marking work orders as 'done' when they were already marked as done. The fix updates a key condition to accurately reflect the state of the manufacturing order, preventing an error and ensuring accurate status tracking. This improves the reliability of the MRP process.
Original PR description
When setting the done state on an already done WO, a traceback is raised. Steps to reproduce the error: - Install ``mrp_workorder`` module with demo data - Go to Manufacturing > Open any confirmed MO…
When setting the done state on an already done WO, a traceback is raised. Steps to reproduce the error: - Install ``mrp_workorder`` module with demo data - Go to Manufacturing > Open any confirmed MO > In Work Orders Tab, Set the status to Done, again set the status to Done Traceback: ```py UnboundLocalError: cannot access local variable 'wo' where it is not associated with a value ``` https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/static/src/components/wo_list_view_dropdown/wo_list_view_dropdown.xml#L4-L5 In the commit [1], condition was changed from ``state`` to ``production_state``. ``production_state`` is the related to the state of MO, So, as long as the MO is not in the ``done`` state, the dropdown remains visible, allowing users to mark an already done WO as done again. In this case, the WO is not added to ``ids_to_update`` list at [2]. so ``action_mark_as_done`` is called on an empty workorder recordset at [3], leading to the above traceback from following line https://github.com/odoo/enterprise/blob/3c4f44f316625f3315d176adfad5e1f1a6bea00a/mrp_workorder/models/mrp_workorder.py#L842 [1]: https://github.com/odoo/odoo/commit/5b1197647b558eacd501fdd816056cfd56f45ced [2]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L168-L176 [3]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L184-L185 sentry-7477198216 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a requirement in the Danish Nemhandel invoicing format, specifically within the AllowanceCharge node. The change adds a necessary TaxCategory node to ensure compliance with UBL standards. This resolves an issue identified during Nemhandel testing, improving invoice compatibility.
Original PR description
Add the TaxCategory node in AllowanceCharge node as it's a requirement for some UBL format. It has been spoted with Nemhandel, as it requires a single tax category in the AllowanceCharge. no-task Forward-Port-Of: odoo/odoo#270351
This update prevents errors in e-Waybill requests when the dispatch and delivery locations share the same pin code. Previously, the system couldn't automatically calculate distance in these cases, leading to incomplete requests. Now, a distance must be provided, ensuring accurate e-Waybill generation and avoiding server issues.
Original PR description
Prevent sending incomplete e-Waybill requests to the GSP server when the dispatch and delivery pincodes are identical. In such cases, the distance cannot be automatically determined and must be provided explicitly. This commit adds a validation to ensure a distance is set before generating the e-Waybill, avoiding incomplete requests and subsequent server-side errors. task-6234343 Forward-Port-Of: odoo/odoo#270495 Forward-Port-Of: odoo/odoo#268497
This update prevents logged-in users from attempting to sign up or log in through the website's signup page. Previously, submitting the form would result in an error. Now, a warning message appears, and the button is disabled, ensuring users can only access these features when not already authenticated.
Original PR description
Steps to reproduce: 1.Log in to the backend as an Admin (or any authenticated user). 2.Navigate to Website -> Configuration -> System Pages and open the Signup page. 3.Fill in the signup form and submit it. 4.After successfully signing up, click the Logout button. 5.Observe that a "405 Method Not Allowed" error is displayed. Before this commit: When an already logged-in user accessed the signup page through the System Pages menu and submitted the signup form, clicking the Logout button afterward resulted in a 405 Method Not Allowed error. After this commit: When an already logged-in user accesses the signup or login page, a warning message is displayed and the Sign Up or Log In button is disabled, preventing the form from being submitted. task-6023075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270911 Forward-Port-Of: odoo/odoo#263791
This update resolves an issue where tasks created through Timesheets Assistant Rules were incorrectly set as private. The fix ensures that a project is automatically associated with new tasks, preventing them from being created without a designated project. This improves task organization and reporting within the Timesheets module.
Original PR description
Steps to reproduce: - Install Timesheets and enable Timesheets Assistant. - Go to Timesheets -> Configuration -> Assistant Rules. - Open an existing rule or create a new one. - Select a Project and enter a new Task name. Issue 1: - Click Create. - The task is created as a private task, and the project is cleared. Issue 2: - Click Create and Edit. - Remove the project and save. - The task is saved as a private task. Cause: - When using Create, the `default_project_id` from the context is not applied, so the task is created as a private task. - When using Create and Edit, users can remove the prefilled project before saving, which also results in a private task. Fix: - Pass `default_project_id` and `form_view_ref='project.view_task_form_res_partner'` in the context. This prefills the project and makes it required when creating a task. task-6293306 Forward-Port-Of: odoo/enterprise#120862
This update fixes an issue where product images didn't display in the correct order when using the grid layout in the product image viewer. The change ensures images are navigated in their intended visual order, providing a better user experience for browsing products. This was caused by a recent layout update and has been corrected to align with the user's visual expectations.
Original PR description
This commit ensures product images follow their visual order in the product image viewer when using the grid layout. Steps to reproduce: - Open a product page with multiple images (or add Extra Media…
This commit ensures product images follow their visual order in the product image viewer when using the grid layout. Steps to reproduce: - Open a product page with multiple images (or add Extra Media to the product) - Change layout mode to "Grid" and click save - Click any image to open the product image viewer - Navigate between images Images do not follow the visual left-to-right order. This regression was introduced by [commit], which replaced the row-based grid with a column-first layout. As a result, `querySelectorAll` returns images in DOM order, which no longer matches the visual order. To fix this, images are now reordered based on their visual placement in the grid so navigation matches the order seen by the user. Images are traversed in visual left-to-right order while also accounting for varying image heights and multi-column alignment. [commit]: https://github.com/odoo/odoo/commit/9a3628b9735550bf8ecc2252ea1b7338f68ab966 task-[4364143](https://www.odoo.com/odoo/project/974/tasks/4364143) Forward-Port-Of: odoo/odoo#270732 Forward-Port-Of: odoo/odoo#254077
This update fixes a visual issue in the spreadsheet dashboard where focused buttons were obscured by the surrounding container. The change ensures that buttons have their expected focus shadows, providing a cleaner and more professional user experience. This improves the overall usability of the dashboard.
Original PR description
the searchbar container cropped the shadow of its button when they were focused. Task-6303342 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#270812
This update fixes a potential instability issue with dynamic website content snippets. The change ensures callbacks are properly 'protected' during rendering, preventing unexpected behavior and test failures. This improves the reliability of the website experience.
Original PR description
Commit dcb070244dbcef59cae1e3b1e87ce9030608ce0d changed the registration of callback for re-render of dynamic snippet on window resize. But did not ensure the callback is "protected", like it was implicitely done with `t-on-` in `dynamicContent`. This commit uses `protectSyncAfterAsync` to register the callback, so that is it protected when called again. This lack of "protection" is suspected to cause a non-deterministic failure in `test_shop_editor_no_alternative_products_visibility` where mutations of dom are observed at unexpected times. runbot-939193 Forward-Port-Of: odoo/odoo#271011
This update resolves a problem where custom styling of text input fields within Odoo wasn't working correctly. The previous version prevented users from applying their own styles, but this fix now allows for proper styling of text inputs by combining the default style with any styles provided by the user. This ensures consistent and customizable text input appearance.
Original PR description
BuilderTextInput's template hardcoded `inputClasses` to 'o-hb-input-text', dropping any `inputClasses` prop passed by callers. As a result, options trying to style their text input had no effect. Introduced in 0aba7f383c86dec00e9fc6d324a5bfdec7a19707. Concatenate caller-supplied `inputClasses` with the default `o-hb-input-text`. Forward-Port-Of: odoo/odoo#265156
This update resolves an issue where the link editor unexpectedly appeared after creating multiple tracked links. The fix ensures the editor is only displayed when a user is actively editing a link, preventing confusion and improving the user experience. This change simplifies the process of managing tracked links.
Original PR description
Steps to reproduce: - Go to the Link Tracker page - Generate a first tracked link - Click on the button to start editing the code - Click on "create another tracker" - Generate a second tracked link => When you access the screen to see/edit the tracked link url, the buttons "ok" and "cancel" are already present. Clicking on "ok" display a traceback. To fix this issue, this commit also cancels edition when clicking on "create another tracker". task-4531974 Forward-Port-Of: odoo/odoo#269886 Forward-Port-Of: odoo/odoo#268573
20 changes
Resolved issues and error corrections
This update resolves a test failure related to GCC POS localization reporting. The fix ensures that order receipts display the correct information and addresses assertions related to rounding and discounts. This improves the reliability of the GCC POS test suite.
Original PR description
- Fixed `TestGenericGCC.test_generic_localization` which was failing because some information was not rendered on the order receipt. - Added rounding configuration to the POS config so that the assertion for `Rounding` does not fail. - Added steps for `Discount` and `Change` in `generic_localization_tour` so that the assertions for `Discount` and `Change` do not fail. Error-237988 Task-5897376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where fully settled customers with past pay-later payments were incorrectly prevented from seeing their Customer Statements. The fix now checks for any past pay-later payment lines, ensuring the statement button appears regardless of whether the customer's total balance is zero. This improves the user experience for all customers.
Original PR description
The override of _compute_has_moves was checking `total_due != 0` to set `has_moves` on for PoS pay_later customers. Once the customer is fully settled however, `total_due` is 0 and the check does not pass anymore, so `has_moves` goes back to `False` and the Customer Statement button hides for them, even though they had past pay_later payment lines. The fix is to check directly for any past pay_later `pos.payment` instead, which covers the cases where partner had used pay_later payment methods before, regardless if they have settled their total due or not. opw-6173760 Forward-Port-Of: odoo/enterprise#120911 Forward-Port-Of: odoo/enterprise#116536
This update resolves an issue where sending NFC-e invoices through IAP would halt the POS synchronization process when IAP credits were exhausted. The change prevents the system from blocking POS updates, ensuring smoother operations when IAP credit limits are reached. This improves reliability and prevents disruptions to sales workflows.
Original PR description
When sending an NFC-e, tax calculation is done by calling Avatax through IAP. If the IAP account has no credits left, iap_jsonrpc() raises an InsufficientCreditError. opw-6290857 Forward-Port-Of: odoo/enterprise#120700
A bug preventing users from adding cover images to Knowledge articles has been resolved. The issue stemmed from a missing callback function during the upload process, causing the upload to fail. This update ensures cover images can now be successfully added, improving the article creation experience.
Original PR description
Steps to reproduce: 1. Install Knowledge. 2. Create an article. 3. Open the more actions menu. 4. Click "Add Cover". 5. Upload a cover image. Issue: - The upload crashes with the following traceback:…
Steps to reproduce: 1. Install Knowledge. 2. Create an article. 3. Open the more actions menu. 4. Click "Add Cover". 5. Upload a cover image. Issue: - The upload crashes with the following traceback: `Uncaught Promise > this.props.setAbortUploadsCallback is not a function` Cause: - `KnowledgeCoverSelector` extends the html_editor `ImageSelector`, whose upload flow registers an abort callback through setAbortUploadsCallback. The generic MediaDialog provides this callback, but KnowledgeCoverDialog renders KnowledgeCoverSelector directly and did not pass it. As a result, the inherited upload flow called a missing prop. Solution: - Pass setAbortUploadsCallback from KnowledgeCoverDialog to KnowledgeCoverSelector and abort pending uploads when the cover dialog is discarded. Alternative approach: - Make ImageSelector tolerate callers that do not provide setAbortUploadsCallback by calling it with optional chaining. opw-6176716 Forward-Port-Of: odoo/enterprise#120467 Forward-Port-Of: odoo/enterprise#116906
This update resolves an issue where milestone deadline dates would disappear from task views after navigating back or refreshing. The fix ensures that milestone deadlines are consistently displayed in task Kanban cards and headers, regardless of user navigation, improving project tracking accuracy.
Original PR description
Steps to reproduce: 1. Open the Project application and open any project. 2. Filter the tasks by milestone (milestone deadlines appear as expected in the kanban view). 3. Open any task form view. 4.…
Steps to reproduce: 1. Open the Project application and open any project. 2. Filter the tasks by milestone (milestone deadlines appear as expected in the kanban view). 3. Open any task form view. 4. Click the browser's back button (or simply refresh the page while on the task kanban view). Issue: Milestone deadline dates disappear from the task Kanban cards and headers after navigating back or reloading. Why this happens: When hitting the browser back button or refreshing, the web client's router state recovery workflow executes (`loadRouterState` -> `loadState` -> `doAction` -> `_executeActWindowAction`). During this flow, `_getActionParams` checks if it can reuse the cached `lastAction`. However, due to a safety condition introduced in commit ab26f95893 to prevent embedded action showing across different projects, the router falls back to generating a fresh action request via `state.action`. This forces `_loadAction` to fetch the action definition from the database. Because the original base action window `act_project_project_2_project_task_all` lacks the `display_milestone_deadline` key inside its default context dictionary, the reloaded view is rendered without the flags required by the frontend to display milestone deadlines. opw-6283514 Forward-Port-Of: odoo/odoo#269781
This update prevents logged-in users from attempting to sign up or log in through the website's signup page. Previously, users could submit the form, resulting in an error. Now, a warning message appears, and the button is disabled, ensuring only new users can register.
Original PR description
Steps to reproduce: 1.Log in to the backend as an Admin (or any authenticated user). 2.Navigate to Website -> Configuration -> System Pages and open the Signup page. 3.Fill in the signup form and submit it. 4.After successfully signing up, click the Logout button. 5.Observe that a "405 Method Not Allowed" error is displayed. Before this commit: When an already logged-in user accessed the signup page through the System Pages menu and submitted the signup form, clicking the Logout button afterward resulted in a 405 Method Not Allowed error. After this commit: When an already logged-in user accesses the signup or login page, a warning message is displayed and the Sign Up or Log In button is disabled, preventing the form from being submitted. task-6023075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263791
This update clarifies timesheet reporting by changing the automated rule (AW Rule) to display the name of the GitHub pull request instead of its ID. This provides users with more context, making it easier to link pull requests to the relevant projects and tasks within the Timesheets Assistant.
Original PR description
Before this commit, the AW Rule used in Timesheets Assistant will display the id of the Github Pull request and the repository but that information is not always clear for the user to know which project/task is related to that PR. This commit changes the AW rule for Github to display the name of the pull request instead to have more context to easily match the project/task to the event created by that rule. task-6306166
This update resolves an issue preventing the correct export of balance sheet data in the Lu (Luxembourg) localization. The system now automatically includes a default start date (beginning of the fiscal year) in the XML file, ensuring accurate reporting. This prevents errors during the export process.
Original PR description
Steps to reproduce: - setup a LU company - go to balance sheet - export the xml file - validate the wizard -> Traceback, because the code expects the options to contain the date_from, which is no longer the case since 19.2 as the balance sheet has by default only a date_to. The solution is therefore to define it for the export to the beginning of the fiscal year.
This update resolves an issue in the Data Recycle app where record IDs were incorrectly summed and displayed alongside group names, causing truncation and unreadability. The fix removes the unnecessary aggregation of record IDs, resulting in a cleaner and more informative display of grouped records.
Original PR description
## Issue In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which: 1. truncates the name and count of the groups 2. does…
## Issue
In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)
<img width="720" height="281" alt="115492" src="https://github.com/user-attachments/assets/567902af-b356-4a0a-8b1e-2ed101a2eba3" />
## Steps to reproduce
1. Install *Data Recycle* (`data_recycle`)
2. In Data Cleaning > Configuration > Recycle Records, create a new rule:
- Any name
- Model: *Contact*
- Filter: *Name contains G* (or anything else that matches some records)
4. Click the *Run Now* button in the upper left corner
5. In Data Cleaning > Recyle Records, group the records by any field (e.g., *Model*)
6. **The name of the group (Contact) is truncated, making it and the record count unreadable. This is due to the sum of Record ID being displayed in the same row, even though that information is irrelevant.**
## Cause
Similarly to related enterprise PR https://github.com/odoo/enterprise/pull/115492, the *Record ID* field of the `data_recycle.record` model uses the default `sum` aggregator.
https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/addons/data_recycle/models/data_recycle_record.py#L17
related: https://github.com/odoo/enterprise/pull/115492
opw-6219824
Forward-Port-Of: odoo/odoo#265163This update resolves an issue in the Data Cleaning app where record IDs were incorrectly summed and displayed alongside group names, leading to truncated names and inaccurate counts. The fix removes the automatic summing of IDs in grouped list views, ensuring that group names and counts are displayed correctly.
Original PR description
## Issue In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which: 1. truncates the name and count of the groups 2. does…
## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)
<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />
## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
- Any name
- Model: *Contact*
- Rule:
- Field to Clean: *Name (Contact)*
- Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**
## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:
https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23
This causes the IDs to be summed up and appear in the group headers.
## After
<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />
related: https://github.com/odoo/odoo/pull/265163
opw-6166623
Forward-Port-Of: odoo/enterprise#115492This update prevents a popover error that occurred when users clicked on notification envelopes in the chatter. The issue stemmed from a missing `res_partner_id` field, which caused a comparison error. This fix ensures notifications display correctly for all users, regardless of whether a partner ID is available.
Original PR description
# How to reproduce - Create an Event registration - Add a follower - Click on the enveloppe icon next to the sender's name in the chatter # The problem A traceback appears # Cause of the issue When…
# How to reproduce - Create an Event registration - Add a follower - Click on the enveloppe icon next to the sender's name in the chatter # The problem A traceback appears # Cause of the issue When clicking on the enveloppe, we display the `message_notification_popover` that calls `isFollowerNotification` to filter follower notifications from other ones. This function compares the ids of the followers of the notification to it's res_partner_id : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/static/src/core/common/notification_model.js#L101-L105 But in our case res_partner_id is undefined because it is not a required field and it will not be set in the case of mass_mailing : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/models/mail_notification.py#L23-L27 opw-6178443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265263
This update resolves a problem where the PDP identifier field in the company registration process was left blank when using non-0225 PEPPOL EAS. It now displays a user error if an invalid identifier is entered, preventing incorrect registrations. This ensures accurate PDP registration and compliance.
Original PR description
Currently when the company partner uses non 0225 peppol EAS the `pdp_identifier` field is `False`. Thus the (related) identifier field on the registration wizard is left empty. Also add a UserError when writing an invalid identifier to the `pdp_identifier` field instead of just silently failing. That way an error ill pop up in the registration wizard when trying to register with an invalid identifier. task-6307489 Forward-Port-Of: odoo/odoo#270915 Forward-Port-Of: odoo/odoo#270330
This update strengthens Odoo's security by ensuring users only have read access to data. This prevents potential issues and unexpected behavior within the system, contributing to a more stable and reliable platform. The change was implemented as a fix to a vulnerability.
Original PR description
Ensure that the user has read access to prevent any unexpected behavior. Task-6226863 Forward-Port-Of: odoo/odoo#267709
This update corrects a formatting issue in the Danish UBL invoice export, specifically related to the Nemhandel system. Adding a required 'TaxCategory' node ensures compliance with UBL standards, preventing export errors and facilitating accurate invoice processing. This ensures invoices are correctly formatted for electronic delivery.
Original PR description
Add the TaxCategory node in AllowanceCharge node as it's a requirement for some UBL format. It has been spoted with Nemhandel, as it requires a single tax category in the AllowanceCharge. no-task Forward-Port-Of: odoo/odoo#270351
This update prevents errors in e-Waybill requests when the dispatch and delivery locations share the same pincode. The system now requires a distance to be specified in these cases, ensuring complete requests are sent to the GSP server and avoiding potential issues.
Original PR description
Prevent sending incomplete e-Waybill requests to the GSP server when the dispatch and delivery pincodes are identical. In such cases, the distance cannot be automatically determined and must be provided explicitly. This commit adds a validation to ensure a distance is set before generating the e-Waybill, avoiding incomplete requests and subsequent server-side errors. task-6234343 Forward-Port-Of: odoo/odoo#270495 Forward-Port-Of: odoo/odoo#268497
This update resolves an issue where new tasks created through Timesheets Assistant Rules were incorrectly set as private. The fix ensures that tasks are always associated with a project, preventing this unwanted behavior and improving task management consistency. This change enhances user experience and data accuracy within the Timesheets module.
Original PR description
Steps to reproduce: - Install Timesheets and enable Timesheets Assistant. - Go to Timesheets -> Configuration -> Assistant Rules. - Open an existing rule or create a new one. - Select a Project and enter a new Task name. Issue 1: - Click Create. - The task is created as a private task, and the project is cleared. Issue 2: - Click Create and Edit. - Remove the project and save. - The task is saved as a private task. Cause: - When using Create, the `default_project_id` from the context is not applied, so the task is created as a private task. - When using Create and Edit, users can remove the prefilled project before saving, which also results in a private task. Fix: - Pass `default_project_id` and `form_view_ref='project.view_task_form_res_partner'` in the context. This prefills the project and makes it required when creating a task. task-6293306 Forward-Port-Of: odoo/enterprise#120862
This update resolves an issue where sign templates with auto-filled fields would incorrectly display placeholders instead of the actual values, or fail to generate documents. The fix ensures falsy auto-filled values are properly handled, preventing errors and guaranteeing accurate sign document generation.
Original PR description
Version: - 19.0 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the linked field value is empty or False. - Send the…
Version: - 19.0 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the linked field value is empty or False. - Send the document for signing. - Complete the signing flow. Issue: - Readonly sign items linked to auto-filled values could not properly handle falsy values. Empty values could trigger the error "Some required items are not filled" and completed sign requests displayed the sign item placeholder instead of the actual auto-filled value. - completed document generation could fail when rendering falsy values for textarea sign items. Cause: - Falsy auto-filled values were ignored during constant item population and replaced by the sign item placeholder. Additionally, readonly constant items were included in required field validation and completed sign requests continued to display placeholders when the stored value was empty. - document rendering assumed sign item values were always strings for textarea sign items but when auto field is empty it value can be False. Fix: - Preserve falsy values when populating readonly constant items, exclude constant items from signer validation, and hide placeholders for empty auto-filled constant items when displaying completed sign requests. - Normalize falsy values to prevent crashes and allow completed documents to be generated correctly. Forward-Port-Of: odoo/enterprise#121009
This update corrects a bug where custom styling of text inputs within Odoo wasn't working correctly. The previous version prevented users from applying their own styles to text inputs. This change ensures that styling options passed to text inputs now function as intended, providing greater flexibility in design.
Original PR description
BuilderTextInput's template hardcoded `inputClasses` to 'o-hb-input-text', dropping any `inputClasses` prop passed by callers. As a result, options trying to style their text input had no effect. Introduced in 0aba7f383c86dec00e9fc6d324a5bfdec7a19707. Concatenate caller-supplied `inputClasses` with the default `o-hb-input-text`. Forward-Port-Of: odoo/odoo#265156
This update corrects an issue where the link editor unexpectedly appeared when creating new tracked links. The fix ensures the editor only opens when a user actively wants to modify a link, preventing confusion and improving the user experience. This resolves a minor bug that could have caused frustration for users.
Original PR description
Steps to reproduce: - Go to the Link Tracker page - Generate a first tracked link - Click on the button to start editing the code - Click on "create another tracker" - Generate a second tracked link => When you access the screen to see/edit the tracked link url, the buttons "ok" and "cancel" are already present. Clicking on "ok" display a traceback. To fix this issue, this commit also cancels edition when clicking on "create another tracker". task-4531974 Forward-Port-Of: odoo/odoo#269886 Forward-Port-Of: odoo/odoo#268573
This update fixes an issue where the chatter in Odoo POS incorrectly displayed the employee who made changes to tracked orders. Now, the chatter accurately reflects the employee currently interacting with the order, ensuring accurate order tracking and communication. This improves order management and reduces potential confusion.
Original PR description
**Steps to reproduce:** - Enable "Track orders edits" in the settings - Enable "Log in with Employees" - Go to the Restaurant, log in with employee A - Go to a table, order 3 Sushis - Go back to the…
**Steps to reproduce:** - Enable "Track orders edits" in the settings - Enable "Log in with Employees" - Go to the Restaurant, log in with employee A - Go to a table, order 3 Sushis - Go back to the floor plan and change to employee B - Go back to the table and change the qty of 3 Sushis to 2 Sushis - Go to the order in the backend and check the chatter - It will indicate that employee A did the change, but it was employee B **Why the fix:** We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point. We now use the session's current employee to write who did the change in the chatter. We do not change the order's employee, because it will be done once the order has been paid. In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name. The way we return the value has been changed because the linter wasn't happy about it. opw-6213504 Forward-Port-Of: odoo/odoo#270416 Forward-Port-Of: odoo/odoo#265582
20 changes
Resolved issues and error corrections
This update resolves an issue where loading demo data for the `l10n_in` module failed when installed without pre-existing demo data. The fix ensures that company IDs are correctly converted into the required format, allowing users to successfully load demo data from the Settings menu. This improves the user experience and ensures consistent demo data setup.
Original PR description
## Description When loading demo data from **Settings** after installing `l10n_in` without demo data, the `_install_demo` method receives company IDs instead of a `res.company` recordset. As a…
## Description When loading demo data from **Settings** after installing `l10n_in` without demo data, the `_install_demo` method receives company IDs instead of a `res.company` recordset. As a result, the following line crashes: ```python companies.filtered(...) ``` with: ```text AttributeError: 'int' object has no attribute 'filtered' ``` This PR ensures that the received company IDs are converted into a `res.company` recordset before being processed, allowing demo data to be loaded successfully from the Settings menu. ## Steps to Reproduce 1. Install `l10n_in` **without demo data**. 2. Navigate to **Settings**. 3. Click **Load Demo Data**. ## Current Behavior Demo data installation fails with: ```text AttributeError: 'int' object has no attribute 'filtered' ``` ## Expected Behavior Demo data should be installed successfully without raising any exception. ## Solution Convert the received company IDs into a `res.company` recordset when the argument passed to `_install_demo` is not already a recordset.
This update resolves an issue where appointment invitations weren't always sent correctly. The change ensures invitations are only sent when an appointment is in the 'booked' or 'request' status, preventing unnecessary emails and improving efficiency. This was originally identified and addressed in a related enterprise PR.
Original PR description
This PR adapts the code to fix the invitations at the appointments' update. See the enterprise PR to get more information about the issues. Enterprise PR: https://github.com/odoo/enterprise/pull/114304 Task-6139036 Forward-Port-Of: odoo/odoo#260073
This update resolves an error that prevented users from sorting tasks by their planned dates within the project management portal. The fix ensures that the system correctly retrieves sort order information, preventing a 'KeyError' and improving the user experience. This change ensures reliable task sorting functionality.
Original PR description
Currently, an error occurs when a user sorts tasks by Planned Date. **Steps to reproduce:** - Install the `project_enterprise` module with demo data. - Go to Projects in the portal (`/my/projects`),…
Currently, an error occurs when a user sorts tasks by Planned Date. **Steps to reproduce:** - Install the `project_enterprise` module with demo data. - Go to Projects in the portal (`/my/projects`), open any `project`, and sort the tasks by `Planned Date`. KeyError: 'order' After a [recent change], the sort order is retrieved from searchbar sortings. When sorting by Planned Date, it attempts to access the order key from the corresponding sorting configuration [1]. However, the planned_date_begin entry does not define an order key [2], which raises error when it tries to access order. This commit ensures that the order key is added with its value for planned_date_begin in searchbar sorting. [recent change]: https://github.com/odoo/odoo/commit/8be5dacf9fbfe8c23b04c876994bea2ce7cbb89a [1]: https://github.com/odoo/odoo/blob/2ae9b57b86cd0bc4816ff8ec207564631baa8ad6/addons/project/controllers/portal.py#L424 [2]- https://github.com/odoo/enterprise/blob/9dd3a9b2c09a6d23a3f71d3e531edd6d78b30277/project_enterprise/controllers/portal.py#L8-L11 sentry-7556050938
This update corrects a visual issue in the Data Recycle app where grouping records resulted in incorrect record counts and truncated group names. The fix removes the unnecessary display of summed record IDs, improving the clarity and accuracy of grouped lists.
Original PR description
## Issue In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which: 1. truncates the name and count of the groups 2. does…
## Issue
In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)
<img width="720" height="281" alt="115492" src="https://github.com/user-attachments/assets/567902af-b356-4a0a-8b1e-2ed101a2eba3" />
## Steps to reproduce
1. Install *Data Recycle* (`data_recycle`)
2. In Data Cleaning > Configuration > Recycle Records, create a new rule:
- Any name
- Model: *Contact*
- Filter: *Name contains G* (or anything else that matches some records)
4. Click the *Run Now* button in the upper left corner
5. In Data Cleaning > Recyle Records, group the records by any field (e.g., *Model*)
6. **The name of the group (Contact) is truncated, making it and the record count unreadable. This is due to the sum of Record ID being displayed in the same row, even though that information is irrelevant.**
## Cause
Similarly to related enterprise PR https://github.com/odoo/enterprise/pull/115492, the *Record ID* field of the `data_recycle.record` model uses the default `sum` aggregator.
https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/addons/data_recycle/models/data_recycle_record.py#L17
related: https://github.com/odoo/enterprise/pull/115492
opw-6219824
Forward-Port-Of: odoo/odoo#265163This update resolves an issue in the Data Cleaning app where grouping records resulted in the display of summed record IDs alongside group names, causing truncation and inaccurate counts. The fix removes the default 'sum' aggregator applied to integer fields, preventing this misleading display and ensuring accurate group counts.
Original PR description
## Issue In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which: 1. truncates the name and count of the groups 2. does…
## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)
<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />
## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
- Any name
- Model: *Contact*
- Rule:
- Field to Clean: *Name (Contact)*
- Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**
## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:
https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23
This causes the IDs to be summed up and appear in the group headers.
## After
<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />
related: https://github.com/odoo/odoo/pull/265163
opw-6166623
Forward-Port-Of: odoo/enterprise#115492This update fixes an issue where product costs weren't correctly converted to the POS currency. Previously, product costs were stored in separate currencies, leading to potential inaccuracies in pricing. This change ensures all product costs are accurately converted, improving the reliability of sales data in the Point of Sale system.
Original PR description
When loading products in the POS, both the sale price and the cost were converted to the POS currency using `currency_id`. However a product stores its sale price and its cost in two potentially different currencies: `currency_id` (company currency, falling back to the main company) and `cost_currency_id` (company currency, falling back to the current company). opw-6297452 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269829
This update prevents a traceback error that occurred when clicking the 'envelope' icon in the chatter, specifically during event registrations or follower additions. The issue stemmed from a missing `res_partner_id` field, which caused a conflict in notification filtering. This fix ensures the notification popover functions correctly regardless of whether a partner ID is present.
Original PR description
# How to reproduce - Create an Event registration - Add a follower - Click on the enveloppe icon next to the sender's name in the chatter # The problem A traceback appears # Cause of the issue When…
# How to reproduce - Create an Event registration - Add a follower - Click on the enveloppe icon next to the sender's name in the chatter # The problem A traceback appears # Cause of the issue When clicking on the enveloppe, we display the `message_notification_popover` that calls `isFollowerNotification` to filter follower notifications from other ones. This function compares the ids of the followers of the notification to it's res_partner_id : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/static/src/core/common/notification_model.js#L101-L105 But in our case res_partner_id is undefined because it is not a required field and it will not be set in the case of mass_mailing : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/models/mail_notification.py#L23-L27 opw-6178443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265263
This update corrects a recent change that was incorrectly returning all active documents during searches. The fix ensures that searches for user root documents only return valid results, excluding those marked as 'trash'. This improves search accuracy and data integrity.
Original PR description
We went a bit too fast with df353d76 and transformed search `'in', '[]'` from Domain.FALSE to all active documents. All active documents should only be returned when searching for all valid user roots (i.e., not TRASH). We're here partially reverting referenced commit and applying the closest code minimizing diff for foward ports. Task-5893183
This update resolves a problem where the PDP identifier field in the company registration process was left blank when using non-0225 PEPPOL EAS. A new error message is now displayed to guide users to enter a valid identifier, preventing silent failures and ensuring accurate registration. This improves the reliability of the PDP proxy setup.
Original PR description
Currently when the company partner uses non 0225 peppol EAS the `pdp_identifier` field is `False`. Thus the (related) identifier field on the registration wizard is left empty. Also add a UserError when writing an invalid identifier to the `pdp_identifier` field instead of just silently failing. That way an error ill pop up in the registration wizard when trying to register with an invalid identifier. task-6307489 Forward-Port-Of: odoo/odoo#270915 Forward-Port-Of: odoo/odoo#270330
This update corrects a requirement in the Danish Nemhandel invoicing format, specifically within the AllowanceCharge node. The change adds a necessary TaxCategory node to ensure compliance with UBL standards, resolving a previously identified issue. This ensures accurate invoice processing for Nemhandel customers.
Original PR description
Add the TaxCategory node in AllowanceCharge node as it's a requirement for some UBL format. It has been spoted with Nemhandel, as it requires a single tax category in the AllowanceCharge. no-task Forward-Port-Of: odoo/odoo#270351
This update prevents errors in e-Waybill requests when the dispatch and delivery locations share the same pin code. Previously, the system couldn't automatically calculate the distance in these cases, leading to incomplete requests. Now, a distance must be provided, ensuring accurate e-Waybill generation and avoiding server issues.
Original PR description
Prevent sending incomplete e-Waybill requests to the GSP server when the dispatch and delivery pincodes are identical. In such cases, the distance cannot be automatically determined and must be provided explicitly. This commit adds a validation to ensure a distance is set before generating the e-Waybill, avoiding incomplete requests and subsequent server-side errors. task-6234343 Forward-Port-Of: odoo/odoo#270495 Forward-Port-Of: odoo/odoo#268497
This update resolves an error that occurred when syncing AvaTax exemption codes. The issue stemmed from a mismatch in how AvaTax represented 'all countries' values, causing a crash during synchronization. This fix ensures correct data handling and successful exemption code synchronization.
Original PR description
Steps to reproduce: - Create a US company - Go to Accounting > Configuration > Settings - Activate `Avatax` > Set Credentials - Try to "Sync Parameters" Traceback: ```py File…
Steps to reproduce:
- Create a US company
- Go to Accounting > Configuration > Settings
- Activate `Avatax` > Set Credentials
- Try to "Sync Parameters"
Traceback:
```py
File "/home/odoo/src/enterprise/saas-19.2/account_avatax/models/res_company.py", line 113, in avatax_sync_company_params
'valid_country_ids': [(6, 0, get_countries(vals['validCountries']).ids)],
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/account_avatax/models/res_company.py", line 90, in get_countries
return self.env['res.country'].browse([country_cache[code] for code in code_list])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 5208, in browse
assert all(ids) or all(isinstance(x, NewId) or x for x in ids), "Invalid falsy real id"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```
The issue occurs because AvaTax return `*` in the `validCountries` field to indicate that an exemption code is valid for all countries. The synchronization logic stores this value in the country cache as `False` and later passes it to `res.country.browse()`. Since `browse()` does not accept a mix of valid IDs and falsy values, the operation crashes during the synchronization process.
This commit filter out falsy country IDs when resolving country codes to prevent crashes and allow exemption codes to be synchronized successfully.
opw-6298189The Odoo team has partially reverted a recent code update due to unexpected changes introduced by Weblate. This ensures the translation updates made during the Weblate integration are preserved while correcting the unwanted code modifications. This resolves a technical issue impacting multiple modules.
Original PR description
For some reason Weblate reverted some code changes apart from the translations updates it did. We partially revert the commit here to fix the code, but keep the translation updates. This partially reverts commit 06c83da5410fd3869af0d9c3edddf9cc1a7d7c55.
This update resolves an issue where users couldn't link bank statement lines to child contacts when using the 'Set Partner' button. The fix aligns the system's logic to correctly recognize and select child contacts, ensuring accurate bank statement reconciliation. This improves the usability of the bank reconciliation process.
Original PR description
When creating a bank statement line, we can not set an individual contact that is a children of a company contact. However, when clicking on the 'Set Partner' button, all contacts are shown in the modal list view. This commit aligns the domain coming from the 'Set Partner' button with the domain from the 'partner_id' field of the auto reconcile wizard Steps: - Have a contact X, with a child contact Y - Create and confirm an invoice for contact Y, amount 1000 - Create a bank statement line for 1000 -> You can not select Y, only X - Click 'Add & Close' - Click on 'Set Partner' button -> Y is displayed opw-6205154 Forward-Port-Of: odoo/enterprise#118036
This update resolves an issue where sign templates with auto-filled fields would incorrectly display placeholders instead of the actual values, or fail to generate documents. The fix ensures falsy values from auto-fields are properly handled, preventing errors and guaranteeing accurate sign document generation.
Original PR description
Version: - 19.0 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the linked field value is empty or False. - Send the…
Version: - 19.0 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the linked field value is empty or False. - Send the document for signing. - Complete the signing flow. Issue: - Readonly sign items linked to auto-filled values could not properly handle falsy values. Empty values could trigger the error "Some required items are not filled" and completed sign requests displayed the sign item placeholder instead of the actual auto-filled value. - completed document generation could fail when rendering falsy values for textarea sign items. Cause: - Falsy auto-filled values were ignored during constant item population and replaced by the sign item placeholder. Additionally, readonly constant items were included in required field validation and completed sign requests continued to display placeholders when the stored value was empty. - document rendering assumed sign item values were always strings for textarea sign items but when auto field is empty it value can be False. Fix: - Preserve falsy values when populating readonly constant items, exclude constant items from signer validation, and hide placeholders for empty auto-filled constant items when displaying completed sign requests. - Normalize falsy values to prevent crashes and allow completed documents to be generated correctly. Forward-Port-Of: odoo/enterprise#121009
This update fixes a potential instability issue with dynamic website content snippets. The change ensures callbacks are properly protected during re-renders, preventing unexpected behavior and test failures. This improves the reliability of the website experience.
Original PR description
Commit dcb070244dbcef59cae1e3b1e87ce9030608ce0d changed the registration of callback for re-render of dynamic snippet on window resize. But did not ensure the callback is "protected", like it was implicitely done with `t-on-` in `dynamicContent`. This commit uses `protectSyncAfterAsync` to register the callback, so that is it protected when called again. This lack of "protection" is suspected to cause a non-deterministic failure in `test_shop_editor_no_alternative_products_visibility` where mutations of dom are observed at unexpected times. runbot-939193 Forward-Port-Of: odoo/odoo#271011
This update corrects a bug where custom styling of text input fields within Odoo wasn't working correctly. The previous version ignored styling instructions passed from the user. Now, styling options are properly applied, ensuring consistent and customizable text input appearances.
Original PR description
BuilderTextInput's template hardcoded `inputClasses` to 'o-hb-input-text', dropping any `inputClasses` prop passed by callers. As a result, options trying to style their text input had no effect. Introduced in 0aba7f383c86dec00e9fc6d324a5bfdec7a19707. Concatenate caller-supplied `inputClasses` with the default `o-hb-input-text`. Forward-Port-Of: odoo/odoo#265156
This update fixes an issue where the number of comments on course slides wasn't accurately displayed. Previously, the system incorrectly counted messages due to changes in how the portal chatter system works. This change ensures the comment counts now reflect the actual number of active comments, improving the user experience.
Original PR description
Steps to reproduce: - Open a slide of a course in non fullscreen mode (website). - Go to the comments tab and add a comment in the chatter. - The comments count does not change in the tab. - The same thing happens when a comment is deleted. - Another way to see the incorrect counter is to add a note in the slide form view (backend). Before this change, `website_slides` used `website_message_ids` to calculate the comments. Since #138233 the old portal chatter has been replaced with the mail chatter and the way messages are displayed on the portal has changed. For example notes are no longer considered portal messages and also deleted messages should not be displayed or counted as such. This change ensures that comments calculations are based on a domain that considers those changes meaning that comments will be synced with the actual number of available comments. Forward-Port-Of: odoo/odoo#270800 Forward-Port-Of: odoo/odoo#260376
This update simplifies the process of applying Early Payment Discounts (EPD) to refund transactions. Previously, a technical issue prevented correct mapping of tax repartition lines, now fixed by ensuring the system correctly identifies invoice and refund types. This enhancement improves the reliability of EPD calculations for refunds.
Original PR description
This commit does not bring native support for EPD on credit notes, only makes custom support a little easier and cleaner. It is quite easy to support EPD (early payment discounts) on refunds by…
This commit does not bring native support for EPD on credit notes, only makes custom support a little easier and cleaner. It is quite easy to support EPD (early payment discounts) on refunds by extending - `_early_payment_discount_move_types` - `_is_eligible_for_early_payment_discount` However, this approach breaks when it reaches `inverse_tax_rep` in `_get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line`, which assumes tax repartition lines with `document_type == 'invoice'` and raises when called on `tax_rep` lines of 'refund' type instead. This commit fixes that by selecting source and target repartition lines according to the `tax_rep`'s document type, which ensures: - the `.index()` no longer raises a `ValueError`, as `tax_rep` is now looked up in the matching set (`refund_` for refunds, `invoice_` otherwise) - `inverse_tax_rep` returns the corresponding line in the opposite set, preserving the original invoice->refund mapping while adding the refund->invoice one Since `inverse_tax_rep` is a closure, downstream modules cannot patch it without copying the whole ~170-line method. Making it symmetric here lets custom EPD-on-refund support work without that duplication. task-[6265601](https://www.odoo.com/odoo/all-tasks/6265601) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271102
This update resolves a bug that previously caused errors when address fields were missing in payment authorization requests. Now, missing address fields are automatically set to empty strings, ensuring the system functions correctly and avoids disruptions to payment processing. This improves the reliability of the payment authorization module.
Original PR description
Fix bug introduced by commit https://github.com/odoo/odoo/pull/267592/changes/c4556637e8eeef07ce6e3cc3b3b4cf28fa10e468 that caused an error if an address field was not set, due to trying to cut a False field. Now, unset fields are set to empty strings. Forward-Port-Of: odoo/odoo#270295
7 changes
Resolved issues and error corrections
This update fixes a minor issue within the Odoo composer (email creation tool) that was causing text editing to behave unexpectedly. Specifically, it addressed a problem where inserting mentions created a formatting error, leading to incorrect cursor placement. Adding a special character ensures proper text editing functionality and a better user experience.
Original PR description
### Purpose of this PR: - Inserting a mention in the composer results in a paragraph ending with a bare `<a>` element and no trailing text node. This causes the browser to mishandle the End key, moving the caret to the start of the next paragraph instead of the end of the current line. - Fix by appending a \uFEFF (zero-width no-break space) text node. task-6295924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269699
This update resolves a problem where the PDP identifier field in the company registration process was left blank when using non-0225 PEPPOL EAS. It now displays a user error message if an invalid identifier is entered, preventing silent failures and ensuring accurate registration. This improves the reliability of the registration process.
Original PR description
Currently when the company partner uses non 0225 peppol EAS the `pdp_identifier` field is `False`. Thus the (related) identifier field on the registration wizard is left empty. Also add a UserError when writing an invalid identifier to the `pdp_identifier` field instead of just silently failing. That way an error ill pop up in the registration wizard when trying to register with an invalid identifier. task-6307489 Forward-Port-Of: odoo/odoo#270915 Forward-Port-Of: odoo/odoo#270330
This update corrects a requirement in the Danish Nemhandel system for Universal Business Language (UBL) invoices. Specifically, it adds a 'TaxCategory' node to the 'AllowanceCharge' element, resolving a previously identified issue. This ensures proper invoice formatting and compliance with Nemhandel's specifications.
Original PR description
Add the TaxCategory node in AllowanceCharge node as it's a requirement for some UBL format. It has been spoted with Nemhandel, as it requires a single tax category in the AllowanceCharge. no-task Forward-Port-Of: odoo/odoo#270351
This update prevents errors in e-Waybill requests when the dispatch and delivery locations share the same pin code. Previously, the system couldn't automatically calculate the distance in these cases, leading to incomplete requests. Now, a distance must be provided, ensuring accurate e-Waybill generation and avoiding server issues.
Original PR description
Prevent sending incomplete e-Waybill requests to the GSP server when the dispatch and delivery pincodes are identical. In such cases, the distance cannot be automatically determined and must be provided explicitly. This commit adds a validation to ensure a distance is set before generating the e-Waybill, avoiding incomplete requests and subsequent server-side errors. task-6234343 Forward-Port-Of: odoo/odoo#270495 Forward-Port-Of: odoo/odoo#268497
This update corrects an issue where emojis, particularly complex ones like `👨🚒`, were being displayed incorrectly due to how they were encoded. The fix backports a more robust regex pattern from a recent version of Odoo that properly handles these variations in emoji formatting, ensuring emojis are displayed correctly.
Original PR description
Bug === Some emoji like `👨🚒` are separated, because they are built using `👨 + Emoji_Modifier + 🚒` (`\uFE0F` can also be used to get the variant of the emoji). Adapt the regex to take into account those Unicode variations. Task-5491124 Forward-Port-Of: odoo/odoo#270779 Forward-Port-Of: odoo/odoo#269719
This update resolves a bug that previously prevented the system from correctly calculating bill addresses when address fields were empty. The fix ensures that empty address fields are now handled gracefully, preventing errors and improving the reliability of payment authorization processes. This change ensures accurate billing information is consistently processed.
Original PR description
Fix bug introduced by commit https://github.com/odoo/odoo/pull/267592/changes/c4556637e8eeef07ce6e3cc3b3b4cf28fa10e468 that caused an error if an address field was not set, due to trying to cut a False field. Now, unset fields are set to empty strings. Forward-Port-Of: odoo/odoo#270295
This update resolves an issue where the table of contents would obscure headings when the status bar was made sticky. The fix ensures headings remain visible by intelligently accounting for sticky elements during scrolling within the table of contents, improving usability.
Original PR description
Since [1] when the `o_form_statusbar` status bar was made `sticky` the table of content scrolls to a given heading without taking it into account. Because of this, when scrolling upwards the heading ends up behind the status bar. This commit fixes this by finding top-aligned sticky elements within the closest scrollable element impacted by the table of content. Steps to reproduce: - Go to a To do note - Define some headings - Have sufficient content so that reaching a heading requires scrolling - Define a table of content with `/toc` - Click on a heading => The heading ended up behind the status bar. [1]: https://github.com/odoo/odoo/commit/a3c63413825cf3492a10ade77a2c571c4eeb33a6 task-6302762 Forward-Port-Of: odoo/odoo#270043
3 changes
Resolved issues and error corrections
This update fixes an issue where scanning unknown barcodes in the POS system didn't automatically open the product creation form. The fix removes a redundant API key check, ensuring the form opens correctly regardless of whether a barcode lookup API key is configured. This improves the user experience by streamlining the process of adding new products via barcode.
Original PR description
When scanning an unknown barcode in POS, the product creation form was never opened because `barcode_lookup()` was called with no barcode as an implicit API key check. Commit 0c8019a4aa7 ([FIX] product_barcodelookup: avoid crash on invalid image URLs) standardized `barcode_lookup_request()` to always
return a `requests.Response` object, removing the `{'authenticated': True}` dict it previously returned for HTTP 404 responses. As a result the JS check `response?.authenticated` was always falsy and the form never opened.
Fix: remove the API key check entirely. `allowProductCreation()` already gates on the user having product create rights, which is the only condition that matters. If a Barcode Lookup API key is configured the `_onchange_barcode` on the form will auto-fill product data; if not, the user can fill it in manually. Either way the form is always usable.
opw-6295221This update resolves a technical issue that caused the restaurant order tour to fail intermittently. The fix ensures the system waits for order updates to complete before proceeding, preventing duplicate requests and improving the reliability of the tour. This enhances the overall user experience for restaurant setup.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846 Forward-Port-Of: odoo/enterprise#119861 Forward-Port-Of: odoo/enterprise#110909
This update corrects a display issue in the list autofill feature of the Enterprise edition. Previously, a loading error was shown in tooltips when lists weren't immediately ready. Now, tooltips display the correct information, ensuring a smoother user experience when lists are loading.
Original PR description
The getter `getTooltipListFormula` would return the result of `getListHeaderValue` as the content of the tooltip, but this returned a loading error instead of a string if the list was not ready yet. Task: [6289944](https://www.odoo.com/web#id=6289944&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#119876
16 changes
Resolved issues and error corrections
This update adds a validation check to ensure employees have a defined work schedule (resource calendar and hours per week). This prevents issues with the DMFA process, ensuring accurate payroll calculations and data integrity. It's a necessary step to maintain the reliability of employee data within the HR module.
Original PR description
Added an @api.constrains check on resource_calendar_id and hours_per_week. Raises a translated ValidationError if both fields are left empty. Added validation since it's causing issue with DMFA. task-6296689
This update resolves an issue where sending NFC-e invoices would halt the POS synchronization process when IAP credits were exhausted. The change prevents the system from blocking POS updates, ensuring continued functionality even when IAP credit limits are reached. This improves reliability and prevents disruptions to sales operations.
Original PR description
When sending an NFC-e, tax calculation is done by calling Avatax through IAP. If the IAP account has no credits left, iap_jsonrpc() raises an InsufficientCreditError. opw-6290857 Forward-Port-Of: odoo/enterprise#120700
This update resolves a minor issue where deleting an Obox didn't properly remove associated queue records, leading to potential data inconsistencies. It also corrects a bug where duplicate device identifiers caused incorrect device updates. This ensures accurate device tracking and management within the Obox system.
Original PR description
This commit fixes two minor bugs: 1. Deleting an Obox record does not delete the queue records associated with it. If you link an Obox with the same serial again, the old queue actions are linked to with the smart button, but don't actually link to the new Obox record. 2. If an Obox discovers a device with the same identifier as an existing device linked to a different Obox, the device is not added, instead updating the other device.
This update resolves an issue causing instability in the systray highlight test. The team replaced a complex, temporary workaround with a more reliable implementation of the `useEffect` hook. This ensures the test consistently passes, improving the overall stability of the timesheet grid functionality.
Original PR description
This PR fixes the systray highlight test by using a simplified version of the old implementation of the `useEffect` hook instead of the setTimeout hack
This update resolves an issue where an incorrect amount was being duplicated in the Balance Sheet report for French financial statements. The fix involves adjusting a journal entry to accurately reflect partner accounts and eliminate the double-counting of 45 accounts under 'Borrowings and Similar Liabilities'.
Original PR description
1. Create a journal entry with: -> 455100 Partners/Associates - Current Accounts - Principal → Credit -> 512001 Bank → Debit 2. Navigate to Accounting → Reporting → Balance Sheet. -> Observe that the amount of the journal entry appears twice in the Balance Sheet: 1. Under Borrowings and Similar Liabilities 2. Under Partners' Current Accounts 45 accounts should not be included under borrowings and similar liabilities opw-6271305 Forward-Port-Of: odoo/enterprise#120282
This update corrects a previous issue where fully settled customers with past pay-later payments were incorrectly prevented from seeing their customer statements. The fix now checks for any past pay-later payment lines, ensuring the statement button remains visible even after the customer's total balance is paid off. This improves the user experience for all customers.
Original PR description
The override of _compute_has_moves was checking `total_due != 0` to set `has_moves` on for PoS pay_later customers. Once the customer is fully settled however, `total_due` is 0 and the check does not pass anymore, so `has_moves` goes back to `False` and the Customer Statement button hides for them, even though they had past pay_later payment lines. The fix is to check directly for any past pay_later `pos.payment` instead, which covers the cases where partner had used pay_later payment methods before, regardless if they have settled their total due or not. opw-6173760 Forward-Port-Of: odoo/enterprise#120911 Forward-Port-Of: odoo/enterprise#116536
This update adds a required field for UNECE code to UoM units, resolving previous issues with UBL/CII validation. This ensures Odoo correctly handles international trade documents and improves compliance with industry standards. It addresses a limitation in the previous static mapping approach.
Original PR description
Before this PR, we mapped UoMs with UNECE codes using a static dictionary. However, due to this static nature, some UoMs were missing the UNECE code, which created validation issues for UBL/CII. To address this issue, we introduce a new UNECE code field on UoM, which will be utilised by the UBL/CII for setting unitCode on Quantity nodes. task-6171459 Community PR - https://github.com/odoo/odoo/pull/261975 Upgrade PR - https://github.com/odoo/upgrade/pull/10091
This update fixes an error in the l10n_ph withholding tax report that was incorrectly adding a negative sign. The change has been reverted to use balances directly, ensuring accurate reporting of withholding taxes and aligning with how the system handles signed amounts. This improves the reliability of tax reporting.
Original PR description
A negative sign was added in the tax report of l10n_ph. This should not have been changed. The reason for the change was to set the balance negate of the tag, but this is incorrect. We therefore revert this change and remove the absolute value and balance negate from the query in the withholding tax report. Relying on these to force sign changes is incorrect. We can instead use balances directly: - `tax_base_amount` is used natively (signed). - `balance` is negated for the report presentation (to show credit-side withholding as positive).
This update resolves an issue where the rental and subscription status badges were overlapping in the sales order view. The fix replaces a positioning method with a simpler float-end approach, ensuring both badges are correctly displayed without interference. This improves the visual clarity of sales orders.
Original PR description
Steps to produce: --- - Install the `Rental` and `Subscription` modules. - Create a rental product and a subscription product. - Create a sales order containing both products and set a rental period.…
Steps to produce: --- - Install the `Rental` and `Subscription` modules. - Create a rental product and a subscription product. - Create a sales order containing both products and set a rental period. - Confirm the sales order. Issue: --- - The rental status badge overlaps the subscription status badge. Root cause: --- - The rental status badge uses the position-absolute CSS class to place it at the end of the header. When the subscription status badge is also displayed in the same area, both badges are positioned at the same location, causing them to overlap. - After [commit], this issue is introduced. Solution: --- - Replace position-absolute with float-end so the badges remain right-aligned without overlapping. [commit]: https://github.com/odoo/enterprise/commit/32ab15dc1f26af0e3d510ec859b1ec428068e9b5 Before: --- <img width="122" height="64" alt="image" src="https://github.com/user-attachments/assets/e6b47c9e-ed59-4a4b-a95c-0318cc43660e" /> After: --- <img width="175" height="57" alt="image" src="https://github.com/user-attachments/assets/ea98f7a1-67f6-4b2b-b699-1f2cd3376d8f" /> opw-6295212 --- Forward-Port-Of: odoo/enterprise#120660
This update fixes alignment issues within the Timesheet Assistant, specifically in the 'By Project' and 'Chronological' views. The changes ensure that descriptions and times are displayed correctly, even with lengthy project details, and adds a necessary margin to the 'No time recorded' section for better visual clarity.
Original PR description
# [FIX] timesheet_grid: alignment issues in assistant This commit resolves the following alignment issues in the Timesheet Assistant: - View "By Project", the time wraps if description too long - View "Chronological", the time wraps if descriptions too long and project / task is not truncated - No timesheet recorded does not have a margin start # [FIX] sale_timesheet_enterprise: alignment issues in assistant This commit adds margin start on the "No (non-)billable time recorded" information. task-6264756 Forward-Port-Of: odoo/enterprise#121054 Forward-Port-Of: odoo/enterprise#120608
This update fixes an issue where timesheet settings (specifically, whether a project is billable) would reset after the timesheet systray was closed and reopened. Now, the selected billable status is correctly saved and retained, ensuring accurate tracking of billable hours. This improves the reliability of timesheet data.
Original PR description
## Behavior before PR 1. Open the timesheet systray. 2. Select a billable project. 3. Toggle the is_billable field. 4. Close and reopen the systray. 5. The is_billable value resets to its default instead of keeping the updated value. ## Expected Behavior After this PR The systray now correctly retains the is_billable value after being closed and reopened. ### Technical Notes The issue occurred because the systray view loads a sudo record that triggers compute methods, which overwrite the stored is_billable value. The fix ensures that after compute methods run, the saved is_billable value is preserved. Forward-Port-Of: odoo/enterprise#121087 Forward-Port-Of: odoo/enterprise#119681
This update resolves an issue in the Data Cleaning app where record IDs were incorrectly summed and displayed alongside group names, leading to truncated names and inaccurate counts. The fix removes the automatic summation of IDs in grouped list views, ensuring correct group names and counts are shown.
Original PR description
## Issue In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which: 1. truncates the name and count of the groups 2. does…
## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)
<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />
## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
- Any name
- Model: *Contact*
- Rule:
- Field to Clean: *Name (Contact)*
- Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**
## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:
https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23
This causes the IDs to be summed up and appear in the group headers.
## After
<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />
related: https://github.com/odoo/odoo/pull/265163
opw-6166623
Forward-Port-Of: odoo/enterprise#115492This update resolves an issue preventing the correct export of balance sheet data in XML format for Luxembourg companies. The system now automatically includes a 'date_from' field, aligning with changes in the Odoo 19.2 version, ensuring accurate financial reporting.
Original PR description
Steps to reproduce: - setup a LU company - go to balance sheet - export the xml file - validate the wizard -> Traceback, because the code expects the options to contain the date_from, which is no longer the case since 19.2 as the balance sheet has by default only a date_to. The solution is therefore to define it for the export to the beginning of the fiscal year. Forward-Port-Of: odoo/enterprise#120843
This update resolves an issue where focusing on the end date within a daterange widget incorrectly modified the start date. The fix ensures that the correct date field is updated when a user interacts with the input fields, improving data accuracy and preventing unintended changes.
Original PR description
When a daterange widget is used (e.g., `deferred_start_date` coupled with `deferred_end_date`), focusing on the end date input was incorrectly modifying the start date field. This occurred because the `focusin` event was resolving the field name from the parent widget rather than the specific input focused. This commit updates `onFocusFieldWidget` and `getFullFieldName` to accept and evaluate the specific `event.target`. For `o_field_daterange` widgets, it now extracts the correct field name from the target's `data-field` attribute, ensuring the correct date field is updated. opw-6250048 Forward-Port-Of: odoo/enterprise#121099 Forward-Port-Of: odoo/enterprise#120684
This update clarifies timesheet tracking by changing the AW rule to display the name of the GitHub Pull Request instead of its ID. This provides better context for users, making it easier to link PRs to the relevant project or task within the Timesheets Assistant.
Original PR description
Before this commit, the AW Rule used in Timesheets Assistant will display the id of the Github Pull request and the repository but that information is not always clear for the user to know which project/task is related to that PR. This commit changes the AW rule for Github to display the name of the pull request instead to have more context to easily match the project/task to the event created by that rule. task-6306166 Forward-Port-Of: odoo/enterprise#121231 Forward-Port-Of: odoo/enterprise#120676
This update resolves an issue where new tasks created through Timesheets Assistant rules were incorrectly set as private. The fix ensures that tasks are always associated with the selected project, improving workflow and data organization within the Timesheets module. This prevents confusion and ensures accurate task tracking.
Original PR description
Steps to reproduce: - Install Timesheets and enable Timesheets Assistant. - Go to Timesheets -> Configuration -> Assistant Rules. - Open an existing rule or create a new one. - Select a Project and enter a new Task name. Issue 1: - Click Create. - The task is created as a private task, and the project is cleared. Issue 2: - Click Create and Edit. - Remove the project and save. - The task is saved as a private task. Cause: - When using Create, the `default_project_id` from the context is not applied, so the task is created as a private task. - When using Create and Edit, users can remove the prefilled project before saving, which also results in a private task. Fix: - Pass `default_project_id` and `form_view_ref='project.view_task_form_res_partner'` in the context. This prefills the project and makes it required when creating a task. task-6293306 Forward-Port-Of: odoo/enterprise#121188 Forward-Port-Of: odoo/enterprise#120862
5 changes
Resolved issues and error corrections
This update resolves an issue where tooltips in the spreadsheet edition's list autofill feature were displaying error messages instead of correct information when the list data wasn't yet ready. The fix ensures that tooltips display the correct data, improving the user experience and preventing misleading notifications.
Original PR description
The getter `getTooltipListFormula` would return the result of `getListHeaderValue` as the content of the tooltip, but this returned a loading error instead of a string if the list was not ready yet. Task: [6289944](https://www.odoo.com/web#id=6289944&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update adds a new testing option to our spreadsheet functionality. It allows developers to quickly test scenarios where the list data isn't immediately available, ensuring the spreadsheet handles loading delays gracefully. This improves the reliability and stability of the spreadsheet feature.
Original PR description
Added the parameter `skipWaitForDataLoaded` to `createSpreadsheetWithList` to test what happens when the list is not ready yet. Task: [6289944](https://www.odoo.com/odoo/2328/tasks/6289944) 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
This update resolves a problem where Italian fiscal printers would stop printing POS orders due to unsupported characters in product or payment method names. The fix replaces these characters with spaces, ensuring complete and accurate printing, as defined by EPSON's official documentation.
Original PR description
Steps to reproduce: - Setup an Italian fiscal printer - Modify the name of a product to use the non-blocking space character "\ "; - In the POS, create an order with the product. Error: the fiscal device will stop midway in the printing process and return an incomplete response to the frontend. The issue can also be reproduce if the character is included in the payment method name or the POS config name. Solution: When formating the xml command, replace all non-supported character by a space character. The non-supported character list is provided by the official [EPSON fiscal printer documentation](https://support.epson.net/setupnavi/?PINF=bsmanual&OSC=WS&LG2=EN&MKN=FP-90III%20RT) in the document "ePOS Fiscal Print Solution Development Guide". Other: Rename the file "dispaly_text.xml" to "display_text.xml". [opw-6244089](https://www.odoo.com/odoo/project/49/tasks/6244089)
This update resolves a crash that occurred when users attempted to view Instagram videos within Odoo. The fix now displays the video link instead of the image, ensuring a smooth user experience. This prevents the previewer from crashing when encountering a real Instagram video.
Original PR description
Purpose ======= When we have a real on Instagram, we try to show the video as an image. When clicking on the broken image, the previewer crash. To fix that issue, we know show the link of the video in the message. Task-5491124 Forward-Port-Of: odoo/enterprise#113487
This update resolves a bug that previously prevented the system from correctly calculating bill addresses when address fields were empty. Now, empty address fields are automatically set to empty strings, ensuring accurate billing information is processed. This improves the reliability of payment authorization transactions.
Original PR description
Fix bug introduced by commit https://github.com/odoo/odoo/pull/267592/changes/c4556637e8eeef07ce6e3cc3b3b4cf28fa10e468 that caused an error if an address field was not set, due to trying to cut a False field. Now, unset fields are set to empty strings. Forward-Port-Of: odoo/odoo#270295
4 changes
Resolved issues and error corrections
This update ensures GIF functionality in Odoo continues to work smoothly. The previous Tenor GIF API key is being replaced with a Klipy GIF API key due to the Tenor API's planned shutdown on June 30, 2026. Users will need to update their API key settings to ensure GIF sharing remains operational.
Original PR description
Tenor API will be terminated on June 30, 2026: https://developers.google.com/tenor/guides/quickstart This commit makes the Tenor API key input settings use a Klipy GIF API key instead of a Tenor GIF API key. To keep GIF working after this commit, the API key must necessarily be changed to a Klipy GIF API key, as the old Tenor API key would be considered as an invalid Klipy API key. Task-5491965 Upgrade: https://github.com/odoo/upgrade/pull/10516
This update resolves an issue in the 17.0 version of Odoo where users couldn't delete soda mapping records, leading to data management problems. The fix allows users to unlink these records, providing the necessary flexibility to correct errors and maintain accurate accounting data. This improves usability and prevents data blockage.
Original PR description
**PROBLEM** It's impossible to delete soda mapping in 17.0. So if you mess the mapping, you can't do anything about it. **STEP TO REPRODUCE** 1. Install l10n_be_codabox. 2. Select the belgium company, and goes to configurations/accounting. 3. Click on open soda mapping, create a new mapping line. 4. There is no way to delete it. opw-6293829
This update resolves a crash that occurred when users attempted to view Instagram videos within Odoo. The fix now displays the video link instead of the image, ensuring a stable preview experience. This improves user engagement and prevents disruptions when accessing Instagram content.
Original PR description
Purpose ======= When we have a real on Instagram, we try to show the video as an image. When clicking on the broken image, the previewer crash. To fix that issue, we know show the link of the video in the message. Task-5491124 Forward-Port-Of: odoo/enterprise#113487
This update resolves a bug that previously prevented the system from correctly calculating bill addresses when address fields were empty. The fix now sets empty address fields to empty strings, ensuring accurate billing information is processed. This improves the reliability of payment authorization transactions.
Original PR description
Fix bug introduced by commit https://github.com/odoo/odoo/pull/267592/changes/c4556637e8eeef07ce6e3cc3b3b4cf28fa10e468 that caused an error if an address field was not set, due to trying to cut a False field. Now, unset fields are set to empty strings. Forward-Port-Of: odoo/odoo#270295