Daily updates from Odoo
Tuesday, September 23, 2025
131 changes
14 changes
Resolved issues and error corrections
Changing a linked to-do item between numbered and bulleted lists no longer causes an error. The editor now cleans hidden formatting characters before saving the text selection, making list formatting more reliable for users.
Original PR description
Steps to Reproduce: 1. Go to To-Do 2. Create a link 3. Select all using Ctrl + A 4. Switch to order list and then unordered list. 5. Traceback occurs Description of the issue: - This issue occurs because a feff (zero-width no-break space) character is present inside the link. When the link is inside a list and the list type is changed, the `removeFEFF` method is triggered. `removeFEFF` removes the feff characters, but the selection is preserved based on positions from when those feffs were still present inside the link. As a result, after the list type is changed, restoring the selection causes a traceback. Solution: - Triggered `clean_handlers` before preserving the selection. This ensures feff characters are removed from the link before the selection is preserved, preventing invalid selection offsets and avoiding the traceback. task-5095561 Forward-Port-Of: odoo/odoo#227680
This update corrects the date used in a product margin test so automated checks reflect the intended business scenario. It helps keep margin-related quality checks stable and reduces the risk of false test failures during releases.
Original PR description
runbot-230719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227210 Forward-Port-Of: odoo/odoo#226089
Timesheet reports printed from sales orders now show the related helpdesk ticket name alongside the helpdesk team. This makes billed support work easier to identify and verify for customers and internal teams.
Original PR description
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report…
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name" Problem: ======== in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order. Solution: ========= `show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable. opw-5002650 Forward-Port-Of: odoo/enterprise#95179
Flexible employee shifts that span multiple weeks now show only the hours allocated to the selected week in the Planning Gantt progress bar. This prevents overstated workload figures and gives managers a clearer weekly capacity view.
Original PR description
### Steps to reproduce: - Install Planning app - Create a shift for a flexible employee that starts on Friday and end on the following Tuesday for example - Go to the gantt view for the week that the shift should start at - Notice the progress bar is showing the whole allocated hours not just the week's hours ### Cause: This mainly happening because when the employee is flexible we are getting the value by multiplying the hours_per_day of his schedule by the period.days and the period is the shift period ### Fix: We use the interval we are just checking as the period now so if the shift is extended to the next week we are just going to use the end of the week as the interval end not the shift's end_datetime opw-5022800 Forward-Port-Of: odoo/enterprise#93404
Creating a milestone from a confirmed Sales Order now keeps the correct project selected. This prevents an error for sales teams using milestone-based service invoicing and makes the workflow smoother.
Original PR description
**Steps to reproduce:** Create a service product with invoicing policy set to Based on milestones. Create and confirm a Sales Order with this product. Open the Sales Order and click on the Milestones stat button. In the milestones list view, click New to create a milestone. **Cause:** The default logic that was supposed to select the default project from context or active_id so it used the active_id which is Sales Order ID. **Issue:** When creating a milestone from a Sales Order, the project was not set correctly, which caused an error. **Fix:** Add the project_id field in list view to avoide default method call. task-5090316 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website shop product page now respects the editor setting for showing or hiding the Terms & Conditions block. This prevents customers from seeing that section when a business has intentionally disabled it.
Original PR description
**Description** - following this commit: odoo/odoo@bbb2d98d9ab97ce729d59b9858b63daccf5434e2 terms and conditions was explicitly called with t-call, which ignores whether the view is active or not. This caused the block to remain visible even when toggled off in the website editor. The fix ensures that the call to `website_sale.product_terms_and_conditions` is wrapped in `is_view_active(...)`, so the snippet is only rendered when enabled. **Steps to reproduce before the fix:** 1. Go to website → open any product in edit mode. 2. Toggle off the Terms & Conditions option. 3. The block still shows up. **After the fix:** toggling off correctly hides the block. opw-5096452 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Belgian payroll Dimona module now prevents editing the student status directly on employee records when that status is controlled elsewhere. This avoids inconsistent employee data and reduces the risk of payroll or reporting errors.
Original PR description
This commit marks `l10n_be_is_student` field as readonly in `hr.employee` model since it is a related field of `hr.version` and it is not editable in `hr.version` and so there is no reason to make in editable in employee model. runbot-error-231303
The website search suggestions menu now chooses the side of the search bar with the most available screen space. This prevents the dropdown from appearing cramped or partially hidden when users zoom in or browse with a smaller window, improving the shop search experience.
Original PR description
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where…
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where there is the less space available. Cause: When the dropdown doesn't fit fully in the viewport below the searchbar it is always added on top even if there is less space available. The code was added in 15.0 62c265ee7d7cf36db01bf6a95b2c5ea9843ba2d3 with the intent of putting the dropdown on the top if it increased the page height when putting it below (eg. when we put a search bar in the footer). But in saas-18.2 refactoring (b9b3a605e0f4c5da3a258c980107d6162da7f44f), the code was rewritten and now: - the dropdown has a scroll bar if it is too big to fit on viewport - if the dropdown doesn't fit fully below the searchbar in the viewport, it is placed above the searchbar even if there is less space Fix: place the dropdown below the searchbar if there is more space below than above. opw-5019685 Forward-Port-Of: odoo/odoo#225220
This fixes an HR issue where updating employee version records could fail when the selected records belonged to different employees. HR teams can now apply changes more reliably without errors in multi-employee scenarios.
Original PR description
Problem: the write method on the version is not working if the versions are coming from multiple employees. This commit fixes the issue by taking care if the versions belong to different employees. task-5085086 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
The Spanish Modelo 130 report now uses an end-date selection instead of a date range. This prevents users from expecting only the selected range while the report actually calculates from the start of the fiscal year, reducing confusion in tax reporting.
Original PR description
Currently mod130 report is configured to compute from the beginning of the fiscal period, however the date filter widget is in range mode. This means that when a user open the report and select a date range, the entries will not be just in the selected range but span from the beginning of the fiscal year to the end of the range, creating confusion. We should disable filter date range, so the date widget allow to set an end date to the current period Enterprise PR: https://github.com/odoo/enterprise/pull/90044 opw-4933241 Forward-Port-Of: odoo/odoo#226177 Forward-Port-Of: odoo/odoo#218544
This update adds test coverage for Spain's Modelo 130 tax report to help ensure it continues to calculate and display correctly. It reduces the risk of reporting issues for Spanish businesses relying on this tax workflow.
Original PR description
opw-4933241 Forward-Port-Of: odoo/enterprise#94251 Forward-Port-Of: odoo/enterprise#90044
This fix prevents live chat call cleanup logic from disrupting automated checks for operator assignment and chatbot call behavior. It helps keep internal quality checks stable without changing the customer-facing live chat experience.
Original PR description
Since [1], rtc sessions are garbage collected when creating new live chat sessions. Rtc sessions that didn't receive any update during the last minute are considered as inactive. This can interfere with agent assignation tests: operators in a call are not prioritized. If the session is garbage collected, they are not in a call, and tests can fail. fixes runbot-232705 [1]: https://github.com/odoo/odoo/pull/211359 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#227716 Forward-Port-Of: odoo/odoo#227648
The offer creation form now uses the correct employee when opened from an employee record. This prevents users from seeing the wrong employee name in the "Offer for" field, reducing confusion during offer preparation.
Original PR description
#### Steps to reproduce Employees -> Create employee (or select employee) with offer -> Offers smart button -> New: wrong employee name in "Offer for ..." #### Reason Wrong key passed to context of the offers view via action_show_offers method #### Solution Replace key 'default_employee_version_id' with 'default_employee_id' task-5003544
Long out-of-stock messages on product pages now stay within their visible badge or message area when the screen is narrowed. This prevents messy overflow on the shop page and improves the customer experience on smaller screens.
Original PR description
When the Out-of-Stock message contains a long string of text at certain screen sizes, the text is longer than the parent div Steps to reproduce -------------------- 1. Have a tracked product with Continue Selling off and a long custom Out-of-Stock Message. 2. View the product shop page on the website. 3. Reduce the horizontal screen size until the text goes over the edge of the parent div(red rounded box). Cause ----- No CSS to handle when the text is longer than the parent element. Solution -------- Add text-wrap to parent div so the child element text wraps when necessary. opw-5056843
8 changes
Resolved issues and error corrections
Fixed an issue in the HTML editor where changing a linked item between numbered and bulleted list styles could cause an error. Users can now edit list formatting in To-Do content more reliably without interruptions.
Original PR description
Steps to Reproduce: 1. Go to To-Do 2. Create a link 3. Select all using Ctrl + A 4. Switch to order list and then unordered list. 5. Traceback occurs Description of the issue: - This issue occurs because a feff (zero-width no-break space) character is present inside the link. When the link is inside a list and the list type is changed, the `removeFEFF` method is triggered. `removeFEFF` removes the feff characters, but the selection is preserved based on positions from when those feffs were still present inside the link. As a result, after the list type is changed, restoring the selection causes a traceback. Solution: - Triggered `clean_handlers` before preserving the selection. This ensures feff characters are removed from the link before the selection is preserved, preventing invalid selection offsets and avoiding the traceback. task-5095561 Forward-Port-Of: odoo/odoo#227680
Timesheet reports printed from a sales order now show the related helpdesk ticket name alongside the helpdesk team. This makes billed support work easier to identify and verify for customers and internal teams.
Original PR description
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report…
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name" Problem: ======== in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order. Solution: ========= `show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable. opw-5002650 Forward-Port-Of: odoo/enterprise#95179
A date used in the product margin test was corrected to keep automated checks reliable. This helps prevent false test failures and supports smoother maintenance without changing business functionality.
Original PR description
runbot-230719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227210 Forward-Port-Of: odoo/odoo#226089
This fix stops Argentina partner records from crashing when an invalid VAT or identification value is entered. It makes data cleanup more reliable and helps users continue working even when tax ID inputs contain unexpected characters.
Original PR description
Manual backport of https://github.com/odoo/odoo/commit/b01a6640895c4dd4b5bcf849740aa6b3312e9a54. This is needed to prevent crashes when trying to sanitize invalid VAT inputs for Argentina partners due to the assumption that the identification number can always be safely cast to int(). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223661
The website search suggestions dropdown now chooses the side of the search bar with the most available space. This prevents suggestions from appearing in a cramped area, improving usability for shoppers using high zoom levels or smaller browser windows.
Original PR description
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where…
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where there is the less space available. Cause: When the dropdown doesn't fit fully in the viewport below the searchbar it is always added on top even if there is less space available. The code was added in 15.0 62c265ee7d7cf36db01bf6a95b2c5ea9843ba2d3 with the intent of putting the dropdown on the top if it increased the page height when putting it below (eg. when we put a search bar in the footer). But in saas-18.2 refactoring (b9b3a605e0f4c5da3a258c980107d6162da7f44f), the code was rewritten and now: - the dropdown has a scroll bar if it is too big to fit on viewport - if the dropdown doesn't fit fully below the searchbar in the viewport, it is placed above the searchbar even if there is less space Fix: place the dropdown below the searchbar if there is more space below than above. opw-5019685 Forward-Port-Of: odoo/odoo#225220
The Spanish Modelo 130 report now uses an end-date selection instead of a date range. This prevents users from expecting results for only a selected range when the report is designed to calculate from the start of the fiscal period, reducing confusion in tax reporting.
Original PR description
Currently mod130 report is configured to compute from the beginning of the fiscal period, however the date filter widget is in range mode. This means that when a user open the report and select a date range, the entries will not be just in the selected range but span from the beginning of the fiscal year to the end of the range, creating confusion. We should disable filter date range, so the date widget allow to set an end date to the current period Enterprise PR: https://github.com/odoo/enterprise/pull/90044 opw-4933241 Forward-Port-Of: odoo/odoo#226177 Forward-Port-Of: odoo/odoo#218544
This update adds test coverage for the Spanish Modelo 130 tax report to help ensure it continues to calculate and display correctly. It reduces the risk of regressions in Spanish tax reporting after future changes.
Original PR description
opw-4933241 Forward-Port-Of: odoo/enterprise#94251 Forward-Port-Of: odoo/enterprise#90044
The point of sale payment screen now correctly disables the Validate button on mobile when no payment method is selected. This helps prevent checkout mistakes and gives cashiers clearer guidance during mobile payments.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. task-id: 5072759 enterprise PR: https://github.com/odoo/enterprise/pull/94100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225975 Forward-Port-Of: odoo/odoo#225917
2 changes
Resolved issues and error corrections
Timesheet reports printed from a sales order now include the related helpdesk ticket name alongside the helpdesk team. This prevents incomplete report details and makes billed support time easier to understand for customers and internal teams.
Original PR description
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report…
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name" Problem: ======== in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order. Solution: ========= `show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable. opw-5002650 Forward-Port-Of: odoo/enterprise#95179
This update adjusts a Hong Kong payroll accounting test after a related leave-generation method changed in an earlier version. It helps keep automated checks passing, reducing the risk of delays when validating payroll-related updates.
Original PR description
Explanation: _generate_leave method is updated in saas-18.1. build_error-229902
16 changes
Resolved issues and error corrections
Removed an unnecessary developer log from the spreadsheet chart configuration area. This keeps the browser console cleaner and avoids exposing irrelevant internal messages during normal use.
Original PR description
Task: 0 Forward-Port-Of: odoo/enterprise#95135
Searching from the Help page now waits for the needed background response before showing results. This prevents users from seeing an error screen and makes help content search work reliably.
Original PR description
Steps to reproduce: 1. Navigate to the Help menu. 2. Search for any term in the search bar. - A traceback occurs. Issue: The search method did not wait for the RPC call to complete and returned a promise prematurely, leading to an unhandled traceback. Fix: Ensure the method properly awaits the RPC call before returning the result. Forward-Port-Of: odoo/enterprise#94565
This fix prevents an error when the same Chilean electronic tax document is imported more than once. Instead of crashing, the system can now handle the duplicate import message correctly, improving reliability for Chilean localization users.
Original PR description
### Steps to reproduce: - Install 'l10n_cl_edi' and switch to a Chilean company - Import twice the same DTE XML file. ### Cause: This [commit](https://github.com/odoo/enterprise/commit/42744fcecdbd36ea0101070c68299227a9f204a6) forgot to add the `_()` method to format the message. As `append()` only needs one argument but two are given, there is a traceback. opw-5080094 Forward-Port-Of: odoo/enterprise#94929
Timesheet reports printed from sales orders now show the related helpdesk ticket alongside the helpdesk team. This makes billed support work easier to identify and avoids unclear report lines for customers and staff.
Original PR description
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report…
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name" Problem: ======== in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order. Solution: ========= `show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable. opw-5002650 Forward-Port-Of: odoo/enterprise#95179
Spanish translations for Peruvian electronic invoicing and stock documents were corrected where tariff fraction and withholding code labels were inaccurate or inconsistent. This helps users see the right wording on localization-related records and reduces confusion in compliant Peruvian reporting workflows.
Original PR description
## Issue: The latest `tariff_fraction` entries were not properly translated into Spanish There were also inconsistencies in the translation of some `withhold codes` ## Cause: The `.po` and `.pot` files were not correctly populated In addition, the translation of "Others" in `l10n_pe_withhold_code` conflicted with `l10n_pe_edi_reason_for_transfer__13`, because the `msgid` is the same but not the `msgstr` should be different opw-4741731 Forward-Port-Of: odoo/enterprise#95019 Forward-Port-Of: odoo/enterprise#92758
Restaurant POS orders no longer ask staff to send items to preparation when no preparation printer or display is configured. This prevents confusing checkout prompts and keeps payment flow smooth for configurations that do not use kitchen preparation routing.
Original PR description
Steps to reproduce: - Open a pos restaurant config that has no prep printer/display. - Add an orderline. - The order button appear and if you try to pay the popup ask for send to preparation is shown. Issue: If there is no preparationCategories for a config getOrderChanges consider that all the available categories are the preparationCategories. Fix: If there is no preparationCategories, set the orderline uiState hasChange to false. Note: When no preparation printer category is defined, no categories is to be return by default. For the preparation display, if no preparation categories is selected preparationCategories will return all the available categories. Task-5016231 Forward-Port-Of: odoo/enterprise#94672 Forward-Port-Of: odoo/enterprise#92541
A barcode workflow test was adjusted to wait for the correct step before continuing. This reduces false build failures caused by timing issues, helping keep validation of stock barcode processes more dependable.
Original PR description
The `test_put_packs_in_existing_pack` tour was using an erroneous trigger causing race condition. This commit replaces this trigger by another one to be sure previous step is completed before going forward. Runbot build error: [232638](https://runbot.odoo.com/odoo/runbot.build.error/232638) Forward-Port-Of: odoo/enterprise#95131
Salary offer pages now use the standard theme background color instead of a fixed color. This keeps the page readable and visually consistent when users work in dark mode.
Original PR description
With this commit the background-color is not hardcoded anymore; the background color is calculated with the bootstrap variable text-bg-secondary task-5089515 Forward-Port-Of: odoo/enterprise#94751
This update adds test coverage for Spain's Modelo 130 tax report to help ensure it continues to calculate and behave correctly. It reduces the risk of regressions in Spanish tax reporting without changing day-to-day user workflows.
Original PR description
opw-4933241 Forward-Port-Of: odoo/enterprise#94251 Forward-Port-Of: odoo/enterprise#90044
Unused AI-related code paths and an obsolete route were removed after the underlying methods had already been deleted. This reduces the chance of errors from outdated AI composer functionality and keeps the module easier to maintain.
Original PR description
Methods like **_ai_submit_to_model**, **_ai_add_message_to_context**, and **_ai_create_response** have been removed, along with the route **/ai/generate_w_composer**, from this [commit] [commit]: https://github.com/odoo/enterprise/commit/f8b9d475c0f19e5746ec47fe535c2030d117b534#diff-292213f329cde8a43c2882d1a0a972016a2fccb2f467fc79b196ebc2ae00f681L133-L191 In this commit, we are removing the method where the route and the referenced methods are called. sentry-6685514254 Forward-Port-Of: odoo/enterprise#95110
A test in the Indian payroll module is now allowed to run because the related salary contract app no longer causes it to fail. This improves confidence in payroll quality checks without changing day-to-day user workflows.
Original PR description
- Removed the test skip since the test is now working correctly task-5067701
This update corrects a failing automated test for printing the planning calendar. It ensures the test uses the expected response value, helping keep planning calendar quality checks reliable without changing user-facing behavior.
Original PR description
This commit's purpose is to fix the planning calendar print test. Source of the issue: the empty dict that the mockrpc returns is evaluated as a truthy value and leads to an extra execute of the doAction function with an invalid value. Solution: Return false instead of an empty dict task-5079063 Forward-Port-Of: odoo/enterprise#95023
Small visual alignment issues in the spreadsheet topbar were corrected. Filter badges and collaborator avatars now appear more consistently positioned, giving users a cleaner and more polished interface.
Original PR description
- the global fitler badge was slightly misaligned - the user avatars in the collaborative status had a border created by a padding with a background color. We should use an a actual border instead, as the padding had a decimal value leading to the items inside looking slightly misaligned. Borders don't have this issue, as they are rounded to the nearest pixel. Task: [5086022](https://www.odoo.com/odoo/2328/tasks/5086022) Forward-Port-Of: odoo/enterprise#94737
This fix prevents payslip creation from failing when an employee payroll input is set to zero while the payslip has its own value. Payroll teams can now use zero values reliably without unexpected errors during payslip generation.
Original PR description
Reproduce: 1. Create a salary rule based on a salary input and make it available for both employee and payslip. 2. Configure the input on both employee and payslip. 3. Set the property value to zero on the employee form and give it a value on the payslip. 4. Try to create a new payslip for this employee. Issue: `dict(payslip.version_id.payroll_properties)` does not return the property if its value is zero. Fix: Use `version_properties.get(key, 0)` to avoid the KeyError. Task: 5082135 Forward-Port-Of: odoo/enterprise#94475
This update adjusts an automated test for sales planning so it matches the latest Gantt scheduling behavior. It helps ensure the planning dialog opens correctly, reducing the chance of future scheduling issues going unnoticed.
Original PR description
Before this commit, the multi-create feature has been added to the gantt view of planning but the tour testing the planning gantt view has not been adapted accordingly. This commit adds a new step to make sure the plan dialog is opened as expected. runbot-error-230670 Forward-Port-Of: odoo/enterprise#95258
Sign requests in the Documents list are now ordered with the newest items at the top. This helps users find and open recent signature requests faster without scrolling through older entries.
Original PR description
Before: * New sign requests appeared at the bottom of the `Documents` list. * Users had to scroll down to find the latest requests. After: * The list is now sorted by creation date (newest first). * New sign requests appear at the top of the`Documents` screen. Impact: * Makes it easier for users to quickly find and access the most recent sign requests. task-5098740 Forward-Port-Of: odoo/enterprise#95104
22 changes
Resolved issues and error corrections
Fixed an issue in the HTML editor that could cause an error when users changed a linked to-do item between numbered and bulleted lists. This improves editing reliability and prevents interruptions while formatting content.
Original PR description
Steps to Reproduce: 1. Go to To-Do 2. Create a link 3. Select all using Ctrl + A 4. Switch to order list and then unordered list. 5. Traceback occurs Description of the issue: - This issue occurs because a feff (zero-width no-break space) character is present inside the link. When the link is inside a list and the list type is changed, the `removeFEFF` method is triggered. `removeFEFF` removes the feff characters, but the selection is preserved based on positions from when those feffs were still present inside the link. As a result, after the list type is changed, restoring the selection causes a traceback. Solution: - Triggered `clean_handlers` before preserving the selection. This ensures feff characters are removed from the link before the selection is preserved, preventing invalid selection offsets and avoiding the traceback. task-5095561 Forward-Port-Of: odoo/odoo#227680
This update corrects how default email recipients are selected in Accounting communications. It helps ensure accounting-related emails are addressed to the right partners, reducing manual corrections and potential communication mistakes.
Original PR description
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
Opening Studio from a project dashboard no longer triggers an error when there are no project update records yet. This prevents a disruptive crash during project configuration and keeps the setup flow working as expected.
Original PR description
An error currently occurs when opening the studio view. Steps to reproduce: --- - Install `Project` and `web_studio` - Project > Configuration > Projects > Create a New Project - Click on the `Dashboard` button > Open studio view - Error in terminal Traceback: --- `TypeError: object of type 'bool' has no len()` This error occurs because `project.update` doesn’t have any records. When opening the studio view, at [1] it tries to compute the record’s name, which is `False`, and `False` has no length. [1]- https://github.com/odoo/odoo/blob/e0322e2cbc16d2405e66f3b16cbabeac2ad265e7/addons/project/models/project_update.py#L80 sentry-6830573412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225070
This fix updates an automated test so it enables the discount and pricelist settings it needs before checking order calculations. It helps prevent false failures in validation systems when only the Sales app is installed, improving release reliability without changing customer-facing behavior.
Original PR description
This commit fix runbot issue cause by PR https://github.com/odoo/odoo/pull/226859 to compute discount depending on pricelist. Cause: - In subscription discount and pricelist are default enable that allow discount to compute properly and set it to 0 but when only sale is installed test was breaking because non of the condition was enabled require to compute discount properly. Fix: - Enabled discount and pricelist feature in testcase to compute discount properly runbot-232685 Forward-Port-Of: odoo/odoo#227706
The Live Chat channel screen no longer shows a misleading -1 rating percentage when no customer ratings have been received. This keeps reporting clearer for administrators by only displaying satisfaction percentages once at least one valid rating exists.
Original PR description
**Steps to reproduce:** - Install website_livechat - Initiate a conversation from the visitor's side - Close the conversation without providing a rating - Log in as 'Admin' - Go to Live Chat - Open the form view of the default channel **Current behavior before PR:** The stat button displays the `rating_percentage_satisfaction` field as -1, which is a fallback value used when there are no ratings. **Desired behavior after PR is merged:** The `rating_percentage_satisfaction` field is only displayed when we have received at least 1 valid rating. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when a Chilean company imports the same DTE XML file more than once. Users now receive the intended message instead of encountering a system traceback, improving reliability during electronic document processing.
Original PR description
### Steps to reproduce: - Install 'l10n_cl_edi' and switch to a Chilean company - Import twice the same DTE XML file. ### Cause: This [commit](https://github.com/odoo/enterprise/commit/42744fcecdbd36ea0101070c68299227a9f204a6) forgot to add the `_()` method to format the message. As `append()` only needs one argument but two are given, there is a traceback. opw-5080094 Forward-Port-Of: odoo/enterprise#94929
This fixes an internal test setup for the email campaign editor so it uses a lighter helper that is available in the relevant testing bundle. It helps keep automated checks reliable when the app is tested on its own, reducing the risk of false failures during development.
Original PR description
The full editor helpers require hoot to be loaded and it's not loaded in the assets bundle used for mailing_editor_theme.js. There is a more lightweight file that exists solely to expose `setSelection` which does not require hoot. runbot-232630
Timesheet reports printed from a sales order now include the helpdesk ticket name alongside the helpdesk team. This makes billed support work easier to identify and verify for customers and internal teams.
Original PR description
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report…
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name" Problem: ======== in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order. Solution: ========= `show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable. opw-5002650 Forward-Port-Of: odoo/enterprise#95179
This update fixes a date used in product margin testing, helping ensure the module’s automated checks remain accurate and stable. It reduces the chance of false test failures without changing everyday user functionality.
Original PR description
runbot-230719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227210 Forward-Port-Of: odoo/odoo#226089
This fix corrects small visual alignment issues in the spreadsheet top bar, including filter badges and collaborator avatars. The change makes the interface look cleaner and more consistent without changing how users work with spreadsheets.
Original PR description
- the global fitler badge was slightly misaligned - the user avatars in the collaborative status had a border created by a padding with a background color. We should use an a actual border instead, as the padding had a decimal value leading to the items inside looking slightly misaligned. Borders don't have this issue, as they are rounded to the nearest pixel. Task: [5086022](https://www.odoo.com/odoo/2328/tasks/5086022)
This update removes obsolete AI-related code paths that referenced functionality already removed elsewhere. It helps reduce errors and maintenance overhead without changing active user-facing features.
Original PR description
Methods like **_ai_submit_to_model**, **_ai_add_message_to_context**, and **_ai_create_response** have been removed, along with the route **/ai/generate_w_composer**, from this [commit] [commit]: https://github.com/odoo/enterprise/commit/f8b9d475c0f19e5746ec47fe535c2030d117b534#diff-292213f329cde8a43c2882d1a0a972016a2fccb2f467fc79b196ebc2ae00f681L133-L191 In this commit, we are removing the method where the route and the referenced methods are called. sentry-6685514254
The website search suggestion menu now opens on the side of the search bar with the most available room. This prevents the menu from appearing cramped or partially hidden when users zoom in or use a shorter browser window, improving shopping search usability.
Original PR description
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where…
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where there is the less space available. Cause: When the dropdown doesn't fit fully in the viewport below the searchbar it is always added on top even if there is less space available. The code was added in 15.0 62c265ee7d7cf36db01bf6a95b2c5ea9843ba2d3 with the intent of putting the dropdown on the top if it increased the page height when putting it below (eg. when we put a search bar in the footer). But in saas-18.2 refactoring (b9b3a605e0f4c5da3a258c980107d6162da7f44f), the code was rewritten and now: - the dropdown has a scroll bar if it is too big to fit on viewport - if the dropdown doesn't fit fully below the searchbar in the viewport, it is placed above the searchbar even if there is less space Fix: place the dropdown below the searchbar if there is more space below than above. opw-5019685 Forward-Port-Of: odoo/odoo#225220
A test for printing the planning calendar was corrected so it no longer triggers an invalid extra action during automated checks. This helps keep the planning feature's quality checks reliable without changing day-to-day user behavior.
Original PR description
This commit's purpose is to fix the planning calendar print test. Source of the issue: the empty dict that the mockrpc returns is evaluated as a truthy value and leads to an extra execute of the doAction function with an invalid value. Solution: Return false instead of an empty dict task-5079063
The payslip form now hides the warnings area when there are no issues to display. This removes unnecessary blank space and makes the payroll screen cleaner for users.
Original PR description
Before this change, the `issues` field was always rendered on the payslip form, even when there were no warnings to display. This resulted in unnecessary empty space being shown in the UI. task-5071223
The automated test for sales planning was updated to reflect a recent change in the planning calendar workflow. This helps ensure the scheduling dialog opens correctly and reduces the risk of future issues going unnoticed.
Original PR description
Before this commit, the multi-create feature has been added to the gantt view of planning but the tour testing the planning gantt view has not been adapted accordingly. This commit adds a new step to make sure the plan dialog is opened as expected. runbot-error-230670
Fixed an issue where creating a payslip could fail when an employee payroll property was set to zero. Payroll teams can now use zero values on employee records without blocking payslip generation or overriding payslip-specific values.
Original PR description
Reproduce: 1. Create a salary rule based on a salary input and make it available for both employee and payslip. 2. Configure the input on both employee and payslip. 3. Set the property value to zero on the employee form and give it a value on the payslip. 4. Try to create a new payslip for this employee. Issue: `dict(payslip.version_id.payroll_properties)` does not return the property if its value is zero. Fix: Use `version_properties.get(key, 0)` to avoid the KeyError. Task: 5082135
This update adds or adjusts automated checks for Spain's Modelo 130 tax report to help ensure the report remains reliable. It reduces the risk of regressions in Spanish tax reporting after future changes.
Original PR description
opw-4933241 Forward-Port-Of: odoo/enterprise#94251 Forward-Port-Of: odoo/enterprise#90044
The Spanish Modelo 130 report now uses an end-date selection instead of a date range. This prevents users from expecting only a selected range while the report correctly calculates from the start of the fiscal period, reducing confusion in tax reporting.
Original PR description
Currently mod130 report is configured to compute from the beginning of the fiscal period, however the date filter widget is in range mode. This means that when a user open the report and select a date range, the entries will not be just in the selected range but span from the beginning of the fiscal year to the end of the range, creating confusion. We should disable filter date range, so the date widget allow to set an end date to the current period Enterprise PR: https://github.com/odoo/enterprise/pull/90044 opw-4933241 Forward-Port-Of: odoo/odoo#226177 Forward-Port-Of: odoo/odoo#218544
The update ensures e-invoice action buttons appear only on the relevant sales or purchase journals. This reduces confusion for users by hiding refresh or fetch options where they do not apply, especially when Peppol self-billing is enabled.
Original PR description
At the moment: - If the `peppol_activate_self_billing_sending` field is set on the company, both the `show_refresh_out_einvoices_status_button` and the `show_fetch_einvoices_button` fields are set on sale and purchase journals. After this commit: - The `show_refresh_out_einvoices_status_button` should be shown only on sale journals, and on self-billing purchase journals if the `peppol_activate_self_billing_sending` field is set. - The `show_fetch_in_einvoices_button` should be shown only on non-self- billing purchase journals. task-none
This fixes a Website Editor issue where the Cover Image option could stay hidden after changing a blog snippet back to showing a single item. Editors can now reliably toggle snippet settings without losing access to the cover image control.
Original PR description
Steps to reproduce: 1. Open Website Editor and drop a single aside blog snippet. 2. Change the Fetched Elements option to > 1. - The Cover Image option disappears (expected). 3. Change the Fetched Elements option back to 1. - The Cover Image option stays hidden (unexpected). Issue: The Cover Image option visibility is managed by useDomState. In dynamic snippets, the core snippet is rendered by an Interaction, while options are rendered before the Interaction starts. Since useDomState observed the element before the Interaction rendered the final one, the option visibility became desynchronized. Fix: Use the `isSingleMode` state to ensure the Cover Image option remains in sync when toggling between 1 and >1 fetched elements. 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
Creating a milestone from a Sales Order now keeps the correct project selected, preventing an error during milestone setup. This helps sales and project teams use milestone-based service products without manual workarounds.
Original PR description
**Steps to reproduce:** Create a service product with invoicing policy set to Based on milestones. Create and confirm a Sales Order with this product. Open the Sales Order and click on the Milestones stat button. In the milestones list view, click New to create a milestone. **Cause:** The default logic that was supposed to select the default project from context or active_id so it used the active_id which is Sales Order ID. **Issue:** When creating a milestone from a Sales Order, the project was not set correctly, which caused an error. **Fix:** Add the project_id field in list view to avoide default method call. task-5090316 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227491
Product packaging options are now shown even when a product has no variants, as long as it offers multiple units of measure. This helps shoppers see available packaging choices more consistently on the website product page.
Original PR description
Packaging options was only viewable if a product had variants. Modify condition to view product packaging when it has multiple uoms. opw-5104189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
23 changes
Resolved issues and error corrections
Fixed an issue where importing certain electronic invoice files could fail if the file contained a zero base quantity. This makes invoice imports more reliable for customers receiving UBL/CII documents with that value.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Customers / Invoices" - Import a UBL file having a value of 0 for a `<cbc:BaseQuantity>` element **Issue:** The import fails due to a division by 0 at: `price_unit = (net_price_unit + rebate) / basis_qty` **Cause:** "basis_qty" is retrieved as followed: `basis_qty = float(self._find_value(xpath_dict['basis_qty'], tree) or 1)` If the element is not defined, it will fall back on 1. But if the element exists with a value of 0, the "_find_value" method will retrieve the string "0" which is not False and will not fall back on 1. Then it will become `0.0` once converted to float. opw-5062985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could appear when restaurant staff repeatedly edited a kitchen note and quantity before sending an order. The change helps keep point-of-sale order preparation workflows reliable and avoids unnecessary log errors during service.
Original PR description
Currently a `TypeError` is arising when user select a meal, add the 'Kitchen Note', change the quantity and hit 'Order'. Steps to reproduce this error: - Select a dish and add a 'Kitchen note', hit 'Order'. - Now edit the 'Kitchen note' and the quantity, hit 'Order'. - Again edit the 'Kitchen note' and the quantity, hit 'Order'. - The error appears in the logs. Error: `TypeError: 'NoneType' object is not subscriptable` This commit solves the above issue by checking if the `old_quantity` is not `None`. sentry-6013783573
The update prevents crashes when employee or working schedule timezone information is missing by safely using UTC as a fallback. This improves reliability in payroll and related workflows where missing timezone settings previously caused errors.
Original PR description
Currently a traceback occurrs from multiple places when there is no tz for employee and used in the `pytz.timezone` method.…
Currently a traceback occurrs from multiple places when there is no tz for employee and used in the `pytz.timezone` method.
https://github.com/odoo/enterprise/blob/517983ae9deec37795eb11522134a1f5ade31e9b/hr_payroll/wizard/hr_payroll_payslips_by_employees.py#L131
For instance, if there is no tz in resource_calendar_id, it leads to a traceback.
Error:
```
AttributeError: 'bool' object has no attribute 'upper'
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1892, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1955, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1922, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2169, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 70, in web_save
self.write(vals)
File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_contract.py", line 429, in write
res = super().write(vals)
File "addons/hr_work_entry_contract/models/hr_contract.py", line 453, in write
contract._recompute_work_entries(date_from, date_to)
File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_contract.py", line 441, in _recompute_work_entries
self._recompute_payslips(date_from, date_to)
File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_contract.py", line 453, in _recompute_payslips
all_payslips.action_refresh_from_work_entries()
File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_payslip.py", line 601, in action_refresh_from_work_entries
payslips._compute_worked_days_line_ids()
File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_payslip.py", line 1141, in _compute_worked_days_line_ids
slip_tz = pytz.timezone(slip.contract_id.resource_calendar_id.tz)
File "odoo/_monkeypatches/pytz.py", line 129, in timezone
return original_pytz_timezone(name)
File "__init__.py", line 183, in timezone
if zone.upper() == 'UTC':
```
To resolve this issue we can give a default value of `UTC` is there is no name. which makes the code more robust.
sentry-6134147853, 6119911834This fix prevents an error when users view or return to inventory quantity records that are missing location, lot, package, or owner details. The system now uses a default display name in those cases, helping users continue inventory updates without interruption.
Original PR description
Currently, an error occurs when computing a display name for stock quant. Step to produce: - Install the `stock` module(without demo data). - Go to inventory settings, enable Packages, Quality,…
Currently, an error occurs when computing a display name for stock quant. Step to produce: - Install the `stock` module(without demo data). - Go to inventory settings, enable Packages, Quality, Quality Worksheet, Reception Report, Variants, Units of Measure, Product Packagings, Lots & Serial Numbers, Display Lots & Serial Numbers on Delivery Slips, Expiration Dates, and Dropshipping. - Disable the Barcode Scanner. - After that, enable 'Display Lots & Serial Numbers on Invoices' in the Valuation section - Create a product and enable the 'Track Inventory' option. - In the product form view, click on On Hand in the breadcrumbs to navigate to the stock quantity list view - Create a new record to update the quantity. - Click on the 'View' button, remove the location, and try to come back to update quantity list view. `TypeError: sequence item 0: expected str instance, bool found` This error occurs because we compute the display name of stock quant and it is derived from location_id, lot_id, package_id, or owner_id. If none of these values are present in stock quant then the system tries to concate the False (bool) value with a string at [1] and an error occurs. Link [1]: https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/addons/stock/models/stock_quant.py#L585-L592 To resolve this issue, Assign a default display name of stock quant if none of the values of fields (location_id, lot_id, package_id, owner_id) are available. Sentry-6165002037 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Accounting report send wizard no longer crashes when users remove all recipients before sending or editing the email template. This prevents an unexpected error and lets users continue their workflow even when recipients are optional.
Original PR description
Currently, a traceback is occurring when the user tries to send a report by removing the partner in the wizard. To reproduce this issue: 1) install `Accounting` 2) Open the Partner Ledger report 3) Change the Report, Account to `Customer Statement` and `Payable` respectively 4) Click the `Send` button, and a send wizard will be opened 5) Remove the `Recipients` and navigate to the mail template from the wizard 6) In Email Configuration, enable the `Default Recipients` Error:- ``` KeyError: False ``` This traceback is occurring because the user removed the `mail_partner_ids` which is indeed not a required field. This leads to the traceback from the below line when accessing the `partner.id` from the mail_field_values. https://github.com/odoo/enterprise/blob/28b6a5d30274f4265c978433b8d02b758d9a032e/account_reports/wizard/account_report_send.py#L92-L96 sentry-6348424386
CodaBox connection management now shows a clear user-facing error when the selected accounting firm has no VAT number. This prevents a confusing technical crash and helps users correct the missing company information before continuing.
Original PR description
The system fails to retrieve vat number of accounting firm when computing `l10n_be_codabox_fiduciary_vat` field value Steps to Produce: 1. Install the `l10n_be_codabox` module and switch to `BE Company CoA` company. 2. Set Accounting firm without vat for BE Company CoA 3. Goto setting > Accounting section > CodaBox & SODA 4. Click `Manage Connection` or refresh icon of CodaBox Connection Error: `TypeError: expected string or bytes-like object, got 'bool'` Solution: Raise `UserError` if value of `account_representative_id.vat` is False Sentry - 6499169614
Users installing modules now receive a clean, understandable error if they upload a file that is not a valid ZIP archive. This prevents a technical crash message and improves the module installation experience.
Original PR description
The error could occur when a user uploads a non-ZIP or malformed ZIP file during module installation. The `zipfile.ZipFile` call raises `BadZipFile` when the file is invalid, but this was not properly caught in all cases. `Error: 'BadZipFile: File is not a zip file'` Solution: -Wrapped the `zipfile.ZipFile(BytesIO(zip_data), 'r')` and similar elements inside a `try...except` block to catch `BadZipFile` and raise a clean `ValidationError`, preventing unhandled exceptions and improving UX. sentry-6066860008
The PDF Quote Builder now blocks empty files before they are uploaded. This prevents users from hitting an error when configuring quotation headers or footers and keeps the setup flow smoother.
Original PR description
Currently, a error is encountered on uploading an empty file in a `PDF Quote Builder` . **Steps to reproduce:** - Install `Sales` - `Sales>Configuration>Settings` - Under `Quotations & Orders>PDF Quote builder>Headers/Footers`, upload an empty file or try this [demo_file](https://drive.google.com/file/d/1NePURnYY3EK63vXM_uz8weJZwDbUbHfc/view?usp=sharing) **Error:** `EmptyFileError: Cannot read an empty file` **Root Cause:** The error occurred because the system attempts to read the uploaded file at [1] triggered by [2]. If the uploaded file is empty, it raises an `EmptyFileError`. [1] - https://github.com/py-pdf/pypdf/blob/5735cb742a45a503e8eb7e409067f7c3d4cb9158/PyPDF2/pdf.py#L1691 [2] - https://github.com/odoo/odoo/blob/9463bfeb58fb40176ecf1131bac6627a1627d02c/odoo/tools/pdf/_pypdf2_1.py#L18 This commit ensures that users cannot upload empty files. sentry-6519503224,6519471276
Purchase bills in the Indian GSTR-2B workflow now return to a clean reconciliation state when reset to Draft. This prevents old return-period links or exceptions from carrying over, helping teams reconcile the bill correctly from the beginning.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582 Forward-Port-Of: odoo/enterprise#95026
Email Marketing now handles incorrectly encoded pasted images more gracefully when editing an email template. Instead of failing with a technical crash, the system can inform the user that the image content is invalid, helping prevent corrupted images from being used in mass mailings.
Original PR description
When user edits mail template html and pastes an image tag with invalid encoding it throws an error. **Steps to reproduce:** * Install Email marketing and activate developer mode. * Email…
When user edits mail template html and pastes an image tag with invalid encoding it throws an error. **Steps to reproduce:** * Install Email marketing and activate developer mode. * Email marketing>New>Mail Body> Start From Scratch>click `</>` icon * Paste any improper image element which doesn't have proper base64 encoding, for example: `<img src='data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU 5ErkJgg'/>` * Enter any Subject name and save. `binascii.Error: Invalid base64-encoded string: number of data characters (113) cannot be 1 more than a multiple of 4` **Solution:** * It would be better to let the user know about the error than to let them mass mail corrupted image element. * This can be done and handled by a try and except statement when the image element added is not proper. Sentry-6495526846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an unexpected error when users customize reports in Studio. It makes report editing more reliable by safely handling missing internal comparison data instead of interrupting the user workflow.
Original PR description
Currently, `KeyError: None` might occur when customizing the `Reports ` in **studio**. - The `KeyError` can occur in the `diff` method when the `DIFF_ATTRIBUTE` is absent in the `new_tree`. - This happens because the code at [1] attempts to access `self.map_id_to_node_old[new_tree.get(DIFF_ATTRIBUTE)]` without verifying if `new_tree.get(DIFF_ATTRIBUTE)` is `None`. [1]- https://github.com/odoo/enterprise/blob/c6148cd50e7446e43b3f327a4c25e7c0ffa03446/web_studio/controllers/keyed_xml_differ.py#L239 - This commit ensures the code handles cases where `DIFF_ATTRIBUTE` is missing and preventing KeyError. sentry-6430937782
Fixes an issue where automated cleanup of old Ecuador withholding wizard records could fail when related withholding lines still existed. This prevents background terminal errors and keeps scheduled maintenance running smoothly without affecting users in the interface.
Original PR description
Foreign key error occurs when a cron job deletes a `withhold (transient model)` still linked to a `withhold.line`. The error appears in the terminal, not the UI. To reproduce, ensure withhold records…
Foreign key error occurs when a cron job deletes a `withhold (transient model)` still linked to a `withhold.line`. The error appears in the terminal, not the UI. To reproduce, ensure withhold records in `l10n_ec_wizard_account_withhold` are old enough to be removed by `Auto-vacuum`. Refer to [this](https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7493C1-L7493C87) to understand how transient models are cleaned by the `Auto-vacuum` process. **Steps to reproduce:** * Install `l10n_ec_edi` and `accountant` * Change company to `EC company` * `Accounting>Customers>Invoices>New` * Confirm invoice with customer as `EC company` and `Payment method (SRI)` as Credit card * Add Withhold > Set document number to `001-001-123456789` > Add withhold lines * `Create and Post`(error will occur when cron tries to delete transient model transient model after couple of hours.) `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line'` **Solution:** * Unlink withhold lines first and then let normal unlink take place. **Sentry-6253783256**
This update adjusts spreadsheet-related testing assets to correct an issue in the FRGI test setup. It helps keep spreadsheet functionality more reliable by ensuring the relevant tests run as expected.
Original PR description
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 fixes company filtering by country, which previously did not work because the country field could not be searched. Businesses using country-specific localizations, such as Belgium or Switzerland, can now apply company restrictions by country as intended.
Original PR description
As the company country_id field was computed and not searcheable, it was not possible to restrict the company domain per country. This is needed in some l10n, like BE or CH. This commit implements the search method for the country_id field of the company. Done as part of task-5096037 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 fixes an issue where the command palette could crash when a task status field had no available options, such as in some Field Service task workflows. Users can now open command search safely; unavailable status actions are simply hidden instead of causing an error.
Original PR description
**Steps to reproduce:** - Installed industry_fsm (Field Service) module - Navigate the menu Field Service -> Configuration -> Project - Create a new project - Then Navigate the menu My Tasks -> Tasks…
**Steps to reproduce:** - Installed industry_fsm (Field Service) module - Navigate the menu Field Service -> Configuration -> Project - Create a new project - Then Navigate the menu My Tasks -> Tasks - Create a new task with the new created project - Then using the keyboard shortcut ctrl + k for command search, an error occurs **Cause:** - When the `stage_id` statusbar had no possible values, `this.getAllItems()` returned an empty array. - The command `isAvailable` unconditionally accessed `this.getAllItems().at(-1).isSelected`, which is undefined, causing a crash.[see](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L147-L148) **Fix** - Add safe check in the command action so it does not attempt to select a non-existent "next" item. **Result** - The command palette no longer crashes when the `stage_id` field has no available items. Instead, the command is simply unavailable. opw-5084130 upg-3130405 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#227440
Merging timesheet entries linked to the same helpdesk ticket now keeps that ticket connection intact. This prevents support work records from becoming detached from the related customer issue, and blocks merges when selected entries belong to different tickets.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090
This fixes an issue where changing the address of a Czech company with demo data could fail with a validation error. Demo accounting dates are now aligned so company details can be saved normally without disrupting document numbering checks.
Original PR description
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo…
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo data throws Validation Error #### Current behavior before PR: When trying to change address of CZ Company while l10n_cz with demo data is present an error popup is displayed and it's not possible to to save the changes. Steps to reproduce: - Install l10n_cz with demo data - Open CZ Company in form view - Change address (e.g. change city Praha -> Brno) - Click Save #### Desired behavior after PR is merged: The address changes are saved without any error. #### Solution: This change adds `taxable_supply_date` date values for CZ demo moves that are compatible with `invoice_date` values to make sure that accounting date values are the same on each recomputatation and do not lead to new sequence numbers that are not aligned with the previous ones which would cause errors being raised by sequence mixin. Related to: #226152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Belgian POS fiscal reporting screens no longer show the warning "THIS IS NOT A VALID VAT TICKET" on invoices and daily reports. This avoids confusion by keeping the warning only where it belongs: on POS receipts that are not final VAT tickets.
Original PR description
- Remove the message "THIS IS NOT A VALID VAT TICKET" from the invoices and POS daily reports views. This message is only necessary on POS receipts that are not final TVA tickets. task-id: 5013860
Creating a mail blacklist entry from a website form no longer fails with an unexpected error when the email field is missing. Instead, Odoo now shows a clear user-facing error, improving reliability for website form submissions.
Original PR description
Currently, an error occurs when creating a blacklist entry from the website. Steps to Reproduce: - Install the `website_crm_iap_reveal`, `website_mass_mailing` and `web studio`. - Go to `Website` > any page, click `Edit`, and drag and drop a `Form` onto the page. - Select the form, in `Action` dropdown, choose `More models` and select `Mail Blacklist`. Save the changes. - Click the Submit button. `KeyError: 'email'` This error occurs when creating a blacklist entry from the website and the email field is missing. When it tries to access the email key in value[1] while creating the record, it raises a KeyError. [1] https://github.com/odoo/odoo/blob/d83801027c9a88b6e4db8166b6e2aad41ed760b9/addons/mail/models/mail_blacklist.py#L31 This commit ensures that if the email is not present in the value, a UserError is raised. sentry-6708162583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when users open sales order line details with invoice lines from a product form dialog. It ensures the accounting matching widget uses the current record context when a search context is unavailable, avoiding an unexpected crash in this workflow.
Original PR description
…in a dialog Steps to reproduce ================== Prerequisites: Having a product with an SO and an Invoice confirmed. Steps: - Open Product Variant Form - Open Studio - Add new O2M to SOL: Product (Sale Order Line) - Edit subview form - Add invoice_lines - Quit Studio - Click on SOL on Product view → It crashes => TypeError: can't access property "context", ctx.env.searchModel is undefined Cause of the issue ================== In form view dialogs, we don't have a search model Solution ======== We should use the context from the current record opw-4921186
Automation rule setup now avoids carrying an internal archived-record setting into later selection dialogs. This prevents archived contacts or users from appearing where they should not, making configuration cleaner and less confusing.
Original PR description
**Before** - the active_test context key is part of the main base_automation action (base_automation_act), but this context key stays in the context further, leading to unwanted filtering in i.e. the…
**Before** - the active_test context key is part of the main base_automation action (base_automation_act), but this context key stays in the context further, leading to unwanted filtering in i.e. the action_server_ids.resource_ref search view dialog. - Steps to reproduce: - have base_automation installed - create an automation rule targeting the res.users model - add an Update server action targeting the Partner field - in the resource_ref autocomplete, click on Search More... - the search view dialogs displays archived records **After** - we chose to instead have a default filter in the base_automation_act action to include archived records by default. As the context key to activate the default filter starts with 'search_default_', it is already cleared from the context when opening the form view (standard behavior). - when you reproduce the same steps as before, the archived records are no longer displayed in the search view dialog. **Additional Note** This fix requires to upgrade the base_automation module. opw-4886487
Employees and managers can now enter a checkout time directly from the Attendance Gantt popup for open attendances. This fixes a display issue that hid the checkout field when it was empty, reducing extra navigation and manual correction steps.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978
Archived or trashed documents are now correctly hidden when users search for document values while setting up automation actions. This prevents users from accidentally selecting removed documents, while still allowing archived automation rules to remain visible where intended.
Original PR description
This PR addresses an issue where trashed files in documents would still appear when clicking on 'search more' when searching for documents.document in a scheduled action's action. The issue is that…
This PR addresses an issue where trashed files in documents would still appear when clicking on 'search more' when searching for documents.document in a scheduled action's action. The issue is that the base_automation_act view sets active_test context to False. This context is propagated to view_base_automation_form and results in the context for the field action_server_ids to be active_test = False. The fix for this issue will just be setting active_test to True for the action_server_ids field. This will make it such that the 'search more' action will no longer display anything archived but archived automation rules will still be displayed which was probably the original intention of setting active_test to False in base_automation_act. Steps to reproduce bug on empty DB: 1) Install base_automation and documents modules. 2) Create a new automation rule targeting the documents module. Make sure to add a trigger. 3) Click on 'Add an action' in the page 'Actions To Do'. 4) In the wizard under action details, set the targeted field to 'folder' (folder_id). Leave the action as 'Update'. 5) Click on the 'Choose a value' drop down. 6) Click on 'Search more'. 7) Notice the number of documents that show up. The numbers on the top right hand side of the wizard should be 1-y/x where x is the total number of documents. 8) Go to the documents module and select any document. 9) Move the document to the trash with the actions button. 10) Repeat steps 4-7. Notice how the number of documents did not change. Behavior after bug fix: Upon completing step 10 of steps to reproduce on empty DB, the number of documents will be one less than what it was originally since we trashed one of the documents. task-4886487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
15 changes
Resolved issues and error corrections
Contacts in the Dominican Republic can now use valid 11-digit Cedula VAT identifiers, not only 9-digit RNC numbers. This prevents valid customer or company records from being incorrectly rejected during VAT checks.
Original PR description
**Issue** When inputting a VAT number with a length different from 9 digits, the check fails, even if the number is a valid Dominican RNC. **Steps to Reproduce** 1. Install Dominican localization and the VAT check module (base_vat), along with Contacts. 2. Go to Contacts, create a new contact for the Dominican Republic. 3. Insert "152-0000706-8" as the VAT. **Root Cause** The `check_vat_do` method only validated 9-digit RNC numbers via `stdnum.do.rnc.validate()`. 11-digit Cédula numbers are not supported. **Fix** - Updated `check_vat_do` to: * Validate 9-digit RNC numbers using `stdnum.do.rnc.validate()`. * Validate 11-digit Cédula numbers using `stdnum.luhn.validate()`. Opw-5004221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Sign reminder process no longer fails when a document is sent without a “Valid Until” date. This keeps scheduled reminder emails running reliably and avoids error logs for affected signing requests.
Original PR description
Currently below error occurs when cron "Sign: Send mail reminder" is executed.
Error: `TypeError("'<' not supported between instances of 'bool' and
'datetime.date'") while evaluating 'model._cron_reminder()'`
### Steps to reproduce :-
- Open 'Sign' >> Go to 'Templates' >> Click 'Send' on a template.
- Set 'Valid Until' field as empty and 1 as the 'Reminder' >> click 'Send'.
- Run 'Schedule Action' (cron) **Sign: Send mail reminder** ( make sure it has
been 2/3 days since last reminder or change the date to 2/3 days from today.
- The error appears in the log.
This commit solves the above issue by making sure that `validity` is passed.
sentry-6168813276This fix prevents an error in the accounting reconciliation wizard when journal items are not available to identify a company. The system now uses the current company as a safe fallback, helping users continue reconciliation without interruption.
Original PR description
The issue occurs when the system attempts to get a 'company_id' from the move line in the account reconciliation wizard, but the move lines are not available at [1]. Link [1]: https://github.com/odoo/enterprise/blob/0b8820aadfcdfaff4df4bbd26c161951fa95b67d/account_accountant/wizard/account_reconcile_wizard.py#L122 To resolve this, Provide a current company_id as default value if move lines are not available in the account reconciliation wizard. Sentry-6237590490
This fixes an issue where Accounting reports could crash if a report expression used an invalid subformula with the Aggregate Other Formulas engine. Instead of showing an error, the report now handles the invalid setup safely, improving reliability for users opening financial reports.
Original PR description
Currently, a traceback is occurring when the user tries to open a The report contains a subformula in the report expression that does not match. To reproduce this issue: 1) Install `Accounting` 2)…
Currently, a traceback is occurring when the user tries to open a The report contains a subformula in the report expression that does not match. To reproduce this issue: 1) Install `Accounting` 2) Open the `Profit & Losses` report and open any `line` 3) Add the subformula as `sum` for any `report expression` 4) Make sure the `Computation Engine` for expression as `Aggregate Other Formulas` 5) Now open the above report from the `Accounting Reporting` Error:- ``` AttributeError: 'NoneType' object has no attribute 'groupdict' ``` This error occurs when the user gives a subformula to the engine type `Aggregate Other Formulas`. Because it tries to match and group the subformula as `currency_1`, `amount_1`, `criterium`. To do this we need a valid subformula. https://github.com/odoo/enterprise/blob/0611a56074616bd935b0a9e5e7db98b23d8184f0/account_reports/models/account_report.py#L3007-L3013 When the user gives an invalid subformula, the regex results as None. which leads to the above traceback. We can resolve this issue by returning unbound_value if the regex is None. sentry-6325843987
The Product Routes Report now handles manufacturing routes that do not have a source location set. This prevents users from seeing an error when opening the route diagram for products configured for manufacturing.
Original PR description
This error occurs when users view the Product Routes Report. Steps to Reproduce: - Install the `mrp` modules. - Open `Products`. - In the Inventory tab, enable `Manufacture` in Routes. - Clear the `Production Location` field. - Click View `Diagram` in Routes. ValueError: False is not in list This error occurs because, in `Warehouse > Routes`, when a rule is created with the Manufacture action, the Source Location field is not required. However, when generating the Product Routes Report, the system attempts to access this field even if it is empty, resulting in an error. This commit ensures the Product Routes Report view correctly Sentry-6487434464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Studio now shows a clear user-facing error when someone duplicates a report that points to a template that does not exist. This prevents an unclear system crash and helps users understand what needs to be corrected in the report setup.
Original PR description
This error occurs when a user duplicates the report using Studio. Steps to Reproduce: - Install the `web_studio` and `hr` modules. - Go to `Reporting > Reports`. - Click New, set the Model Name to hr.employee, and enter a non-existent template name like hr.demo in the Template Name field. - Go back and click the Studio icon. - Navigate to Employees > Reports, duplicate the newly created report. `ValueError: Expected singleton: ir.ui.view()` This error occurs because the user attempts to duplicate a report in Studio that references a non-existent template. This commit ensures that if a user duplicates a report with a non-existent template name, a UserError is raised. Sentry-6528691775
This fix ensures timesheet reports correctly include related helpdesk ticket information when applicable. It resolves a prior report update that did not properly target the existing report section, helping users see the expected ticket context in exported or printed timesheet reports.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if.
The system now handles incorrectly written filter rules on relational fields more gracefully. Instead of showing a technical crash, users receive a clear validation message so they can correct the field setup.
Original PR description
Currently an error occurs when a syntactically invalid domain is added to any relational field. Steps to replicate: - Go to `Settings > technical > Fields` and click on New. - Make the field type as…
Currently an error occurs when a syntactically invalid domain is added to any relational field.
Steps to replicate:
- Go to `Settings > technical > Fields` and click on New.
- Make the field type as `Many2one` (any relational type would work).
- Add the domain as `[('x_isLaundy), '=', True)]`, which has a syntax error.
- Add other required fields and save.
Error:
`SyntaxError: unterminated string literal (detected at line 1) (, line 1)`
This error was caused by a `SyntaxError` raised during `safe_eval()` [1] evaluation of a malformed domain. Since the exception wasn't handled properly, it resulted in a traceback.
This commit resolves the issue by catching the `SyntaxError` raised during domain evaluation and converting it into a user-friendly `ValidationError`, preventing unhandled tracebacks.
[1] - https://github.com/odoo/odoo/blob/a3e9b4de2714bd0cc7831e924a0cce490f5da39e/odoo/addons/base/models/ir_model.py#L633-L636
sentry-6676988276
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCreating a new website page with a title that looks like a filename, such as demo.xml, no longer triggers an error. This improves reliability for website editors and prevents a failed page creation flow when using common title formats.
Original PR description
Currently, an error occurs when creating a new page on the website. Steps to Reproduce: - Install the `website` module. - Go to `Pages` on website. - Click `New` and choose any template except Blank.…
Currently, an error occurs when creating a new page on the website. Steps to Reproduce: - Install the `website` module. - Go to `Pages` on website. - Click `New` and choose any template except Blank. - Enter demo.xml as the page title and click Create. `IndexError: list index out of range` This error occurs when creating a new page and the title includes a file extension. The _guess_mimetype function [1] uses the extension to determine and return the related template name. In [2], if the template does not contain a 'div' with id="wrap", the XPath query returns an empty list. When it tries to access the first element of this empty list, it raises an error. [1] https://github.com/odoo/odoo/blob/8ddc065c5d75750d8fe0736c2232888a543424fd/addons/website/controllers/main.py#L640 [2] https://github.com/odoo/odoo/blob/8ddc065c5d75750d8fe0736c2232888a543424fd/addons/website/models/website.py#L881 This commit ensures that it accesses the first XPath only if there is an element present in the list. sentry-6696313055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Uploading an OFX bank statement with malformed date values now shows a clear validation error instead of causing an unexpected import failure. This helps accounting users understand that the file content is invalid and prevents a confusing system error during bank statement import.
Original PR description
This error occurs when an uploaded OFX statement file contains malformed date values. For example, the date string `89310133` is interpreted as `8931-01-33` in the `YYYYMMDD` format — but since day 33 is invalid, it causes an error. **Steps to replicate:** * Install `accountant` module with demo data * Accounting Dashboard> Bank>Dropdown>Import [File](https://drive.google.com/file/d/1qWd2mrf1Vh5ZgvDmng-dioNe1xwdfi7y/view?usp=sharing) `OfxParserException:unconverted data remains: 3` **Solution:** * Raise a `ValidationError` when an invalid date is encountered in the file. **Sentry-6715864025**
This fixes an issue that could cause a server error while handling responses from the Nilvera e-invoicing service in Turkey. Users should now receive the intended error message instead of an unexpected technical failure.
Original PR description
The http response object doesn't have a `code` attribute, this commit fixes this typo which has already been fixed in 19.0 as a part of #222869 task-5050516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Membership invoices now open with the right sales invoice context, so membership products remain searchable on invoice lines even if they are not marked as purchasable. This prevents confusion when editing draft membership invoices and helps users complete invoicing without changing product settings.
Original PR description
**Steps to Reproduce:** 1. Create a new membership product from the Membership module. 2. Open any partner and go to the Membership page. 3. Click on Buy Membership and select the created product. 4.…
**Steps to Reproduce:**
1. Create a new membership product from the Membership module.
2. Open any partner and go to the Membership page.
3. Click on Buy Membership and select the created product.
4. Click on Invoice Membership.
5. Open the newly created draft invoice.
6. From the invoice line, open the product form (via the internal link).
7. Disable the Can be Purchased option and return to the invoice using breadcrumbs.
8. Add a new line in the invoice and search for the same product by its name.
**Observation:**
1. When Can be Purchased is enabled on the product, the product appears in the invoice line search.
2. When Can be Purchased is disabled, the product no longer appears in the search.
**Issue:**
In the product field domain defined in
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029 the `default_move_type` context is `null`.
As a result, only the condition `[('purchase_ok', '=', True)]` is applied in the `name_search` domain.
**Solution:**
Pass the proper context value in the invoice action, ensuring the domain evaluates correctly and the product remains searchable.
**Note:**
The domain used in the following field
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029
is evaluated by a following JavaScript function
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/web/static/src/core/py_js/py_interpreter.js#L483-L489
rather than on the Python backend. Because the domain logic depends on dynamic
context evaluation performed client-side, there is no straightforward way to
retrieve or test the domain arguments dynamically within the `name_search`
method on the server. As a result, it is not feasible to write automated test
cases for this specific domain filtering scenario in the backend.
opw-5028789This fix prevents appointment slot refreshes from failing when no specific resource is selected. It helps users continue booking appointments smoothly by safely handling missing or empty resource selections before calculating available capacity.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895
This fix prevents synchronization error messages from causing a crash in the Romanian e-invoicing flow. Businesses using Romanian electronic invoicing get more reliable error reporting when communication issues occur.
Original PR description
Problem
---------
Currently, the 'error' message (in case of communication error) is stored in the 'answer' dict. However, the code verify for the 'error' key in the message dict itself.
Solution
---------
When checking if the 'error' key is present, check in the 'answer' dict rather than the message dict
The code is
```message = {**data, 'answer': {**data, 'error': ""}}```
The verifications were
```'error' in message ?```
and now they are
```'error' in message['answer'] ?```
opw-5046567
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSales order invoiced amounts now ignore invoice note and section lines, matching standard accounting behavior. This prevents non-billable display lines from affecting invoiced amount calculations and related filters.
Original PR description
When computing the invoiced amount for a SO, ignore the invoice's lines of `display_type` equal to `line_note` and `line_section` This matches the accounting features which always ignore such lines. **Current behavior before PR** Method `_get_sale_order_invoiced_amount` includes display lines. **Desired behavior after PR is merged** Method `_get_sale_order_invoiced_amount` ignores display lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr