Daily updates from Odoo
Thursday, October 23, 2025
152 changes
24 changes
Resolved issues and error corrections
This fix ensures Argentina vendor bills for foreign partners default to the expected “Invoices and Receipts from Abroad” document type. It also aligns foreign customer and supplier invoice suggestions with the selected journal, reducing manual corrections and compliance risk.
Original PR description
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del…
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively. In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners. With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers. Current behavior before PR: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers Desired behavior after PR is merged: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228635
Work entry generation now handles employees with different working schedule types, including fully flexible employees without a calendar. This prevents errors and helps ensure payroll-related work entries are generated accurately across varied contract setups.
Original PR description
- fixed work entries generation for employees with different working schedules types - fixed a traceback when the method `_attendance_intervals_batch` is called without a calendar (because the employee is fully flexible) or with more than 1 calendar - made work entries generation check for employee timezone in case the employee is fully flexible and doesn't have a calendar - added method `_get_calendar_at` to get the calendar of the resource at a given date - added `test_work_entry_different_calendars` for work entries generation for employees with contracts with different calendar types task-id: 5065160
Performance tests were updated to reflect an additional calendar lookup used when calculating attendance intervals. This helps ensure automated checks stay accurate for employees or appointments using different calendar setups.
Original PR description
- adjusted some query counters to account for the extra search in `_attendance_intervals_batch` done by the method `_get_calendar_at` task-id: 5065160
This fixes an issue that prevented managers from creating appraisals when they should have permission to do so. It helps keep performance review workflows running smoothly and adds test coverage to prevent the issue from returning.
Original PR description
fixed with https://github.com/odoo/enterprise/commit/d4b708d22c0c3768cbb50bd5a43e91db419ff277 added test to cover the use case opw-4794641 Forward-Port-Of: odoo/enterprise#87831
A scheduled HR update was incorrectly replacing employees' work phone numbers with the company phone number. This fix preserves the correct employee contact details and reduces unnecessary background recalculations.
Original PR description
When executing the ir_cron_data_employee_update_current_version job, employee's work_phone fields would always be overridden by the company phone. We found out that setting the employee phone as the company phone as a default was pretty much never useful. By searching for other computed properties that could be triggered by the cron job, I found out that two computed properties were the exact same as their equivalent in hr_version. I thus removed them. The computed property triggered by the cron would assign current_version_id, even if it was the same. Even in this case will all the computed properties be triggered (even if current_version_id stays the same), so I added a check before to avoid unnecessary recomputations. task-5103739
Fixed an issue where using Set Account on bank statement lines with similar references could create an invalid matching rule and block reconciliation. Users can now continue reconciling affected bank statements without encountering the regex validation error.
Original PR description
Currently, when a user uses the 'Set Account' button to reconcile a statement line, the system may also create a reconciliation model for fees for the given journal/account combination, based on the…
Currently, when a user uses the 'Set Account' button to reconcile a statement line, the system may also create a reconciliation model for fees for the given journal/account combination, based on the previous statement line reference pattern. To extract a patter from the references, the system computes the normalised longest common substring. This will be used as regex matching pattern of the newly created reconciliation rule. However, the common substring may end up with '\\', which is not a valid termination of a regex, leading to the error: `Invalid operation. The regex is invalid.` Steps to reproduce: - Have an account '646000 Test Account' - Create a Bank statement with label 'TEST REFERENCE BNK 2024' - Set Account 646000 - Create a Bank statement with label 'TEST REFERENCE BNK.OTHER' - Set Account 646000 Issue: Error `Invalid operation. The regex is invalid.` will raise blocking the action [opw-5086638](https://www.odoo.com/odoo/project.task/5086638) [opw-5062965](https://www.odoo.com/odoo/project.task/5062965) [opw-5123963](https://www.odoo.com/odoo/project.task/5123963) [opw-5166160](https://www.odoo.com/odoo/project.task//5166160) [opw-5159871](https://www.odoo.com/odoo/project.task/5159871) [opw-5160108](https://www.odoo.com/odoo/project.task/5160108) [opw-5109454](https://www.odoo.com/odoo/project.task/5109454) [opw-5086638](https://www.odoo.com/odoo/project.task/5086638) ... Forward-Port-Of: odoo/enterprise#97865
Fixed a display issue in the Timesheets monthly view where text could overlap into timer button areas when users increased text size and scrolled horizontally. This improves readability and keeps totals and footer rows visually clean.
Original PR description
Steps to reproduce: - Open timesheets and change to Month scale. - Increase text size a little bit. - Scroll to the right side Issue: - You can see runover text being visible in timer button cell of Total row and Footer row. Reason: - It is due to z-index problem as z-index-* is deprecated from https://github.com/odoo/odoo/pull/165568 (from saas-17.4+). Fix: - Replace it with Bootstrap z-index class notated as z-*(-1 to 3) task-4949182 Forward-Port-Of: odoo/enterprise#96371
Long mailing list names now remain contained within the list view instead of overlapping nearby information. This keeps the Marketing mailing lists screen readable and easier to use when records have lengthy names.
Original PR description
Issue: When you create a long name for your maling list, the name overflows over the other fields in the view. Repro: Go to marketing -> mailing lists -> create a fairly long name -> notice name overflows in the view. Cause: Small bootstrap issue, name field not limited to it's container. Fix: Added a simple w-100 to limit the field to 100% of it's container. opw-5153270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232312
This fixes a payroll work entry error that could occur when an employee with fully flexible hours had overlapping absences, such as sick leave and a public holiday. Payroll teams can now generate work entries without the process being blocked by this overlap scenario.
Original PR description
FIX] hr_work_entry_holidays: singleton error in overlaping leaves **Issue:** ValueError "Expected singleton: hr.work.entry.type(7, 8)" occurs during work entry generation when overlapping leaves…
FIX] hr_work_entry_holidays: singleton error in overlaping leaves **Issue:** ValueError "Expected singleton: hr.work.entry.type(7, 8)" occurs during work entry generation when overlapping leaves (sick leave + public holiday) create intervals containing multiple work entry types. **Steps to Reproduce:** 1. Go to the **Employees** app and create a new employee. * Set the working hours to **empty (fully flexible)**. 2. Create contract fields on the employee: * Set **Work Entry Source** to *Attendance*. * Set date_version and contract_date_start. 3. Go to **Time Off** → **New**, and create a sick time off for the employee. * Example: from **25th to 29th**. * Approve the time off. 4. Go to **Configuration** → **Public Holidays**, and create a new public holiday. * Example: **27th**, which overlaps with the sick time off. * Work Entry Type = **Paid Time Off**. 5. Go to **Payroll** → **Work Entries**. * A **traceback** occurs. **Root Cause:** In `_get_interval_leave_work_entry_type()`: Direct access to `interval[2].work_entry_type_id.code` causes singleton violation when overlapping leaves create intervals containing multiple work entry types. **Fix:** Replace direct access to `interval[2].work_entry_type_id.code` with safe recordset slicing `interval[2].work_entry_type_id[:1].code` to prevent singleton violation. **Note (18.4+):** Steps updated for versioned contract architecture where contract fields are set directly on employee. This resolves payroll blocking issues for deployments with overlapping leave scenarios. Test : [PR](https://github.com/odoo/enterprise/pull/93902) opw-4979974 Forward-Port-Of: odoo/odoo#223448
Adds test coverage to ensure flexible employees using attendance-based work entries can have overlapping sick leave and public holidays without causing payroll work entry errors. This helps protect payroll processing reliability for complex absence scenarios.
Original PR description
**Purpose:** Add regression test to verify that overlapping leave scenarios (sick leave + public holiday) do not cause singleton errors for fully flexible employees using attendance-based work entries. **Test Coverage:** - Fully flexible employee with no calendar assignment - Attendance-based work entry source configuration - Overlapping sick leave and public holiday scenario - Work entry generation and validation without singleton errors **saas-18.4+ Adaptation:** Adapted for versioned contract architecture - contract fields now set directly on employee. Related : [PR](https://github.com/odoo/odoo/pull/223448) opw-4979974 Forward-Port-Of: odoo/enterprise#93902
This fixes a formatting issue in printed folder-style reports where page numbers could wrap onto two lines when using the Montserrat font. Keeping the page number on one line makes report footers cleaner and more professional.
Original PR description
The folder layout is using the same footer than the `external_layout_standard` but when using Montserrat, the page number wraps in 2 lines on the folder layout. It's missing a `text-nowrap` class. task-4942402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228391
This fix prevents active customer live chat conversations from being accidentally canceled when a customer starts another chat. It ensures only still-pending chat requests are canceled, improving reliability for customers using chat across multiple pages or devices.
Original PR description
The website livechat module allows agents to start conversations with customers, but conversations are only displayed on the next navigation. Previously, pending chat requests were canceled whenever a customer opened a new live chat. The search condition for pending chats was too broad: it did not consider who started the conversation or whether it was already ongoing. As a result, ongoing chats could be unintentionally canceled. Customers could have multiple conversations (e.g. on different devices). This change ensures that only pending chat requests are canceled, leaving ongoing chats intact. task-5186567 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#232624
When an applicant is refused and a refusal email is sent, the email is now also recorded in the application's chatter. This gives recruiters a clearer communication history and helps teams confirm what was sent to candidates.
Original PR description
To reproduce: ============= refuse an application with `send_email` checked, the email is sent but not logged in the chatter Solution: ========= Add a `message_post` in the `_prepare_send_refusal_mails` method opw-5137342 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vendor credit note DTE files in Chilean localization now import as credit notes instead of being incorrectly treated as invoices. This prevents import errors and helps accounting teams process supplier credit notes through drag-and-drop as expected.
Original PR description
### Steps to reproduce Go to Accounting -> Vendor Bills Attempt to import a valid vendor credit note by dragging-dropping the DTE file in the list view. Notice how the vendor credit note gets created with an error: ``` Error importing attachment 'DTE.xml' (type=l10n_cl.dte): This specific error occurred during the import: You can not use a credit_note document type with a invoice ``` ### Analysis `_l10n_cl_import_dte` should set the move type to credit note when the document type code is '61', but does not. This was broken by 42744fcecdbd36e See https://github.com/odoo/enterprise/commit/42744fcecdbd36ea0101070c68299227a9f204a6#diff-044bc1ef3ea4878783a064258b4436b44b3064c5196c22d0d104daee8fde4501L294 ### Solution Correctly set move_type to `in_refund` if the document type code is '61' Linked issue https://github.com/odoo/odoo/issues/232348 task-none
Accounting users can now create SEPA Direct Debit mandates without encountering an access error. This ensures authorized invoicing and banking staff can complete direct debit setup without needing administrator rights.
Original PR description
Have the Payment Provider Sepa Direct Debit module installed. Connect with a user with access right for Accounting: Invoicing & Banks. Create a Direct Debit Mandate => Get an access error. Reason: the compute does a read_group with a value on payment.provider, which non System Admin have no access to. Solution: Add a sudo for these _read_group Forward-Port-Of: odoo/enterprise#97127
Public website customers could get stuck after paying for an online order when accounting journal restrictions were enabled. The fix ensures payment confirmation can complete correctly without triggering an internal access error, improving checkout reliability.
Original PR description
Error in backend while public user payment confirmation Steps: - Install `website_sale` - Activate `restrict_mode_hash_table` on sale journal - From an incognito window, Make an order in ecommerce and pay it -> we get stucked on 'Your payment has been successfully processed' page because of an acces error in the backend This is because when posting a new move, we either to access or modify moves we get from `chain['moves']`, however these moves are returned with `sudo(False)` by `AccountMove._get_chain_info()`. opw-5128189 Forward-Port-Of: odoo/odoo#232143
Event registration pages now translate the date selection labels when visitors use another language. This improves the multilingual registration experience by showing consistent localized wording for event slots.
Original PR description
Scenario: - adds slots to an event - register to that event with another language Result: "Selected Date" or "Select a Date" is not translated or translatable. Fix: wrap those JS strings with _t function. opw-5167911 Forward-Port-Of: odoo/odoo#231729
Manufacturing users can now open the work-in-progress accounting wizard even when a work order is still running. The fix prevents an error caused by unfinished work orders that do not yet have an end time, reducing disruption during production cost tracking.
Original PR description
#### Issue: - Traceback when calculating the cost of a workorder #### Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post…
#### Issue: - Traceback when calculating the cost of a workorder #### Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post WIP Accounting entry" #### Current Behavior: - get a traceback #### Expected behaviour - open the WIP wizard #### Cause of the issue: - to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'. #### Solution: - check if the end date of the WO is defined In module mrp_workorder an override of [button_start](https://github.com/odoo/enterprise/blob/18.0/mrp_workorder/models/mrp_workorder.py#L284-L295) change how work order are launched. Therefore, the test should be launched on an Enterprise run. opw-4961873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221938
This fix prevents an error when posting work-in-progress accounting entries for a manufacturing work order that is still in progress. Users can now open the WIP wizard as expected, reducing disruption during manufacturing and accounting workflows.
Original PR description
Issue: - Traceback when calculating the cost of a workorder Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post WIP Accounting entry" Current Behavior: - get a traceback Expected behaviour - open the WIP wizard Cause of the issue: - to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'. Solution: - check if the end date of the WO is defined Test: - in module mrp_workorder an override of button_start change how work order are launched. Therefore, the test should be launched on an Enterprise run. opw-4961873 Forward-Port-Of: odoo/enterprise#97558 Forward-Port-Of: odoo/enterprise#93812
Large PNG images uploaded to Odoo are now resized without being converted to a lower-quality web palette. This prevents visible image degradation on website content and removes the need for users to manually resize images before upload.
Original PR description
When uploading a png image ir_attachment, the image is not modified if its resolution is under the maximum 1920x1920. However, if the resolution is bigger, it both gets resized and is converted to a WEB palette, which visibly degrades the quality of the image. A workaround for this is to resize the image locally to be max 1920 on either dimensions and then upload it, which effectively bypasses this special treatment. Steps to reproduce: - Go to the website app - Add a Text - Image snippet - Double click the image - Upload a .png image of a resolution strictly greater than 1920 in either width or height Old behavior: the png is visibly degraded New behavior: the png is not visibly degraded opw-3935533 Forward-Port-Of: odoo/odoo#173508
The fix restores the speed slider for animated background shapes in the website editor. Users can now adjust animation speed as expected, improving editing accuracy for page designs.
Original PR description
Steps to reproduce: - Drop a snippet - Add a background shape (e.g. Rainy 05) - Use the slider to change the speed - Nothing happens This commit is adapting `CSS_ANIMATION_RULE_REGEX` as it was too restrictive, the space after the colon is now optional. task-5170549 Forward-Port-Of: odoo/odoo#231747
This fixes a missing hours field when planning service work from a sales order. Users can now enter allocated hours in the planning dialog when the usual start time field is hidden, helping schedules capture the required effort correctly.
Original PR description
Steps to reproduce: - Create a Sales order with planning services. - Click on To Plan stat button. - Click on empty cell Issue: - Plan dialog is opened but has missing allocated_hours field. Reason: - In this commit https://github.com/odoo/enterprise/commit/d21bd4b694ec63ba83bea077714a8fe928d6e014 allocated hours was merged with start_datetime using a widget and thus removed from view. - But in planning list view we hide start_datetime when we schedule shifts from sales order. Fix: - Add back allocated_hours conditionally to be visible when we schedule shifts as in other cases start_datetime is present. task-5117776 Forward-Port-Of: odoo/enterprise#96391
Website form editors can no longer delete the final option from a multiple-checkbox field. This prevents forms from getting stuck in a state where users cannot add options back, improving reliability when configuring website forms.
Original PR description
Since `html_builder`, the last element of a multiple checkboxes form field can be removed, but it leads to a situation where no element can be added anymore to the field. To avoid this, this commit restores the former behavior which did forbid the removal of the last element. Steps to reproduce: - Drop a form snippet - Add a field - Set the field type to "Multiple checkboxes" - Remove all options => It was possible to remove the last option. task-4367641
The website donation form now waits for required currency information before processing a donation click. This prevents rare crashes or failed submissions on slow networks and reduces accidental double-click issues by showing a loading state.
Original PR description
This fixes a very rare race condition in the `test_01_donation` tour... but it is actually surprising it is not more frequent than it is. Steps to reproduce: - Simulate a slow network (e.g. using…
This fixes a very rare race condition in the `test_01_donation` tour... but it is actually surprising it is not more frequent than it is. Steps to reproduce: - Simulate a slow network (e.g. using Chrome DevTools) - Load a page with a donation snippet - Quickly fill in the donation form and click the submit button => You'll sometimes get a crash. Or a more precise one: - Add a 1 minute delay to the `/website/get_current_currency` route - Load a page with a donation snippet - Fill in the donation form and click the submit button once the page is fully loaded. => You'll definitely get a crash. This commit makes that button's handler async-protected, meaning it will now properly wait for what is needed (the currency) before proceeding, but it will also display a loading effect for the duration and prevent double clicking. Once the form is submitted, the loading effect is removed for stability safety. In master it can probably be improved. runbot-220885 Forward-Port-Of: odoo/odoo#232585 Forward-Port-Of: odoo/odoo#232408
14 changes
Resolved issues and error corrections
This fix ensures Argentine foreign vendor bills consistently default to the proper document type for invoices and receipts from abroad. It also aligns foreign supplier handling on customer invoices with foreign customer behavior, reducing document selection errors in invoicing workflows.
Original PR description
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del…
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively. In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners. With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers. Current behavior before PR: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers Desired behavior after PR is merged: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228635
Fixed a visual issue in the Timesheets month view where text could overlap into timer button cells when users increased text size and scrolled horizontally. This keeps total and footer rows easier to read and prevents confusing layout artifacts.
Original PR description
Steps to reproduce: - Open timesheets and change to Month scale. - Increase text size a little bit. - Scroll to the right side Issue: - You can see runover text being visible in timer button cell of Total row and Footer row. Reason: - It is due to z-index problem as z-index-* is deprecated from https://github.com/odoo/odoo/pull/165568 (from saas-17.4+). Fix: - Replace it with Bootstrap z-index class notated as z-*(-1 to 3) task-4949182 Forward-Port-Of: odoo/enterprise#96371
This fix restores the speed control for animated background shapes in the website editor. Users can now adjust animation speed as expected when customizing snippets, improving editing reliability for visual page design.
Original PR description
Steps to reproduce: - Drop a snippet - Add a background shape (e.g. Rainy 05) - Use the slider to change the speed - Nothing happens This commit is adapting `CSS_ANIMATION_RULE_REGEX` as it was too restrictive, the space after the colon is now optional. task-5170549 Forward-Port-Of: odoo/odoo#231747
This fix keeps page numbers on a single line in folder-style report footers, especially when the Montserrat font is used. It improves the visual consistency and professionalism of generated documents without changing report content or behavior.
Original PR description
The folder layout is using the same footer than the `external_layout_standard` but when using Montserrat, the page number wraps in 2 lines on the folder layout. It's missing a `text-nowrap` class. task-4942402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228391
Self-ordering now separates orders between devices when customers pay after each order, preventing people at the same table from seeing or changing each other's orders. When paying after the meal, devices at the same table can still collaborate on one shared order as intended.
Original PR description
Before this commit orders were always shared between multiple devices using the same QR code. This could lead to issues when multiple customers were using self-ordering at the same table, as they could see and modify each other's orders. When multiple devices are used for self-ordering with the same QR code, there is now two mode possible: - Pay after each: orders are not shared, and the table isn't linked to the order when synchronizing. Instead the table number is in the floating order name. - Pay after meal: orders are shared, and the table is linked to the order when synchronizing. That's means that multiple devices can add products to the same order. taskId: 5187089
Manufacturing users can now open the WIP accounting wizard even when a work order is still running. The fix avoids an error caused by unfinished work orders not yet having an end time, making production cost posting more reliable.
Original PR description
#### Issue: - Traceback when calculating the cost of a workorder #### Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post…
#### Issue: - Traceback when calculating the cost of a workorder #### Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post WIP Accounting entry" #### Current Behavior: - get a traceback #### Expected behaviour - open the WIP wizard #### Cause of the issue: - to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'. #### Solution: - check if the end date of the WO is defined In module mrp_workorder an override of [button_start](https://github.com/odoo/enterprise/blob/18.0/mrp_workorder/models/mrp_workorder.py#L284-L295) change how work order are launched. Therefore, the test should be launched on an Enterprise run. opw-4961873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221938
This fix prevents an error when users post work-in-progress accounting entries for a manufacturing work order that is still running. The wizard now opens as expected, helping manufacturing and accounting teams continue cost tracking without interruption.
Original PR description
Issue: - Traceback when calculating the cost of a workorder Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post WIP Accounting entry" Current Behavior: - get a traceback Expected behaviour - open the WIP wizard Cause of the issue: - to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'. Solution: - check if the end date of the WO is defined Test: - in module mrp_workorder an override of button_start change how work order are launched. Therefore, the test should be launched on an Enterprise run. opw-4961873 Forward-Port-Of: odoo/enterprise#97558 Forward-Port-Of: odoo/enterprise#93812
Fixes an issue where online shoppers could get stuck after a successful payment when extra accounting controls were enabled. The change ensures the payment confirmation process can complete reliably for public website users while preserving accounting restrictions.
Original PR description
Error in backend while public user payment confirmation Steps: - Install `website_sale` - Activate `restrict_mode_hash_table` on sale journal - From an incognito window, Make an order in ecommerce and pay it -> we get stucked on 'Your payment has been successfully processed' page because of an acces error in the backend This is because when posting a new move, we either to access or modify moves we get from `chain['moves']`, however these moves are returned with `sudo(False)` by `AccountMove._get_chain_info()`. opw-5128189 Forward-Port-Of: odoo/odoo#232143
This fix ensures Odoo's web test mock server respects custom responses exactly as they are defined, instead of changing them into a standard JSON-RPC format. It improves the reliability of automated tests and helps developers validate web behavior more accurately without affecting end users.
Original PR description
Before this commit, when an 'onRpc' handler would return a 'Response' object, it would still be wrapped in a JSON-RPC payload (under the 'result' key) if the "content-type" header specified that it was a JSON-RPC. However, if a 'Response' object is returned by the handler, it usually means that the response should be that object as-is, as it was created with the desired final parameters. This commit ensures that 'Response' values are returned as they are, instead of being wrapped in a JSON-RPC payload object. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232614
This fixes a display issue where portal pages in right-to-left website languages could show excessive blank horizontal space. Dynamic website styling now uses the active website language, so pages render correctly for users browsing in languages such as Arabic.
Original PR description
Scenario to reproduce from 18.0: - install right-to-left (eg. arabic) language on website - open a portal record with chatter (eg. /my/invoices/1) - switch to right-to-left language - scroll…
Scenario to reproduce from 18.0: - install right-to-left (eg. arabic) language on website - open a portal record with chatter (eg. /my/invoices/1) - switch to right-to-left language - scroll horizontally to the left Result: there is a huge amount of whitespace scrollable to the left. Cause: In 18.0, the chatter has an hidden textarea .o-mail-Composer-fake with position "left: -10000px; top: -10000px;". But the chatter assets (portal.assets_chatter_style) are called dynamically with getBundle which is using the session lang instead of the website lang. So the bundle is gotten with the wrong lang and the CSS is not rtlcss'ed and this create big whitespace to the left of the page. Fix: set the website request language when getting bundle for the frontend. Note: this PR also create a TestLangUrlCommon to prevent TestLangUrl tests of being run a second time in TestControllerRedirect. opw-5013485 Forward-Port-Of: odoo/odoo#232671 Forward-Port-Of: odoo/odoo#223575
Large PNG images uploaded to Odoo are now resized without being converted to a limited web color palette. This prevents visible image quality loss on websites and other areas using uploaded attachments, so users no longer need to resize images manually before uploading.
Original PR description
When uploading a png image ir_attachment, the image is not modified if its resolution is under the maximum 1920x1920. However, if the resolution is bigger, it both gets resized and is converted to a WEB palette, which visibly degrades the quality of the image. A workaround for this is to resize the image locally to be max 1920 on either dimensions and then upload it, which effectively bypasses this special treatment. Steps to reproduce: - Go to the website app - Add a Text - Image snippet - Double click the image - Upload a .png image of a resolution strictly greater than 1920 in either width or height Old behavior: the png is visibly degraded New behavior: the png is not visibly degraded opw-3935533 Forward-Port-Of: odoo/odoo#173508
This fixes a missing field when planning service work from a sales order. Users can once again see and set allocated hours in the planning dialog when the usual scheduling time field is hidden, helping avoid incomplete shift planning.
Original PR description
Steps to reproduce: - Create a Sales order with planning services. - Click on To Plan stat button. - Click on empty cell Issue: - Plan dialog is opened but has missing allocated_hours field. Reason: - In this commit https://github.com/odoo/enterprise/commit/d21bd4b694ec63ba83bea077714a8fe928d6e014 allocated hours was merged with start_datetime using a widget and thus removed from view. - But in planning list view we hide start_datetime when we schedule shifts from sales order. Fix: - Add back allocated_hours conditionally to be visible when we schedule shifts as in other cases start_datetime is present. task-5117776 Forward-Port-Of: odoo/enterprise#96391
Donation forms now wait until the page has loaded the current currency before processing a click. This prevents rare crashes or failed submissions on slow connections and shows a loading state to avoid duplicate clicks.
Original PR description
This fixes a very rare race condition in the `test_01_donation` tour... but it is actually surprising it is not more frequent than it is. Steps to reproduce: - Simulate a slow network (e.g. using…
This fixes a very rare race condition in the `test_01_donation` tour... but it is actually surprising it is not more frequent than it is. Steps to reproduce: - Simulate a slow network (e.g. using Chrome DevTools) - Load a page with a donation snippet - Quickly fill in the donation form and click the submit button => You'll sometimes get a crash. Or a more precise one: - Add a 1 minute delay to the `/website/get_current_currency` route - Load a page with a donation snippet - Fill in the donation form and click the submit button once the page is fully loaded. => You'll definitely get a crash. This commit makes that button's handler async-protected, meaning it will now properly wait for what is needed (the currency) before proceeding, but it will also display a loading effect for the duration and prevent double clicking. Once the form is submitted, the loading effect is removed for stability safety. In master it can probably be improved. runbot-220885 Forward-Port-Of: odoo/odoo#232585 Forward-Port-Of: odoo/odoo#232408
The Helpdesk SLA report now lets users add the SLA status grouping back after removing it. This avoids needing to reload the reporting view and makes SLA analysis smoother for support teams.
Original PR description
Currently, when the user opens the sla reporting view, if he removes the default grouping of sla_status, he has no way to get it back unless he reloads the view completly. This commit fixes this issue by adding the sla_status field to the group_by options. task-5076401 Forward-Port-Of: odoo/enterprise#95261
3 changes
Resolved issues and error corrections
Payslips now correctly show worked days for employees on fully flexible contracts, even when no fixed working calendar is set. This prevents payroll teams from seeing empty worked-day sections despite valid attendance or planning entries, reducing manual checks and payroll errors.
Original PR description
**Issue:** Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries **Cause:** `_get_worked_day_lines()` skips worked day computation if the contract has no calendar https://github.com/odoo/enterprise/blob/1a10e0444fdb71a072262a1f14f0bfc766d109c6/hr_payroll/models/hr_payslip.py#L665-L674 **Steps to Reproduce:** - Assign an employee a fully flexible contract with attendance as work entry source. - Create work entries based on the attendance records of the employee record - Go to employees > contracts > new Payslip Worked Days section is empty, even though attendance shifts are showing up on top. **Fix:** removing the calendar requirement in the main method and adding a fallback calendar in the called utility method **Note:** same issue happens if work entry source of the contract is Planning opw-4931972 Forward-Port-Of: odoo/enterprise#93935
The Timesheets monthly grid now keeps overflowing text from appearing over the timer button area in total and footer rows. This improves readability when users increase text size and scroll across the grid.
Original PR description
Steps to reproduce: - Open timesheets and change to Month scale. - Increase text size a little bit. - Scroll to the right side Issue: - You can see runover text being visible in timer button cell of Total row and Footer row. Reason: - It is due to z-index problem as z-index-* is deprecated from https://github.com/odoo/odoo/pull/165568 (from saas-17.4+). Fix: - Replace it with Bootstrap z-index class notated as z-*(-1 to 3) task-4949182 Forward-Port-Of: odoo/enterprise#96371
Corrects the Chinese ASBE balance sheet so liabilities and related account lines are included in the right place. This helps businesses rely on accurate balanced financial reports and prevents false test failures around balance sheet validation.
Original PR description
Fixes the balance_sheet_balanced test for asbe where the wrong line was set as liability. Also fixes the report itself that was ignoring one line, and missing one account. task-5175789 Forward-Port-Of: odoo/enterprise#97460
12 changes
Resolved issues and error corrections
The ESG dashboard now uses colors that adapt correctly to dark and light mode, making its graphs easier to read. On mobile, initiative cards also give more room to key action buttons by hiding the total button.
Original PR description
Before this commit, the color chosen for the graphs in the ESG dashboard does not take into account the dark/light mode and so they does not have the right color when the user is in dark mode. This commit makes sure the graphs are well rendered in dark mode. task-5138512 Forward-Port-Of: odoo/enterprise#97646
The salary calculation now prevents gross salary from being shown as a negative amount. This avoids confusing or invalid payroll figures and ensures salary results stay at a sensible minimum of zero.
Original PR description
This commit fixes an issue where the gross salary was computed as negative. It makes no sense to have a negative gross salary. This commit min the computation to 0. task-5175923
This update fixes a display issue in Timesheets where text could overlap into timer button areas when using the monthly view with larger text size. It improves readability and prevents visual clutter in total and footer rows.
Original PR description
Steps to reproduce: - Open timesheets and change to Month scale. - Increase text size a little bit. - Scroll to the right side Issue: - You can see runover text being visible in timer button cell of Total row and Footer row. Reason: - It is due to z-index problem as z-index-* is deprecated from https://github.com/odoo/odoo/pull/165568 (from saas-17.4+). Fix: - Replace it with Bootstrap z-index class notated as z-*(-1 to 3) task-4949182 Forward-Port-Of: odoo/enterprise#96371
Fixed an issue where using Set Account during bank statement reconciliation could create an invalid matching rule and block the action. Users can now reconcile statement lines with similar references more reliably without seeing a regex validation error.
Original PR description
Currently, when a user uses the 'Set Account' button to reconcile a statement line, the system may also create a reconciliation model for fees for the given journal/account combination, based on the…
Currently, when a user uses the 'Set Account' button to reconcile a statement line, the system may also create a reconciliation model for fees for the given journal/account combination, based on the previous statement line reference pattern. To extract a patter from the references, the system computes the normalised longest common substring. This will be used as regex matching pattern of the newly created reconciliation rule. However, the common substring may end up with '\\', which is not a valid termination of a regex, leading to the error: `Invalid operation. The regex is invalid.` Steps to reproduce: - Have an account '646000 Test Account' - Create a Bank statement with label 'TEST REFERENCE BNK 2024' - Set Account 646000 - Create a Bank statement with label 'TEST REFERENCE BNK.OTHER' - Set Account 646000 Issue: Error `Invalid operation. The regex is invalid.` will raise blocking the action [opw-5086638](https://www.odoo.com/odoo/project.task/5086638) [opw-5062965](https://www.odoo.com/odoo/project.task/5062965) [opw-5123963](https://www.odoo.com/odoo/project.task/5123963) [opw-5166160](https://www.odoo.com/odoo/project.task//5166160) [opw-5159871](https://www.odoo.com/odoo/project.task/5159871) [opw-5160108](https://www.odoo.com/odoo/project.task/5160108) [opw-5109454](https://www.odoo.com/odoo/project.task/5109454) [opw-5086638](https://www.odoo.com/odoo/project.task/5086638) ... Forward-Port-Of: odoo/enterprise#97865
Sales users can once again enter allocated hours when planning shifts from a sales order. This fixes a missing field in the planning dialog, helping teams schedule service work with the correct expected duration.
Original PR description
Steps to reproduce: - Create a Sales order with planning services. - Click on To Plan stat button. - Click on empty cell Issue: - Plan dialog is opened but has missing allocated_hours field. Reason: - In this commit https://github.com/odoo/enterprise/commit/d21bd4b694ec63ba83bea077714a8fe928d6e014 allocated hours was merged with start_datetime using a widget and thus removed from view. - But in planning list view we hide start_datetime when we schedule shifts from sales order. Fix: - Add back allocated_hours conditionally to be visible when we schedule shifts as in other cases start_datetime is present. task-5117776 Forward-Port-Of: odoo/enterprise#96391
This update fixes how PFA amounts are calculated in Belgian payroll, helping ensure payroll results are accurate. It also reorganizes the related logic and adds test coverage for 13th-month payroll scenarios to reduce the risk of future calculation errors.
Original PR description
task-5103485
Corrects the display of spreadsheet filter tooltips when dark mode is active. This prevents the tooltip from appearing only partially styled and keeps the spreadsheet experience visually consistent until full dark mode support is available.
Original PR description
The fitler tooltip was displayed halfay in dark mode, while the rest of spreadsheet does not support dark mode yet. Task: [5162869](https://www.odoo.com/web#id=5162869&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#97478
This fixes an issue where employees could not edit the personal information section in the salary configurator when the website editor component was not installed. The update restores access to the affected fields, helping HR salary configuration flows work reliably across setups.
Original PR description
Before this commit, when website was not installed (or more precisely html_builder), the salary configurator was not editable anymore due to ::before section that took the whole page. This was due to the changes made in https://github.com/odoo/odoo/pull/229554/. The style rule regarding relative positioned sections was move from html_editor to html_builder as this was a more website specific (or html_builder specific) rule. The fix should then be done in modules that used that rules but that does not depends on html_builder. The commit applies relative position to the personal info section ans force the ::before to let the pointer go through it to access underlying inputs. Task-5154145 Forward-Port-Of: odoo/enterprise#96644
Helpdesk SLA reports now let users add the SLA status grouping back after removing it. This avoids needing to reload the report view and makes reporting easier to adjust during analysis.
Original PR description
Currently, when the user opens the sla reporting view, if he removes the default grouping of sla_status, he has no way to get it back unless he reloads the view completly. This commit fixes this issue by adding the sla_status field to the group_by options. task-5076401 Forward-Port-Of: odoo/enterprise#95261
The last appraisal button is available again for employee profiles. This restores a shortcut that was accidentally removed, helping managers and HR users quickly access the most recent appraisal.
Original PR description
The action on res.users to see the last appraisal has been removed by this PR https://github.com/odoo/enterprise/pull/88518. This commit reintroduces the action in hr.employee.public. task-5166704 Forward-Port-Of: odoo/enterprise#97113
Chilean electronic vendor credit notes can now be imported correctly from DTE files. This prevents valid credit notes from being rejected as invoices, helping accounting teams process supplier adjustments without manual workarounds.
Original PR description
### Steps to reproduce Go to Accounting -> Vendor Bills Attempt to import a valid vendor credit note by dragging-dropping the DTE file in the list view. Notice how the vendor credit note gets created with an error: ``` Error importing attachment 'DTE.xml' (type=l10n_cl.dte): This specific error occurred during the import: You can not use a credit_note document type with a invoice ``` ### Analysis `_l10n_cl_import_dte` should set the move type to credit note when the document type code is '61', but does not. This was broken by 42744fcecdbd36e See https://github.com/odoo/enterprise/commit/42744fcecdbd36ea0101070c68299227a9f204a6#diff-044bc1ef3ea4878783a064258b4436b44b3064c5196c22d0d104daee8fde4501L294 ### Solution Correctly set move_type to `in_refund` if the document type code is '61' Linked issue https://github.com/odoo/odoo/issues/232348 task-none Forward-Port-Of: odoo/enterprise#97694
This fixes how VoIP contact searches combine phone keypad search terms with other contact filters. Users should see more accurate contact results instead of searches that are too restrictive and often return no matches.
Original PR description
t9_search should be ORed to the subdomain, which in turn should be ANDed to the domain. Currently, both the subdomain and the t9_search are ANDed to the domain, resulting in a "subdomain AND t9_search" condition, which is not correct and unlikely to match anything. Forward-Port-Of: odoo/enterprise#97811 Forward-Port-Of: odoo/enterprise#97731
25 changes
Resolved issues and error corrections
Corrects the date field name used in Italian electronic invoice XML when linked invoice data is included. This helps prevent invoice rejections by Italy's e-invoicing system due to an invalid XML format.
Original PR description
The name for the date in DatiFattureCollegate (56e08bb091d39a18ea1c8e7699321b953a8823e1) is wrong. It is not DataDocumento but Data as per https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiFattureCollegate/Data/18
How to reproduce the issue:
- With l10n_it, create an invoice and fill the customer reference field.
- Generate the xml and validate through https://fex-app.com/servizi/verifica
- The following error related to the date happens: E-invoicing (Italy) La fattura elettronica è stata rifiutata dall'SdI. File non conforme al formato : Invalid content was found starting with element 'DataDocumento'. One of '{Data, NumItem, CodiceCommessaConvenzione, CodiceCUP, CodiceCIG}' is expected. riga: 80 - colonna: 24
opw-5082016
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#229120
Forward-Port-Of: odoo/odoo#227260The accounting settings now correctly show the OSS option for companies in Switzerland and the UK, not only EU countries. This helps affected businesses access the tax configuration they need without manual workarounds.
Original PR description
This PR https://github.com/odoo/odoo/pull/189315 changed the countries for which the OSS setting was visible. It has been limited to EU countries, however both UK and Switzerland need it as well. see discussion in task 4782337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could block users when assigning an account to bank statement lines. Odoo now avoids creating an invalid matching rule, so reconciliation can continue smoothly for affected bank journals and accounts.
Original PR description
Currently, when a user uses the 'Set Account' button to reconcile a statement line, the system may also create a reconciliation model for fees for the given journal/account combination, based on the…
Currently, when a user uses the 'Set Account' button to reconcile a statement line, the system may also create a reconciliation model for fees for the given journal/account combination, based on the previous statement line reference pattern. To extract a patter from the references, the system computes the normalised longest common substring. This will be used as regex matching pattern of the newly created reconciliation rule. However, the common substring may end up with '\\', which is not a valid termination of a regex, leading to the error: `Invalid operation. The regex is invalid.` Steps to reproduce: - Have an account '646000 Test Account' - Create a Bank statement with label 'TEST REFERENCE BNK 2024' - Set Account 646000 - Create a Bank statement with label 'TEST REFERENCE BNK.OTHER' - Set Account 646000 Issue: Error `Invalid operation. The regex is invalid.` will raise blocking the action [opw-5086638](https://www.odoo.com/odoo/project.task/5086638) [opw-5062965](https://www.odoo.com/odoo/project.task/5062965) [opw-5123963](https://www.odoo.com/odoo/project.task/5123963) [opw-5166160](https://www.odoo.com/odoo/project.task//5166160) [opw-5159871](https://www.odoo.com/odoo/project.task/5159871) [opw-5160108](https://www.odoo.com/odoo/project.task/5160108) [opw-5109454](https://www.odoo.com/odoo/project.task/5109454) [opw-5086638](https://www.odoo.com/odoo/project.task/5086638) ... Forward-Port-Of: odoo/enterprise#97865
This fixes the default document type suggested for Argentine foreign vendor bills so they consistently use the expected abroad invoice/receipt type. It also aligns foreign supplier behavior on customer invoices with the selected journal, reducing manual corrections and invoicing errors.
Original PR description
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del…
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively. In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners. With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers. Current behavior before PR: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers Desired behavior after PR is merged: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228635
The timesheet grid now keeps text from spilling into timer button areas when users view timesheets by month, enlarge text, and scroll horizontally. This improves readability and prevents confusing visual overlap in total and footer rows.
Original PR description
Steps to reproduce: - Open timesheets and change to Month scale. - Increase text size a little bit. - Scroll to the right side Issue: - You can see runover text being visible in timer button cell of Total row and Footer row. Reason: - It is due to z-index problem as z-index-* is deprecated from https://github.com/odoo/odoo/pull/165568 (from saas-17.4+). Fix: - Replace it with Bootstrap z-index class notated as z-*(-1 to 3) task-4949182 Forward-Port-Of: odoo/enterprise#96371
Fixes a website editor problem where changing or selecting shaped images could trigger an error, especially for content created before the editor migration. Existing shaped images remain usable after the move from the old editor path to the new HTML builder path.
Original PR description
Steps to reproduce: =================== 1. Drop a snippet having an image with a shape (e.g. "Intro Pill", "Images Mosaic", ...). 2. Try to change the image shape. → Traceback occurs. This issue also happens when clicking on images with shapes that were added in previous versions. Cause: ====== Before the refactoring, shape URLs started with `web_editor`, but now `html_builder` is expected. This mismatch causes the shape to be considered invalid when parsed, leading to a traceback. The issue was introduced by this PR: https://github.com/odoo/odoo/pull/222471 Solution: ========= Ensure backward compatibility by allowing shapes using the old `web_editor` path to remain functional after the migration to `html_builder`. Forward-Port-Of: odoo/odoo#230803
Invoice terms and conditions now refresh in the selected customer language when that language is changed during invoice creation. This prevents customers from receiving invoices with terms shown in the wrong language.
Original PR description
Issue: When changing the customer’s language during invoice creation, the terms & services were not retranslated, unlike when creating a new partner in a different language. Repro Steps: 1. Create an invoice with terms link or plain enabled. 2. Change the partner's language from the invoice creation view. 3. Terms is not translated. Cause: The translation compute was only triggered on partner change, not language change. Fix: Added dependency for partner_id.lang to the narration compute to ensure it updates when the language changes. opw-5031933 Forward-Port-Of: odoo/odoo#230800
This fix keeps report page numbers on a single line when using the folder layout with the Montserrat font. It improves the visual consistency and readability of printed or exported documents without changing report content.
Original PR description
The folder layout is using the same footer than the `external_layout_standard` but when using Montserrat, the page number wraps in 2 lines on the folder layout. It's missing a `text-nowrap` class. task-4942402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228391
Long mailing list names now remain inside their intended field instead of overlapping nearby information. This keeps the Marketing mailing list view readable and easier to use when list names are lengthy.
Original PR description
Issue: When you create a long name for your maling list, the name overflows over the other fields in the view. Repro: Go to marketing -> mailing lists -> create a fairly long name -> notice name overflows in the view. Cause: Small bootstrap issue, name field not limited to it's container. Fix: Added a simple w-100 to limit the field to 100% of it's container. opw-5153270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232312
This fix ensures the spreadsheet filter tooltip is fully visible when dark mode is active. It prevents a confusing visual issue, even though the spreadsheet app itself does not yet fully support dark mode.
Original PR description
The fitler tooltip was displayed halfay in dark mode, while the rest of spreadsheet does not support dark mode yet. Task: [5162869](https://www.odoo.com/web#id=5162869&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This fixes event communications so attendee-specific emails, such as badge or QR code messages, are no longer scheduled once an event is finished. Post-event communications tied to the event itself can still be sent, preserving intended follow-up messaging while avoiding confusing or unnecessary attendee emails.
Original PR description
Forward-Port-Of: odoo/odoo#229960 Forward-Port-Of: odoo/odoo#227986
This update fixes an internal purchase app test that was failing in single-app builds because it referenced an unavailable field. It helps keep automated quality checks reliable without changing day-to-day user behavior.
Original PR description
This issue comes from [218483](https://github.com/odoo/odoo/pull/218483) The field `is_storable` is invalid in single app build and breaks the `TestPurchase` class. Runbot - [230096](https://runbot.odoo.com/odoo/runbot.build.error/230096)
Accounting users can now create SEPA Direct Debit mandates without being blocked by an access error. This ensures teams with invoicing and banking permissions can complete their direct debit setup without needing system administrator rights.
Original PR description
Have the Payment Provider Sepa Direct Debit module installed. Connect with a user with access right for Accounting: Invoicing & Banks. Create a Direct Debit Mandate => Get an access error. Reason: the compute does a read_group with a value on payment.provider, which non System Admin have no access to. Solution: Add a sudo for these _read_group Forward-Port-Of: odoo/enterprise#97127
This fixes an access problem that could leave online shoppers stuck after a successful payment when strict journal sequencing was enabled. Payment confirmation can now complete properly for public website users, improving the checkout experience.
Original PR description
Error in backend while public user payment confirmation Steps: - Install `website_sale` - Activate `restrict_mode_hash_table` on sale journal - From an incognito window, Make an order in ecommerce and pay it -> we get stucked on 'Your payment has been successfully processed' page because of an acces error in the backend This is because when posting a new move, we either to access or modify moves we get from `chain['moves']`, however these moves are returned with `sudo(False)` by `AccountMove._get_chain_info()`. opw-5128189 Forward-Port-Of: odoo/odoo#232143
The event registration page now supports translation for the date selection labels used when events have time slots. This helps visitors using other languages see a consistent localized registration experience.
Original PR description
Scenario: - adds slots to an event - register to that event with another language Result: "Selected Date" or "Select a Date" is not translated or translatable. Fix: wrap those JS strings with _t function. opw-5167911 Forward-Port-Of: odoo/odoo#231729
This change moves the rule that hides the tip product field from the general restaurant point-of-sale module to the Belgian blackbox point-of-sale module. It keeps the behavior limited to the market-specific compliance feature where it belongs, reducing the chance of unintended effects for other restaurant POS users.
Original PR description
- Move logic to hide `tip_product` field from `pos_restaurant` to `pos_blackbox_be` module. task-id: 5011427 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Large PNG images uploaded to the website are now resized without the visible quality loss caused by palette conversion. This removes the need for users to manually resize images before uploading and helps website content look sharper.
Original PR description
When uploading a png image ir_attachment, the image is not modified if its resolution is under the maximum 1920x1920. However, if the resolution is bigger, it both gets resized and is converted to a WEB palette, which visibly degrades the quality of the image. A workaround for this is to resize the image locally to be max 1920 on either dimensions and then upload it, which effectively bypasses this special treatment. Steps to reproduce: - Go to the website app - Add a Text - Image snippet - Double click the image - Upload a .png image of a resolution strictly greater than 1920 in either width or height Old behavior: the png is visibly degraded New behavior: the png is not visibly degraded opw-3935533 Forward-Port-Of: odoo/odoo#173508
The Last Appraisal button is available again for employees after it was unintentionally removed. This helps managers and HR users quickly access an employee's most recent appraisal from the employee record.
Original PR description
The action on res.users to see the last appraisal has been removed by this PR https://github.com/odoo/enterprise/pull/88518. This commit reintroduces the action in hr.employee.public. task-5166704
This fixes the planning dialog opened from a sales order so users can see and set allocated hours when creating a shift. It prevents missing scheduling information for sales-related planning services, making shift planning from sales orders work as expected.
Original PR description
Steps to reproduce: - Create a Sales order with planning services. - Click on To Plan stat button. - Click on empty cell Issue: - Plan dialog is opened but has missing allocated_hours field. Reason: - In this commit https://github.com/odoo/enterprise/commit/d21bd4b694ec63ba83bea077714a8fe928d6e014 allocated hours was merged with start_datetime using a widget and thus removed from view. - But in planning list view we hide start_datetime when we schedule shifts from sales order. Fix: - Add back allocated_hours conditionally to be visible when we schedule shifts as in other cases start_datetime is present. task-5117776 Forward-Port-Of: odoo/enterprise#96391
This update fixes several business-facing issues across accounting, payroll, localization reports, and translations. It improves tax accuracy in bank reconciliation and trial balance reports, allows authorized payroll administrators to cancel payslips, corrects Indian and Peruvian tax reporting data, and refreshes many translations.
This update fixes the layout of the ePos test widget and Epson printer IP field in Point of Sale settings. The fields are now better aligned and spaced, making the configuration screen clearer and easier to use.
Original PR description
- Adjust the display of the ePos test widget and Epson printer IP field in the Point of Sale configuration and settings views for better alignment and spacing. | View | Before | After | | :--- | :----: | ---: | | pos_config_view.xml | <img width="406" height="151" alt="image" src="https://github.com/user-attachments/assets/e2b6f619-62e7-44d8-928b-53ce5401d9a7" /> | <img width="403" height="184" alt="image" src="https://github.com/user-attachments/assets/96a0137d-cc56-4b2e-a322-811e5ad4b130" /> | | res_config_settings_views | <img width="535" height="249" alt="image" src="https://github.com/user-attachments/assets/679a1fce-45f3-4378-96bb-077d8cdef2e1" /> | <img width="535" height="218" alt="image" src="https://github.com/user-attachments/assets/efd62f18-a3fc-45f2-9ca2-4132a6b1a1df" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Helpdesk SLA reporting view now lets users add the SLA status grouping back after removing it. This avoids needing to reload the report and makes analysis smoother for support teams.
Original PR description
Currently, when the user opens the sla reporting view, if he removes the default grouping of sla_status, he has no way to get it back unless he reloads the view completly. This commit fixes this issue by adding the sla_status field to the group_by options. task-5076401 Forward-Port-Of: odoo/enterprise#95261
This update fixes several issues when launching AI chat from the systray, including missing message recipients, missing record details, and crashes on some forms. It also makes system AI agents visible for easier configuration and improves handling of prompt-based chats.
Original PR description
Currently: - when using the "Send as Message" button in a chat with an agent (opened from the systray), the default recipients are not added in the composer - creating a default prompt for "get help…
Currently: - when using the "Send as Message" button in a chat with an agent (opened from the systray), the default recipients are not added in the composer - creating a default prompt for "get help on a record" on a model that does not inherit from `mail.trhead` does not work: it's the default "ask ai" chat that is opened when clicking on the "ai" button in the systray from this record's form view ( the "prompt buttons" created are not shown and the record info is not added in the prompt) - clicking on this ai button in the systray from the res.users form view results in a crash (one tries to fetch a thread because the model has a "message_ids" field, but it's a related field and the model does not have a thread) - "system agents" are not shown in the agent views, making it difficult to edit them (while one user could want to change the model used by a system agent if that user does not have an api key for the provider of the default model) With this PR: - adds the default recipients (and creates their related partner if needed, as it would be done when opening the full composer from the chatter) - the info about the current record is always added to the context when using the ai systray button from a form view, even if there's no chatter - the "send as message" and "log note" are added from the launch chat service, only if the model inherits from `mail.thread` (instead of relying on the field `message_ids`) - moved the call to open the ai chat back to the form controller to avoid sending 2 events on the bus (currently systray sends an event to the form controller which in turn sends an event with the model info to the systray), and to make it easier to reuse this "open chat with agent" (shouldn't need to always go through the systray for that) - the "system agents" are now shown in the agents views. Their name/description have therefore been reworked. The website page generator and call summarizer agents are now archived by default, as they are only used in very specific contexts Task-5109721
This fix prevents active website live chat conversations from being canceled when a customer starts another chat. It helps customers keep ongoing conversations open across devices or sessions while still clearing only requests that are truly pending.
Original PR description
The website livechat module allows agents to start conversations with customers, but conversations are only displayed on the next navigation. Previously, pending chat requests were canceled whenever a customer opened a new live chat. The search condition for pending chats was too broad: it did not consider who started the conversation or whether it was already ongoing. As a result, ongoing chats could be unintentionally canceled. Customers could have multiple conversations (e.g. on different devices). This change ensures that only pending chat requests are canceled, leaving ongoing chats intact. task-5186567 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#232704 Forward-Port-Of: odoo/odoo#232624
Fixed an Accounting issue where grouping customer invoices by sent status showed every invoice in both Sent and Not Sent groups. Users can now rely on this grouping to review invoice communication status accurately.
Original PR description
### Issue: The groups "Sent" and "Not Sent" display all the invoices. ### Steps to reproduce: - Go in Accounting > Customer > Invoices - Create a custom GroupBy with "Sent" - Unfold the groups: all invoices appear in each group ### Cause: `web_read_group` returns the groups with their length and the domain corresponding. When unfolding `web_search_read` uses the given domain to get the records to display. Here the issue comes from the domain returned, it contains `['move_sent_values', '=', 'sent']`, but `move_sent_values` is a computed field that doesn't have a `_search` method so the domain doesn't filter on this field. ### Solution: Add the method `_search_move_sent_values` to search on `is_move_sent`. opw-5164650 Forward-Port-Of: odoo/odoo#232400
15 changes
Resolved issues and error corrections
This update makes rental-related automated tests more reliable when demo data is not installed. It ensures the tests set up the required accounting and stock information themselves, reducing false failures in validation environments.
Original PR description
The test was failing in no-demo environments because it relied on accounting and stock configurations that were not present. When the test attempted to set property_valuation = 'real_time' on the product category, it triggered a ValidationError because the related stock accounts had not been properly set up for the test's transaction context. runbot-error-230417 Forward-Port-Of: odoo/enterprise#92292
The Vietnam localization migration now updates only the required tax records instead of reloading the full chart setup. This reduces the risk of overwriting company-specific accounting settings during an upgrade.
Original PR description
Problem The previous implementation used try_loading() which would reload the entire chart template, potentially overwriting user-customized configurations settings. Solution Replaced try_loading() with a more targeted approach usin _load_data for account.tax.group and account.tax 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#227918
Work entry generation now handles employees whose contracts use different working schedule types, reducing incorrect or missing entries. It also better accounts for employee time zones when fully flexible employees do not have a set calendar, helping payroll and attendance data stay accurate.
Original PR description
- fix work entries generation for employees with different working schedules types - made work entries generation check for employee timezone in case the employee is fully flexible and doesn't have a calendar - added method `_get_calendar_at` to get the calendar of the resource at a given date - added `test_work_entry_different_calendars` for work entries generation for employees with contracts with different calendar types task-id: 5065160
This fix updates internal test expectations for work entry calculations when employees use different work schedule types. It helps ensure payroll and appointment-related processes continue to be validated correctly after the calendar lookup behavior changed.
Original PR description
- adjusted some query counters to account for the extra search in `_attendance_intervals_batch` done by the method `_get_calendar_at` task-id: 5065160
Portal profile updates now avoid overwriting a saved bank account holder name when the user has not changed their own name. This protects employee banking details from accidental changes during routine address or profile edits.
Original PR description
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a…
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a Bank Account with a custom Account Holder Name. 4. Log in to the Website using the Test User. 5. Navigate to My Account and click Edit Information. 6. Fill in the address details (without changing the Name) and click Save. 7. Go back to the Employee’s Bank Account and check the Account Holder Name. Observation: ------------------------- The Account Holder Name was overwritten to the partner's name. Issue: ------------------------- In `_compute_account_holder_name` method, https://github.com/odoo/odoo/blob/c3b543631bde96260082484a3baac19d942f6b9f/odoo/addons/base/models/res_bank.py#L104-L107 The Account Holder Name is always recomputed using the Partner’s name. When submitting the form from the frontend, the name field is included in the values sent to update the Partner, even if the user did not actually change the name. https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/portal/controllers/portal.py#L196-L205 which re-triggers this compute and as a result, the Partner’s name overwrites the Account Holder Name on the linked Bank Account Solution: ------------------------- Prevent the Account Holder Name compute method from being triggered when updating information from the frontend if the Partner’s name has not been changed. opw-5059247 Forward-Port-Of: odoo/odoo#229210
This change prevents an error that could occur when users expanded a Spanish VeriFactu document. It removes an unsupported discussion panel from the document screen, improving stability without changing business workflows.
Original PR description
The system will crash with error when user clicks on expand button. **Error:** `AttributeError: 'l10n_es_edi_verifactu.document' object has no attribute '_get_thread_with_access'` **Cause:** - `l10n_es_edi_verifactu.document` does not inherits ['mail.thread', 'mail.activity.mixin'] and used chatter in it's form view. - In this PR, removed `<chatter/>` from view. Already fixed for master here: https://github.com/odoo/odoo/pull/231477 **sentry-6792833694** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231601
Submenu items in the website navigation now keep the same font styling as the main navbar. This prevents submenu text from unexpectedly changing when a user updates the paragraph font, keeping website menus visually consistent.
Original PR description
To reproduce: ============= 1- Go to website 2- Add a submenu to any menu item. 3- Choose a font for the navbar. 4- Change paragraph font. → Observe that the added submenu in the navbar also changes…
To reproduce: ============= 1- Go to website 2- Add a submenu to any menu item. 3- Choose a font for the navbar. 4- Change paragraph font. → Observe that the added submenu in the navbar also changes its font. Problem: ========= When creating submenu the class nav-link which contains the navbar font was removed by theses lines: https://github.com/odoo/odoo/blob/6f5682b1cab3c2e043e1f1d4316093bab2752521/addons/website/static/src/js/content/auto_hide_menu.js#L173-L179 cause this one was false https://github.com/odoo/odoo/blob/6f5682b1cab3c2e043e1f1d4316093bab2752521/addons/website/static/src/js/content/auto_hide_menu.js#L39-L39 but in the default template the navbar has another class name https://github.com/odoo/odoo/blob/6f5682b1cab3c2e043e1f1d4316093bab2752521/addons/website/views/website_templates.xml#L498-L498 Undesired Behavior: =================== When you set a navbar font, the navbar and submenu both initially use it. But if you change the paragraph font afterward, the submenu text incorrectly switches to the paragraph font, while the navbar still uses the correct navbar font. Desired Behavior: ================== Once a navbar font is set, it should be consistently applied to both the navbar and submenu text, regardless of changes to the paragraph font afterward. Solution: ========= If we are in the navbar we will keep the nav-link class. Link for bug: https://drive.google.com/file/d/1OyWUUEvvtHw5MKITew5F_KOP_m6zgi9B/view opw-4943240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Point of Sale issue where a session could lose or show the wrong user when another employee opened it in a separate browser tab. It helps ensure payments through Six terminals use the correct employee context, reducing checkout errors.
Original PR description
This commit fixes an undefined `user_id` on the pos session when trying to start a payment with a Six terminal from another user than the one that started the session. Before this commit: - open a pos session with Mitchell Admin, - check the value of `pos.session.user_id` (it will be `2`), - open another tab and connect as Marc Demo, - check the value of `pos.session.user_id` again: it should be `6`, but instead is `undefined`. After this commit: `pos.session.user_id` is set to the right `user_id` while loading pos data. opw-5055977
The web test runner now handles cases where someone clicks Run before all test assets have finished loading. This prevents an early-click crash in manual testing and makes the test workflow more reliable.
Original PR description
Before this commit, in manual mode, "Run" could be clicked before the assets finished loading (and so, before the test runner was properly "ready"). This caused a crash because it tried to resolve a promise that did not exist yet. Steps to reproduce: - Go to test URL (manual) - Click "Run" as soon as the button is visible (probably via a script to make sure the click is fast enough) This commit fixes that by adding failsafes around that promise, effecitvely allowing to click "Run" early on. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Benefits form now prevents users from creating related employee, cost, or mandatory benefit records from the selection fields. This keeps benefit setup cleaner and reduces accidental duplicate or incomplete records.
Original PR description
This commit prevents creating new employee, cost or mandatory benefits records directly from the Benefits form by setting these fields' `'no_create'` to `True`. task-5156844
Splitting a delivery now correctly updates the status of the original stock movement, not just the newly created one. This prevents warehouse users from seeing misleading availability information after part of a delivery is split off.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Update its quantity to 10 - Create a delivery picking with 10 units of P1 - Confirm → The picking is in “Ready” state and the move is “Available” - Update the “Quantity” of P1 to 6 units in the picking → The move state is recomputed to “Partially Available”, since the demanded quantity exceeds the quantity done. https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L2207-L2208 - Split the picking Problem: A new picking is created with 4 units in quantity and its move is “Available”, but the original move with 6 units does not have its state recomputed. opw-5173374
Fixes an issue where pages containing videos added by an administrator could become uneditable for restricted website editors. Videos are now stored in a sanitizer-friendly way and rebuilt for visitors, allowing non-admin editors to keep updating website content safely.
Original PR description
Steps to reproduce the current behaviour: - Update the DEMO user to be a website "restricted editor" and sales "admin" who cannot bypass HTML field sanitization. - As ADMIN, add a YouTube video to a…
Steps to reproduce the current behaviour: - Update the DEMO user to be a website "restricted editor" and sales "admin" who cannot bypass HTML field sanitization. - As ADMIN, add a YouTube video to a product page > Save. - As DEMO, try to update the content on the product page > You cannot (a dialog informs you that you cannot edit the content because an admin edited it previously). Explanation: Starting from [1], an HTML field can be flagged as `sanitize_overridable` which allowed users with the `base.group_sanitize_override` group to skip the HTML field sanitize process. If such users added some content that is not considered "sanitize friendly" (e.g. YouTube iframe), a restricted user won't be allowed to add content in the fields, since the sanitizer will remove the original content from the DOM. For this case, the code from [2] added an implementation to consider the field as none editable and warn the user once he tries to update it. Implementation: The goal of this commit it to fix the current limitation for video upload that currently prevents non admin users to edit a website record once an admin adds a video on it... The idea of the fix is the following: - We already have a technical fallback when uploading a video to save the iframe `src` to an attribute: `data-oe-expression`. - The public widget is now destroying the video iframes so they are never saved in the DOM. - A non-lazy code will build the iframes immediately on page load. - The public widget can always create the iframes if they are not already created (for compatibility). [1]: https://github.com/odoo/odoo/commit/cf844e34dd0ce4830eb99fd0fa5b6b9cb58c867c [2]: https://github.com/odoo/odoo/commit/cb80c15d3db49ede3c93171abcaa9064b88822c6 task-3757205 Forward-Port-Of: odoo/odoo#175717
Manufacturing shop floor backorders now show the quantity needed for the specific operation instead of the total remaining manufacturing order quantity. This prevents operators from recording too many units on partially completed steps and helps keep production progress accurate.
Original PR description
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total…
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation. **STEP TO REPRODUCE** 1. create a BoM of product with 3 or more operations 2. Create a Manufacturing order for i.e. 10 unit 3. Open shop floor 4. Register the production in shopfloor: - Op1 – 10 units registered - Op2 – 7 units registered - Op3 – 5 units registered 5. At the end, a backorder is created for 5 units. 6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step. **CAUSE** When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order. **FIX** We should pass `qty_production` instead which is the quantity to produce for the specific step. opw-5011739 Forward-Port-Of: odoo/enterprise#93599
Large PNG images uploaded to Odoo are now resized without being converted to a lower-quality color palette. This prevents visible image degradation on website content and removes the need for users to resize images manually before uploading.
Original PR description
When uploading a png image ir_attachment, the image is not modified if its resolution is under the maximum 1920x1920. However, if the resolution is bigger, it both gets resized and is converted to a WEB palette, which visibly degrades the quality of the image. A workaround for this is to resize the image locally to be max 1920 on either dimensions and then upload it, which effectively bypasses this special treatment. Steps to reproduce: - Go to the website app - Add a Text - Image snippet - Double click the image - Upload a .png image of a resolution strictly greater than 1920 in either width or height Old behavior: the png is visibly degraded New behavior: the png is not visibly degraded opw-3935533 Forward-Port-Of: odoo/odoo#173508
Helpdesk SLA reports now include the SLA status as an available grouping option. This lets users remove and reapply the grouping without having to reload the report, making analysis smoother and less frustrating.
Original PR description
Currently, when the user opens the sla reporting view, if he removes the default grouping of sla_status, he has no way to get it back unless he reloads the view completly. This commit fixes this issue by adding the sla_status field to the group_by options. task-5076401 Forward-Port-Of: odoo/enterprise#95261
7 changes
Resolved issues and error corrections
Users in timezones with 30- or 45-minute offsets will no longer see an incorrect timezone mismatch warning when their device and Odoo preferences match. This removes a confusing false alert in user preferences without changing timezone settings behavior.
Original PR description
**Steps to reproduce** - Set your machine timezone to one ending in :30 or :45 - Open your user preferences and chose the same timezone Issue: the timezone mismatch icon is displayed. **Cause** `.toFixed(0)` rounds to the nearest integer. **Change** Always round down the hour part. opw-5123025
Creating a new warehouse could incorrectly generate many duplicate replenishment routes when an existing global route had been renamed for a company. This fix reuses the intended route name when checking for existing routes, preventing clutter and unnecessary records in inventory configuration.
Original PR description
In _find_or_create_global_route, use the asked 'route_name' instead of the potentially modified name of `data_route`. This ensures that if '_find_or_create_global_route' is called with the exact same values a new route will not be re-created. https://github.com/user-attachments/assets/815adf60-aa2d-4699-a79d-f9ad9607cbea ## How to reproduce (in runbot 17.0): - Enable "Multi-steps Routes" - Unarchive route "Replenish on Order (MTO)", change the name, set company to "My company (San Francisco)" - Go to "My Company (Chicago)" - Create new Warehouse => Check all the routes: ~100 MTO routes with the modified name have been created. OPW-5149842 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now checks live browser connections at the application level when no activity has occurred for a short period. This helps detect dropped connections more quickly on slow or unstable networks, reducing the time users may miss real-time updates.
Original PR description
When a TCP connection is not closed cleanly, it can take minutes to detect a closed WebSocket connection. During this time, no messages are received. This can happen in slow or unstable network conditions. Browsers do not expose WebSocket ping/pong mechanisms. To detect dead connections quickly, periodic application level messages are sent if no messages were either sent or received within a minute. This approach ensures quicker detection compared to relying on the OS TCP timeout, which is typically set to a high value. 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
Fixed an issue where Argentina VAT summary reports could overstate totals when price-included VAT was used with multiple IIBB taxes on the same vendor bill. The report now counts each tax amount only once, helping businesses rely on accurate tax summaries that match accounting records.
Original PR description
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#85873
This fix ensures the point of sale cash drawer can still be opened through an ePOS printer even when a configured IoT box is unreachable. It prevents store staff from being blocked at payment by an unrelated disconnected device.
Original PR description
Steps to reproduce: 1. Configure a POS to use an ePOS printer with the cashdrawer enabled. 2. Also configure the POS to use an IoT box with a dummy device, e.g. '[Shop] Scale'. The important thing is that the IoT box is not reachable when the POS opens, so the dummy devices work well for this. 3. Open the POS, make an order and go to payment, then click 'Open cashbox'. Expected behaviour: The cashdrawer opens Actual behaviour: Nothing happens task-5059502 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes a website-related automated test independent from optional demo data. It helps ensure test results are more consistent, reducing false failures in development and release validation.
Original PR description
runbot-162894
Italian electronic bill imports now avoid applying the same discount twice when the XML contains both a discount section and a separate negative line. This helps keep vendor bill totals accurate and prevents extra manual correction after import.
Original PR description
When importing a bill in an IT company the system will automatically parse the xml and populate the record. In case of discount, an element <ScontoMaggiorazione> will be present, either for the whole document or for a single line. However, an extra negative line may be present in the xml representation of the bill, creating a double discount **Steps to reproduce** - With an IT Company setup - Import an xml bill having <ScontoMaggiorazione> element and a negative line representing the same discount **Issue** Double discount line will be created in the bill **Analysis** This occurs because, when parsing the bill, the system will import also negative lines, even if a discount has been already applied opw-4913335 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4913335)