Daily updates from Odoo
Navigate
Branch
Thursday, October 23, 2025
205 changes
15 changes
Enhancements to existing features
This update suppresses misleading warning messages caused by an operating system packaging issue on Ubuntu Jammy environments. It helps keep automated checks and server logs cleaner without changing business features or user workflows.
Original PR description
Apparently on jammy the pdfminer package returns nonsensical versions (the distribution for `pdfminer.six` yields `-VERSION-`, and inside the python code the `__version__` is `__VERSION__`). When trying to look up the distribution for the (invalid as a distribution name) `ldap`, as a fallback `pkg_resources` parses every package on the sys.path before returning a lookup failure. Doing so, it encounters `pdfminer` fails to parse its version as a `Version`, warns that that is deprecated, then parses it using the more lenient `LegacyVersion` and warns that this is also deprecated. Since this is a packaging issue in just jammy and we can't really do anything about it, just sweep the issue under the rug. https://runbot.odoo.com/odoo/error/163677 Forward-Port-Of: odoo/odoo#232650
Belgian partner lookup on the Peppol network now checks the two most commonly used identifiers, improving the chances of finding the right participant. Related warning messages about recommended identifiers were removed because the mandatory identifier handling is now managed automatically by the Peppol access service.
Original PR description
1. For belgian partner, we now check for 0208 and 9925 which are the two most used EAS when looking for partner existence on the Peppol network. 2. Remove the warnings about the recommended EAS: 0208 is now the mandatory EAS, this will be handled directly on IAP where the Peppol Access Point will try to register 0208 in all cases with an alias system. Note that we have always computed 0208 as recommended value in registration process. task-4852903 Forward-Port-Of: odoo/odoo#231142 Forward-Port-Of: odoo/odoo#227431
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
Code cleanup and technical improvements
This update applies automated code quality checks to the VoIP area without changing how users make or receive calls. It helps keep the codebase consistent and easier to maintain, reducing the risk of future issues.
Original PR description
Forward-Port-Of: odoo/enterprise#97753
12 changes
Enhancements to existing features
This update suppresses misleading warning messages caused by an external packaging issue on Ubuntu Jammy environments. It helps keep monitoring and logs cleaner without changing user-facing Odoo behavior.
Original PR description
Apparently on jammy the pdfminer package returns nonsensical versions (the distribution for `pdfminer.six` yields `-VERSION-`, and inside the python code the `__version__` is `__VERSION__`). When trying to look up the distribution for the (invalid as a distribution name) `ldap`, as a fallback `pkg_resources` parses every package on the sys.path before returning a lookup failure. Doing so, it encounters `pdfminer` fails to parse its version as a `Version`, warns that that is deprecated, then parses it using the more lenient `LegacyVersion` and warns that this is also deprecated. Since this is a packaging issue in just jammy and we can't really do anything about it, just sweep the issue under the rug. https://runbot.odoo.com/odoo/error/163677 Forward-Port-Of: odoo/odoo#232650
This change improves performance when sales orders look up linked projects for reinvoicing. It helps avoid slower database scans as project data grows, making related sales and project views more responsive.
Original PR description
This commit adds an index on `project.project. reinvoiced_sale_order_id`, because the search in `sale.order. _compute_project_ids` might not be selective enough based on `sale_order_id`, which is a related field using `sale_line_id`. Since it's related, there is only a where clause on `sale_line_id IS NOT NULL`, which might not be selective enough and leads to a Seq. Scan of the `project_project` table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232623
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
Code cleanup and technical improvements
This update applies standard linting cleanup to the VoIP softphone code. It does not change user-facing behavior, but helps keep the code easier to maintain and less prone to small technical issues over time.
Original PR description
Forward-Port-Of: odoo/enterprise#97752
4 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
Code cleanup and technical improvements
This update applies automated code quality cleanup to the VoIP area. It does not add or change business features, but helps keep the codebase easier to maintain and safer for future updates.
Original PR description
Forward-Port-Of: odoo/enterprise#97751
30 changes
New functionality added to Odoo
VoIP users can now see calls in a calendar view, making it easier to plan and track scheduled call activity. This improves visibility over upcoming communications and helps teams manage follow-ups more effectively.
Original PR description
Task-5025572 Community: https://github.com/odoo/odoo/pull/224255
Enhancements to existing features
The equity transaction form has been reorganized to make key information easier to read and enter. Transaction, beneficial owner, and valuation records now have clearer names, and tracked security prices show the correct currency symbol for easier review.
Original PR description
This commit 1. Reorders fields on transaction form 2. Gives better display names for transactions, ubos, and valuations 3. Fixes the tracking of transaction security_price not having currency sign task-5144766 Forward-Port-Of: odoo/enterprise#97644
Multi-company financial reports can now group lines by account code before individual account. This makes it easier for users to compare and review accounts consistently across companies.
Original PR description
If the report has a line that contains a group by `account_id` and if the report is multi-company, we allow the user the group per `account_code` before `account_id`. task-5092712 Forward-Port-Of: odoo/enterprise#94920
The payroll payment report popup now shows a meaningful title instead of the generic “Odoo” label. This makes it clearer to users which payroll action they are performing and reduces confusion across supported payroll localizations.
Original PR description
When users clicked the Payment Report button, the popup window opened with the generic title, Odoo. This was confusing because it provided no context about the action being performed. This change introduces a dedicated action so that the wizard displays a meaningful title. task-5052018
HR salary configuration now lets users archive personal information fields, benefits, and resume items they do not want to use. This helps companies keep their preferred setup after upgrades, instead of removed items reappearing automatically.
Original PR description
…its and resume Some want to remove some personal info fields they don't want in their salary configuration but, after an upgrade, those fields are put back. These changes allow the archiving of personal info, benefits and resume so that users can configure what they want without worrying about an upgrade making the records come back. There was no need to add the active field in the personal_info and salary_resume models, since they were already included. I just had to add them in the views in these cases. task-4901052
Payslip action buttons have been renamed to use clearer wording. This makes payroll screens easier to understand by changing “Compute Sheet” to “Compute” and “Recompute whole sheet” to “Recompute whole payslip.”
Original PR description
. payslip compute sheet buttons renamed from "Compute Sheet" to "Compute" for better clarity . action button "Recompute whole sheet" renamed to "Recompute whole payslip"
Salary rule descriptions on payslips now wrap onto multiple lines instead of being cut off. This makes payroll information easier to read both on-screen and in printed or PDF payslips.
Original PR description
Ensures full description is visible on both the payslip view and PDF by wrapping text instead of cropping it. task-5034372
UrbanPiper test orders can now be launched directly from the POS frontend debug widget instead of the backend configuration page. This reduces tab switching and makes it easier for teams to validate the UrbanPiper order flow during setup or troubleshooting.
Original PR description
Before this commit: --------------- The UrbanPiper test order action was only accessible from the backend POS configuration form. This required opening two separate tabs to test the UrbanPiper order flow. After this commit: --------------- - The "UrbanPiper Test Order" action is now available directly in the frontend debug widget. - Removed the test order button from the configuration page. <img width="1308" height="108" alt="image" src="https://github.com/user-attachments/assets/706d0a88-4b52-42da-88cc-4bf2f80fab7a" /> Task-4977992
Icon resources are now loaded through a shared bundle in the affected apps, helping keep the interface consistent and easier to maintain. This is a minor technical improvement with low direct impact for everyday users.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/224663 See community PR for details: https://github.com/odoo/enterprise/pull/94023#issue-3387954727
The payroll employee view now consistently places the External Codes section at the end of the payroll area. This makes the screen layout more predictable for users and avoids the section appearing among other payroll fields depending on system loading order.
Original PR description
Made sure that the External codes Group appear last in the payroll view. Previously the `external_codes` group was added with `position="inside"` on the `payroll_group`, which caused it to sometimes appear in the middle of the payroll fields depending on the load order of inherited views. This commit changes the inheritance to use `position="after"` on `payroll_group`, so that `external_codes` is consistently inserted at the end of the payroll section. task - 5109281
The payroll and salary configuration screens now use the clearer label "Employee Record" instead of "Version" for employee-related records. This makes the wording easier for HR users to understand and aligns chatter messages with the updated terminology.
Original PR description
Rename "Version" to "Employee Record" in selection option of type `hr.version` and in chatter message. task-5074160
This update improves how Documents Spreadsheet keeps user-entered information during spreadsheet interactions, reducing the chance of losing or overwriting work. It also updates automated checks for charts and list views to ensure the behavior remains reliable.
Original PR description
Enterprise counter-part of https://github.com/odoo/odoo/pull/227449 This commit contains adaptation of tests. task-4756754
The AI website live chat now retrieves conversations through the dedicated chat channel system instead of a more generic messaging route. This is an internal improvement that should make the live chat integration cleaner and easier to maintain without changing the user experience.
Original PR description
This commit replaces the use of the `mail.thread` model to retrieve a channel with the direct use of the `discuss.channel` model.
The German tax report has been reworked after removing the balance column, so related calculations and report logic continue to align with the new layout. This keeps the report clearer and helps ensure German tax reporting remains accurate for businesses.
Original PR description
After removing the balance column, we need to refactor the code that depends on it task-5046641
The VoIP call history screens have been adjusted to work better on smaller devices, making recent calls easier to read and use on mobile. The update also improves visual alignment of phone details and status indicators for a cleaner, more consistent experience.
Original PR description
**Purpose:** - The form view was broken on mobile, making it difficult to read and interact with. - The list view was not usable on smaller screens, so a kanban (fake list) view was required for a better mobile experience. - The country flag was misaligned with the phone number in views. - The state badge was not vertically centered in the list view. **Specification:** - Fixed the form view layout for mobile while keeping the desktop layout intact. - Added a kanban view to improve readability and usability on small screens. - Updated “Recent Calls” redirection to open in kanban view on mobile and in list view on desktop. - Fixed alignment of country flag with the phone number. - Fixed vertical alignment of the state badge in list view. **Task**-5060875
BACS payments can now use UK account numbers and sort codes directly, instead of relying only on IBAN details. This makes setup more practical for UK bank accounts and removes an unnecessary journal field from Direct Debit mandates to keep payment handling clearer.
Original PR description
BACS was only supporting IBAN account type and extracting account number and sort code from it. Added support for BACS to handle account number and sort code(clearing number field) separately. Removing Journal fields on bacs.ddi, ss there's no reason that we have payment_journal_id field on the mandate, as all related journal logic is in the payments themself. task-4630586
The ESG emissions workflow now opens emitted emission records through a dedicated form, making navigation more consistent regardless of the source record. It also prevents users from choosing a physical calculation method when the required unit of measure is missing, avoiding save errors.
Original PR description
task-5152778
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
Code cleanup and technical improvements
This update applies standard code quality checks to the VOIP area. It helps keep the codebase consistent and easier to maintain, with no expected change to day-to-day user behavior.
Original PR description
Forward-Port-Of: odoo/enterprise#97755
24 changes
Security fixes and vulnerability patches
The API documentation now hides saved API keys like passwords, reducing the chance they are exposed on screen. The API key dialog also includes a direct link to the backend page where users can create a new key more easily.
Original PR description
This commit sets the field type of the api key setting as password to hide it from the user. It also adds a link in the api key dialog to open the api key page in the backend and let the user create an api key more easily. Task: 5039248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This change suppresses a misleading warning caused by a third-party packaging issue on Ubuntu Jammy systems. It helps keep logs and automated checks cleaner without changing business functionality or user workflows.
Original PR description
Apparently on jammy the pdfminer package returns nonsensical versions (the distribution for `pdfminer.six` yields `-VERSION-`, and inside the python code the `__version__` is `__VERSION__`). When trying to look up the distribution for the (invalid as a distribution name) `ldap`, as a fallback `pkg_resources` parses every package on the sys.path before returning a lookup failure. Doing so, it encounters `pdfminer` fails to parse its version as a `Version`, warns that that is deprecated, then parses it using the more lenient `LegacyVersion` and warns that this is also deprecated. Since this is a packaging issue in just jammy and we can't really do anything about it, just sweep the issue under the rug. https://runbot.odoo.com/odoo/error/163677 Forward-Port-Of: odoo/odoo#232650
This pull request updates several website and HTML editing tools used to build pages, forms, menus, links, carousels, and layout blocks. The changes appear aimed at improving the page-building experience and editor behavior, although the PR description is incomplete and the commit is marked as work in progress.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Czech localization now includes dedicated fiscal positions for intra-community and extra-community transactions. This helps businesses apply the correct 0% EU goods and services tax setup more reliably.
Original PR description
When using the CZ localisation, the fiscal position are not fully set up. This commit will create a new fiscal position for intra-community and changes the 0% EU G and 0% EU S taxes to have that fiscal position. To be able to have the "replaces" (original_tax_ids) fields, i had to change the vat_required field on the domestic fiscal position. task-5103864 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how Odoo finds projects linked to reinvoiced sales orders. It can reduce slow database searches in sales and project workflows, helping larger databases respond more efficiently without changing user-facing behavior.
Original PR description
This commit adds an index on `project.project. reinvoiced_sale_order_id`, because the search in `sale.order. _compute_project_ids` might not be selective enough based on `sale_order_id`, which is a related field using `sale_line_id`. Since it's related, there is only a where clause on `sale_line_id IS NOT NULL`, which might not be selective enough and leads to a Seq. Scan of the `project_project` table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232623
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
Code cleanup and technical improvements
This update applies code quality checks and cleanup across the VoIP feature, including the softphone and related tests. It does not introduce new user-facing functionality, but helps keep the calling tools more reliable and easier to maintain over time.
Original PR description
Forward-Port-Of: odoo/enterprise#97753
This update applies automated code quality rules to the VoIP area without changing how users place or manage calls. It helps keep the codebase consistent and easier to maintain, reducing the risk of future issues.
Original PR description
Forward-Port-Of: odoo/enterprise#97754
Documentation and clarification updates
This pull request adds or updates a contributor license agreement signature for DevSijariya. It is an administrative legal update that confirms contribution eligibility and does not change Odoo features or user workflows.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
10 changes
Enhancements to existing features
This update suppresses misleading warning messages caused by a packaging issue in Ubuntu Jammy's PDF tooling. It keeps server logs cleaner so teams can focus on real issues without changing business functionality.
Original PR description
Apparently on jammy the pdfminer package returns nonsensical versions (the distribution for `pdfminer.six` yields `-VERSION-`, and inside the python code the `__version__` is `__VERSION__`). When trying to look up the distribution for the (invalid as a distribution name) `ldap`, as a fallback `pkg_resources` parses every package on the sys.path before returning a lookup failure. Doing so, it encounters `pdfminer` fails to parse its version as a `Version`, warns that that is deprecated, then parses it using the more lenient `LegacyVersion` and warns that this is also deprecated. Since this is a packaging issue in just jammy and we can't really do anything about it, just sweep the issue under the rug. https://runbot.odoo.com/odoo/error/163677 Forward-Port-Of: odoo/odoo#232650
The web team has updated the code quality setup so VOIP-related modules are now included in linting checks. This helps catch issues earlier during development and supports more consistent maintenance, with no direct change for end users.
Original PR description
Forward-Port-Of: odoo/odoo#232484
This update adds new capabilities for Six payment terminals in Odoo Point of Sale, including end-of-day balance report printing and support for refunds or reversals. It also improves transaction handling, receipt formatting, and card information handling to make terminal operations faster and more reliable for merchants.
Original PR description
Based on the feedback received from our partners we are missing some features in our Six terminal integration. This PR adds them 1. Send balance command to print end-of-day report 2. Adapt the code to reduce the sleep delay after each transaction 3. Refunds/payment reversals for Six + it also adds some minor code improvements like a) Card brand is now saved in pos payments instead of the card number b) Card number is still being sent to PoS and while not stored in v17 will be stored from v18 c) The code of ctypes_terminal_driver and Six Driver was improved to reuse the buffer size and improve the buffer usage d) Fixes the receipt size for the Six terminals e) updates the Six C libraries used to the latest version to get all the newest fixes Related C PR: https://github.com/odoo/worldline-lib/pull/9 Forward-Port-Of: odoo/enterprise#96748
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
Code cleanup and technical improvements
This update applies automated cleanup to the VoIP codebase without changing how users make or manage calls. It helps keep the module easier to maintain, reducing the risk of future issues and making ongoing improvements smoother.
Original PR description
Forward-Port-Of: odoo/enterprise#97750
5 changes
Enhancements to existing features
This change makes automated browser test failures easier to diagnose by warning when Chrome cannot be found or does not start correctly. It also cleans up stalled Chrome processes and captures error details, reducing hidden test issues and leftover temporary files on test machines.
Original PR description
If we can't find the devtools port file after 10 seconds we skip the test, however - this is an invisible error because the runbot does not surface skipped tests, so this specific variant should also have a warning (also the skip from not finding a chrome executable) - if chrome started but got stuck before it managed to create the port file we don't `stop` the chromebrowser as it never finished starting, however this means we leave a chrome running in the void a `user_data_dir` littering the machine / vm's tempdir So improve the handling of that bit. Also have chrome write its stderr to a file (in the `user_data_dir`) so we can log that out in case it contains useful information as to why chrome didn't finish booting. While at it backport the spawn changes from #206574 for consistency and simplicity: we don't need to test the platform for every single tour and the indirection makes updating the `Popen` parameters unnecessary complicated. Forward-Port-Of: odoo/odoo#232612
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