Daily updates from Odoo
Wednesday, April 29, 2026
53 changes · saas-19.3
New functionality added to Odoo
This update integrates AI session data into the live chat functionality. The team added a field to the discuss channel to store AI session information, and updated the tests to ensure this data is correctly managed. This improves the AI-powered features within live chat.
Original PR description
Enterprise PR adds `ai_session_ids` field to `discuss.channel`. This commit adapts the tests that check the content put in the frontend store. Enterprise PR: https://github.com/odoo/enterprise/pull/114472
Enhancements to existing features
This update implements changes required by a new Vietnamese tax regulation (Decree 175/2025) regarding VAT rates on specific goods and services. It allows businesses to generate and export Appendix 142 reports, which are necessary for declaring transactions with the reduced 8% VAT rate. Enterprises meeting specific criteria can now avoid submitting this report.
Original PR description
According to Decree 175/2025/NĐ-CP, an decrease of 2% will be applied to a certain goods and services which has 10% VAT rate (from 10% to 8%) and this will be effective until 12/2026 according to Decision 205/2025/QH15. This decision will be considered after that to decide if 8% VAT rate will be still applied. Appendix 142 report is meant to declare those operations and is only for Purchased and Sold goods with 8% VAT rate. For enterprises which satisfies these two following conditions don't have to submit Appendix 142: + Don't have both input and output invoices related to products & services with applied decreased tax rate (8%) + Only have input but not output invoices related to products & services with applied decreased tax rate (8%) We want to allow users to view and export form 01/GTGT and Appendix 142 with xml format from Odoo. task-5498205
This update simplifies the URLs used to access spreadsheets within Odoo. The previous URLs included a lengthy `sheet_id` parameter, which has been replaced with the shorter `sid` parameter. This change improves URL readability and maintainability.
Original PR description
Current behavior before PR: - The URL used the `sheet_id` parameter, which was unnecessarily long. Desired behavior after PR is merged: - Replace `sheet_id` with `sid` to make the URL more concise and readable. Task: [6171969](https://www.odoo.com/odoo/project.task/6171969) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the URLs used to access spreadsheets within the Odoo Enterprise platform. The previous URLs included a lengthy `sheet_id` parameter, which has been replaced with the shorter `sid` parameter. This change improves URL readability and maintainability.
Original PR description
Current behavior before PR: - The URL used the `sheet_id` parameter, which was unnecessarily long. Desired behavior after PR is merged: - Replace `sheet_id` with `sid` to make the URL more concise and readable. Task: [6171969](https://www.odoo.com/odoo/project.task/6171969)
This update enhances the bank reconciliation process by displaying the analytic distribution of each reconciliation line. This provides users with clearer insight into where funds are allocated, simplifying the reconciliation process and reducing potential errors. The changes were based on existing bank reconciliation components and improved usability.
Original PR description
For automated reco models, we didn't take the amount into account. That means that some lines could have a suggestion of reco model that makes no sense. This commit will allow to show the analytic distribution of a line in the line to reconcile so that it's clear for the user. (Most of the code is taken from the analytic distribution widget and adapted) Also make the popover works on hover task-5733382 Forward-Port-Of: odoo/enterprise#106118
This update enhances the website builder's AI functionality by adding a reliable way to track launched AI chat sessions. Previously, tracking was fragile due to user edits, now the system uses a standardized 'interface_key' to identify the source of AI sessions, enabling features like blocking website iframes. This improves the stability and functionality of the AI builder.
Original PR description
__Before this commit__ The `ai.session` record linked to a `discuss.channel` is not accessible from the frontend. This is a problem for the website builder AI because in some cases we need to know if…
__Before this commit__ The `ai.session` record linked to a `discuss.channel` is not accessible from the frontend. This is a problem for the website builder AI because in some cases we need to know if an AI chat session was launched from the website builder sidebar. For instance, to implement custom behaviors such as blocking the website page iframe while the AI is thinking. As a workaround, we currently check if the channel agent external identifier corresponds to the website builder AI, however this might be edited by the user, which would break the flow. __After this commit__ The inverse field `ai_session_ids` is added to `discuss.channel`. In practice, there might only be a maximum of one `ai.session` linked to a channel, but we keep it plural as a convention for `One2many` fields. Only the `ai.composer` and the `interface_key` linked to the session are put in the store at the moment, but fields can now be easily added if needed. We can now check for the `interface_key` in the frontend to know from which part of the code an AI session was launched. Those models have also been added to the Hoot mock server. The `action_launch_ai_chat` method is added to the `ai.agent` mock model and returns the session and the composer. task-5411100
This update simplifies the asset depreciation views in Odoo Enterprise, making them easier to use. Redundant information has been removed, and the search functionality has been streamlined to focus on key depreciation settings. A default 'Active' filter has been added for clarity.
Original PR description
Simplify the asset depreciation views by removing redundant information and improving usability. The method column is removed from the assets list since it is already included in the depreciation model name. The depreciation model list is cleaned up to show only the model by default, while filters for method, period, and number of depreciations remain available in the search view. A default Active filter is also added to display only active records. task-6128781 Forward-Port-Of: odoo/enterprise#114419
Resolved issues and error corrections
This update ensures that when a company is quickly created through a partner record in the equity module, the system correctly identifies it as a company. Previously, this wasn't happening, leading to incorrect data. The update also includes a minor fix for a typo in view definitions.
Original PR description
The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case. This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views. task-6132343 Forward-Port-Of: odoo/enterprise#114375
This update fixes an issue where the system incorrectly determined if an Italian VAT-registered company was recognized. The previous logic only checked for a 11-character Codice Fiscale, failing to correctly identify companies with longer, country-prefixed codes. This change ensures accurate company status determination based on the CF, preventing incorrect partner classifications.
Original PR description
Since 5d3c73ffd0ad ("derive company status from Codice Fiscale format") is_company is True only when the CF (Codice Fiscale) is exactly 11 chars.
Two issues:
- No @api.depends on l10n_it_codice_fiscale, so editing the CF alone leaves is_company inchanged.
- A country-prefixed CF like "IT14475210960" is 13 chars and silently downgrades the partner to a natural person.
Steps to reproduce:
- On an Italian company partner, set:
VAT = IT14475210960
Codice Fiscale = MRTMTT91D08F205J
- Change the CF to IT11122244544, it will be saved but is_company will
remain False, which is wrong.
opw-6129645
Forward-Port-Of: odoo/odoo#261702A recent update broke the layout of the payment method form in the Safaricom POS module, making it difficult for users to configure payment terminals. This commit resolves the issue by simplifying the view structure, ensuring the form displays correctly and functions as intended. This improves the user experience for configuring Safaricom payment terminals.
Original PR description
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right…
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right column of the form loses all the field labels, making it very difficult to fill out the information to configure a payment terminal. This commit fixes the issue by removing the `group` elements from the view, instead just using the `field` elements directly as is done in other payment terminal modules. Before (Safaricom selected): <img width="678" height="504" alt="image" src="https://github.com/user-attachments/assets/9c41643f-1a98-4e44-9493-f0e6e8161a50" /> Before (Viva selected): <img width="674" height="371" alt="image" src="https://github.com/user-attachments/assets/409f5c7a-da13-4f90-8145-a1ed5d6bbf7f" /> After (Safaricom selected): <img width="674" height="531" alt="image" src="https://github.com/user-attachments/assets/a3118563-39a3-4c41-a807-296e531abe58" /> After (Viva selected): <img width="665" height="447" alt="image" src="https://github.com/user-attachments/assets/51140a28-1fca-4d94-a81e-d45e081024a2" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261746
This update resolves a bug where basic receipts were incorrectly generated in the Point of Sale chatter, even when the feature wasn't enabled. It now ensures basic receipts are only created when the option is specifically selected, preventing duplicate receipt images and streamlining the user experience.
Original PR description
Before this commit: =================== - Basic receipt was generated even when the option was not selected. - Both basic and full receipt images could be generated simultaneously. After this commit: ================== - Basic receipt is generated in chatter only when the option is enabled. - Prevents simultaneous generation of both basic and full receipt images. Task - 6126775 Forward-Port-Of: odoo/odoo#260555
This update resolves a bug that prevented expense card creation when the hr_expense_stripe module was installed without the mail_tracking module. The fix ensures that necessary tracking values are copied, allowing users to successfully process expense cards using Stripe. This improves the reliability of the expense reporting workflow.
Original PR description
In odoo/odoo#235719, the tracking values have been moved to a separate module. Step to reproduce: - Install hr_expense_stripe_demo without mail_tracking (or uninstall it) - Setup the stripe issuing account - Create an employee - Create a card and assign that employee - It will fail with a tracking since `tracking_value_ids` doesn't exist on the message
This update resolves a bug where pasting a list item directly into the HTML editor would cause the main content area of the application to disappear after saving. The fix ensures that newly pasted list items are correctly wrapped within a list container, preventing the browser from incorrectly removing surrounding elements.
Original PR description
Problem: Pasting a `<li>` element inside a header block caused `<main>` and `<footer>` to disappear after saving. The browser's HTML parser ejects everything following an orphaned `<li>` (one without a `<ul>`/`<ol>` parent) out of its ancestor tree. Cause: The root cause was `closestElement(selection.anchorNode, listElementSelector)` finding a `<ul>`/`<ol>` ancestor that was not a direct parent of the insertion point, resulting in a `<li>` being inserted without a wrapping list element. Steps to reproduce: - Copy a `<li>` element and paste it in the Text Element in the header. - Save - `<main>` content disappears from the page. opw-6113857 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260320
This update addresses a visual flicker and occasional failure to apply lists when using the chatter composer. The fix prevents unnecessary processing triggered by a 'blur' event, ensuring lists are consistently applied smoothly. This improves the user experience when formatting text within the chatter.
Original PR description
Problem: When the chatter is open and text is selected, applying a list from the toolbar causes a flicker, and the list is sometimes not applied on the first attempt. Cause: Opening the list dropdown triggers a `blur` event on the `html_editor` field, which calls `getInlinedEditorContent` and duplicates the DOM to perform inlining. This unnecessary processing causes the visual flicker and may interrupt the list application. Solution: Prevent the field from blurring when selecting a list alignment option from the toolbar. Steps to reproduce: - Open a new record. - Open the composer. - Add text and select it. - Apply a list using the toolbar. - Observe that sometimes the list is not applied on the first try and the content briefly flickers. opw-6153261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261476
This update resolves an issue in the Bangladesh localization where an unnecessary expense account was being linked to inventory valuations. Removing this link ensures that inventory accounting aligns with standard Bangladesh practices, preventing unexpected stock variations and improving accuracy.
Original PR description
Issue: The Bangladesh chart template sets account_stock_expense_id on the inventory valuation account. This triggers Stock Variation entries following perpetual continental behavior, which is not expected for Bangladesh localization. Cause: l10n_bd template data explicitly populated `account_stock_expense_id` for account `l10n_bd_100502`. Solution: Remove `account_stock_expense_id` from the Bangladesh account template mapping. opw-5944874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261311
This update fixes an issue where users needed to manually pair Bluetooth devices with their IoT Boxes. The fix addresses a technical problem where the device was forcibly disconnecting Bluetooth connections and failing to register the necessary pairing agent. Now, supported Bluetooth devices automatically connect when they are within range of the IoT Box.
Original PR description
According to the IoT Box documentation written in 10/2019, supported Bluetooth devices should connect automatically whenever they are in range of the IoT Box: https://github.com/odoo/documentation/commit/16f2f26f8ae6d9040195c854da337e0dcbbff955#diff-b5974750d9a7f12db80e4922399a7cacd26228dec979ca0fbb504faac386efc8R27 This behavior had broken at some point, requiring manual pairing via bluetoothctl on the IoT Box to establish a connection. Root causes identified and fixed: - The interface was forcibly disconnecting all already-connected BLE devices at startup, kicking them mid-GATT handshake - No BlueZ pairing agent was registered, causing AuthenticationFailed during the pairing negotiation Automatic connection on proximity is now restored. opw-5473691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259885
This update resolves an issue where the automated reporting cron job for vendor invoices wasn't correctly identifying the target company in multi-company setups. The fix ensures invoices are fetched from the correct company, preventing errors and improving the reliability of the reporting process. This avoids disruptions to invoice reporting.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115350 Forward-Port-Of: odoo/enterprise#113254
A recent change to the Viva payment system in the POS was causing cancellations to fail. This update corrects a technical issue where the cancellation process didn't match the original payment setup, resulting in an error message. Now, cancellations from the POS will function correctly.
Original PR description
Steps to reproduce: 1. Start a Viva payment from the POS 2. Cancel the payment from the POS (not on the terminal) **Expected behaviour:** Payment cancels successfully **Actual behaviour:** Error message "Only cash register that created the transaction can abort it". The fix is to use the same cash register ID in both the payment and the cancellation transactions. The payment cash register ID was originally changed to ensure payments would work in the kiosk, but the cancellation cash register ID was never updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261725
This update resolves a performance issue that caused slowdowns and crashes when working with many2many fields containing a large number of records. The fix replaces a slow search method with a faster one, ensuring smoother operation and preventing UI freezes for users handling extensive datasets.
Original PR description
### Issue before this commit: When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became…
### Issue before this commit: When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became unresponsive or crashed when triggering onchange or compute logic. ### Steps to Reproduce: Create a computed many2many field. Add it to a form view (can be invisible). Populate the related model with a large dataset (20k+ records). Trigger an onchange that recomputes the field. ### Cause of the Issue: In _applyCommands (LINK case), the system checks for existing record IDs using Array.includes(), which has O(n) time complexity. When handling thousands of records, repeated ID lookups using includes() result in O(n²) complexity. ### With This Commit: Replaced Array.includes() with a Set (Set.has()), reducing lookup time to O(1). The set is updated incrementally as new IDs are added, improving overall complexity to O(n) and preventing UI freezes for large datasets. opw-6122024 Forward-Port-Of: odoo/odoo#261319 Forward-Port-Of: odoo/odoo#260993
The Profit and Loss report for French associations was displaying incorrect financial figures due to an error in the report formulas. This update fixes the inverted signs in the report, ensuring accurate calculations and correct totals for association financial reports. This resolves a key issue impacting financial reporting accuracy.
Original PR description
### Issue: The Profit and Loss report for associations shows incorrect values with inverted signs, leading to wrong totals in the final computation ### Cause: In 19.1, a new fiscal localization package for associations as been added In the report `account_financial_report_l10n_fr_cdr_asso`, all formulas in the `Operating income (I)` section are incorrectly inverted The equivalent section in `account_financial_report_l10n_fr_cdr_column_2024` is correct, where accounts are properly inverted in the formulas ### Steps to reproduce: - Install `l10n_fr_reports` - Create and switch to a French company - In Accounting Settings, select the fiscal localization: `France - Associations accounting plan` - Create and confirm an invoice (any amount) - Open `Profit and Loss` and select `Profit and loss account for associations (FR)` Before the fix, the Operating Income (I) is negative opw-6117967 Forward-Port-Of: odoo/enterprise#114414
This update enhances the accuracy of French tax reports sent to authorities by completing XML data and fixing minor bugs. Specifically, it adds necessary fields and tags to ensure compliance and improves data validation for company information, ultimately streamlining the reporting process.
Original PR description
This commit aims to make the xml that we send to aspone for the liasse fiscale is the more complete as possible and to correct some small bugs. - Add missing fields in the reports - Add missing tags in the xml - Add a data validation on company data before exporting the reports - Correct errors in the reports - Add country fields in the reports as many2one task-6128878
This update corrects a bug in the payroll system's calculation of full-time equivalent (FTE) hours. Previously, if an employee worked 0 hours, the FTE calculation was incorrect. This change ensures accurate FTE reporting for all employees, regardless of their worked hours.
Original PR description
Before this commit, the full-time equivalent compute was not taking into account the fact that the total worked hours could be 0.
This update resolves a bug preventing users from correctly setting up Worldline and Axepta payment terminals through the quick setup process. The issue stemmed from an incorrect value being used, which is now corrected to ensure both providers function properly. The update also streamlines the logo images for better consistency.
Original PR description
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal…
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal provider cards, which allow quickly setting up a payment terminal by selecting the brand, the Worldline and Axepta options were both not working. The reason for this is that the `use_payment_terminal` field would be set to `axepta_bnpp`, which isn't a valid value and is only used for the name of the logo image. This commit changes the following: - The Worldline and Axepta BNPP cards now both correctly set `worldline` as the payment provider. - The name of the payment method is now set to either 'Worldine' or 'Axepta BNP Paribas' depending on which card is selected. - The logos for Worldline and BNP Paribas have been combined into one image, reflecting the fact that they are a single selection. The alternative would be to add new logic with a separate image path for these providers, which seemed like overkill for this edge case. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261709
A recent update caused newly added overtime lines on attendance records to disappear. This fix disables the ability to add new overtime lines, resolving the synchronization problem and preventing data loss. This ensures accurate work entry tracking.
Original PR description
Steps to reproduce: - On an attendance with overtime, click the "Add a line" button and add a new overtime line - Refresh the page - The newly added line has disappeared and navigating to work entries causes a traceback How it was fixed: Disabled the ability to add a new overtime line. Task ID: 5899657 Forward-Port-Of: odoo/odoo#261540 Forward-Port-Of: odoo/odoo#248431
This update corrects a bug that was incorrectly generating overtime entries on previous days. The fix adjusts how work entries are regenerated to accurately account for employee timezones, preventing incorrect date calculations and ensuring accurate overtime reporting.
Original PR description
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate…
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate the work entries for the following day of the attendance - A new overtime work entry is generated on the first day. Reason: Because of how regenerating work entries is done, the computed date for searching overtime lines took into account the previous day (i.e. regenerating a work entry for a tuesday in an UTC+1 timezone made it so the starting date was on monday at 23:00:00), and since the _read_group only looked at the date part of the time start without taking into account the hour, it included the overtime of the previous day. How it was fixed: The domain now takes into account the timezone of the employee to generate the domain for the _read_group to ensure the correct day is selected Task ID: 5899657 Forward-Port-Of: odoo/enterprise#115289 Forward-Port-Of: odoo/enterprise#107266
This update resolves an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the system. The fix corrects a technical error related to how the button's functionality was triggered, ensuring it now functions as expected. This improves the user experience when initiating new payroll processes.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770) Forward-Port-Of: odoo/enterprise#114101 Forward-Port-Of: odoo/enterprise#111735
This update resolves an issue where commission calculations were failing for recurring subscription orders due to an empty currency rate table. The fix adds a fallback rate, ensuring commissions are correctly applied when currency rates are not populated, leading to accurate commission payouts for subscription-based sales. This improves the reliability of our commission tracking.
Original PR description
Steps to reproduce: 1- Installed sale_commission_subscription and accounting 2- Go to [Sales -> Commissions -> Commission Plans] 3- Create a new commission plan of type MRR, specify a salesperson and approve 4- Go to Subscriptions app and create a new order with a recurring monthly plan and specify the same salesperson 5- Create an invoice for the order and confirm it 6- Go back to the commission plan and click on the Commissions smart button Issue: Commissions show up as 0 Expected behavior: Should have the corresponding commission based on the rate specified Why this happens: The `res_currency_rate` table is empty by default and only gets populated if you are in a multi-currency environment and sync the rates in the settings or by manually making a currency rate entry. Since the commission calculation depends on this table, it results in 0 rows when joining the sub-query. opw-6108580 Forward-Port-Of: odoo/enterprise#114354
This update fixes an error in how tax returns are calculated for companies with multiple branches. Previously, rounding adjustments were incorrectly applied, leading to inaccurate closing entries. The change ensures accurate tax return calculations by isolating company-specific rounding data.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#115116 Forward-Port-Of: odoo/enterprise#110652
This update corrects a technical issue preventing correct export of HK payroll XML files to the IRD platform. The fix includes adding a required file header encoding and a Byte Order Mark (BOM) to ensure the files are properly formatted and accepted by the IRD system. This ensures accurate reporting for Hong Kong payroll.
Original PR description
Following recent tests, we noticed that the encoding used when exporting our XML files doesn't follow the required format. We noticed two issues during testing: - The IRD platform expects the file to have BOM included. - The encoding in the header must be capitalized. We solve this in this commit by prepending the BOM bytes to the xml bytes; and making sure to capitalize the URF-8 in the header. task-6150470 --- Note: There will be a lot to do during forward ports, as these have changed quite a bit. (XML support for the other file types, and a proper testing file, at least) Forward-Port-Of: odoo/enterprise#115530 Forward-Port-Of: odoo/enterprise#115227
This update corrects a technical issue where styling applied to list views was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list views, improving the consistency and appearance of reports. This resolves a minor visual inconsistency.
Original PR description
The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well. task-6141685 Forward-Port-Of: odoo/enterprise#114903
This update fixes an issue where the product description text area on iOS devices (specifically with Safari) would jump unexpectedly when typing. The root cause was a miscalculation of scroll height within the application's design. This change ensures a smoother and more reliable experience for users adding product descriptions in invoices.
Original PR description
Steps to reproduce ================== - Use an iPad device - Go to accounting - Sales > New - Add the product column in the invoices lines - Add a new line - Select a product - Add a description - press enter a bunch of times => the cursor will end up beneath the virtual keyboard - enter a letter => the textarea jumps above Cause of the issue ================== With Safari, setting a size on the widget root causes the scrollheight to be miscalculated. It doesn't take into account the last empty lines of the textarea. Solution ======== There is actually no need to set an height on the widget root node. opw-5927775 Forward-Port-Of: odoo/odoo#259855
This update fixes an issue where refund orders weren't correctly included when calculating outstanding balances. Now, the system accurately reflects all payments and refunds, ensuring accurate due amounts are displayed and settled, particularly when using 'pay-later' payment methods. This improves the reliability of our POS accounting.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#114143 Forward-Port-Of: odoo/enterprise#107883
Previously, changes to a customer's activity (like notes or tasks) weren't consistently reflected across all views within Odoo. This update corrects a technical error that prevented this synchronization, ensuring all users see the most up-to-date activity information. This improves collaboration and data accuracy.
Original PR description
Since [1], the activity state, which is supposed to be shared accross tab through a broadcast channel, isn't anymore. This PR fixes the responsible typo. [1]: #161286 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#259810 Forward-Port-Of: odoo/odoo#255785
This update resolves a problem where unit prices were not being rounded correctly in Peppol transactions, leading to inaccurate invoice data. This change reverts a previous commit and ensures proper price calculations for Peppol-compliant invoices. It improves the accuracy of financial data for international trade.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. opw-6169870 Forward-Port-Of: odoo/odoo#261941
This pull request addresses an issue with tests related to Mexican electronic invoicing (l10n_mx_edi). It reverts a previous change that introduced errors in how rounding was being tested, ensuring accurate calculations for invoices. This fix improves the reliability of the l10n_mx_edi module.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115611
This update corrects a bug in the employee leave calculation process. Previously, leave time-offs were incorrectly recomputed whenever an employee's version changed, leading to inaccurate data. The fix ensures leave time-offs are calculated based on the correct date range, resolving this issue.
Original PR description
The employee_type_id, job_id and structure_type_id fields on hr.leave were stored related fields pointing to current_version_id. This caused all time offs to be recomputed whenever the employee's current version changed, and stored the current version's values instead of those active at the time of the leave. Replace the related fields with a compute based on date_from, resolving the version active at the leave's start date. task-6175086
This update corrects typos and standardizes wording within the French reporting module (l10n_fr_reports). These changes ensure greater accuracy and consistency in French-language reports, improving the overall user experience for French-speaking customers and internal teams.
Original PR description
Fixes typos and ensures wording consistency No task ID
This update allows accountants to retain important XML files received from KSEF (a Polish tax authority) when processing invoices. Previously, these files were automatically discarded after being used. Now, the XML files are attached to the corresponding invoice, providing a permanent record for compliance and auditing purposes.
Original PR description
Description of the issue this commit addresses: When fetching the bills from ksef, the xml with the data about the move is received, parsed and then discarded but the XML can be required to be kept for longer than ksef keeps it so we are lacking a way for an accountant to download it and store it locally. --- Desired behavior after this commit is merged: When a move is fetched from ksef via an xml file, that file is put as an attachment on the move created with its data. --- task-6076505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259655
This update corrects a bug in the salary configuration process. Previously, payslips were calculated using outdated salary rules if generated on the contract start date, leading to inaccurate net pay figures. Now, payslips are always generated based on the current date, ensuring correct calculations.
Original PR description
When the salary configurator is used, it generate a simulation payslip to know get a net value based on the gross. It should be done at the current date, because if it is at contract_start day, maybe years ago, it'll use wrong salary rules values to compute it Forward-Port-Of: odoo/enterprise#115319
This update fixes a visual issue in the invoice report by adding spacing between the Source Invoice and Reference fields. Previously, long invoice names would overlap, making the report difficult to read. This change ensures a cleaner, more professional presentation of invoice data.
Original PR description
Before this commit: - When the Source Invoice name is too long, it connect with the Reference field due to missing spacing. After this commit: - Added margin (`me-3`) to the Source Invoice block to ensure proper spacing and avoid overlap with the Reference field. task-6074560 | Before | After | |--------|--------| | <img width="801" height="474" alt="image" src="https://github.com/user-attachments/assets/cbef48f8-c37b-4263-8c6f-a6b0de3716b9" /> | <img width="780" height="462" alt="image" src="https://github.com/user-attachments/assets/fa01e0b5-d877-424f-a51f-8da0ce5a6bd5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256641
This update resolves an issue where selling a main asset with a closed child asset resulted in incorrect accounting entries. The fix ensures that only active, non-closed assets are considered during the sale process, preventing double-entry errors and maintaining accurate fixed asset and depreciation calculations. A new test case confirms the resolution.
Original PR description
This commit fixes the double entries created when selling the main asset after disposing the child asset. Previously, the sale of the main asset with a closed child asset created 2 entries which resulted in wrong values in fixed asset, depreciation, and gain accounts. This commit filters the non-closed/non-cancelled assets, while previously it would try to close/sell all assets even if it was already closed/cancelled. Test case added to verify fix. opw-6018649 Forward-Port-Of: odoo/enterprise#115452 Forward-Port-Of: odoo/enterprise#115115
This update fixes an issue where Single Touch Payroll (STP) reports were sometimes missed. The system now uses the payslip's creation date instead of the STP submission date, ensuring all payslips are accurately reported to the ATO, even with delayed payment processing. This improves compliance and data accuracy.
Original PR description
When a payslip is created after the submission of a previous payrun, it should trigger an update event to ensure the missed payslip is reported to the ATO with the totals, including all the slips already paid. It currently uses the submit date of STP to check if it's a missed report. However, sometimes the submit/payment date might be set in the future for a delayed payment of the payrun. In this case, the new payrun should not be considered as a missed payrun as it is still the correct order. This fix uses past payslip dates to check if a payrun is a missed report or not, instead of using the submit/payment date of STP. task-6134865 Forward-Port-Of: odoo/enterprise#114280
This update resolves visual inconsistencies and usability problems within the employee salary management module after a recent change related to benefit configurations. The fix ensures a smoother and more intuitive experience for HR staff when managing employee compensation details. This improves overall efficiency and reduces potential errors.
Original PR description
Task: 6141770
This update adds thorough tests for the new customer rating feature introduced in odoo/enterprise#109696. The tests ensure that rating emails are only sent when appropriate (slot completion or report signing) and that the rating process itself functions correctly. This enhances the reliability and accuracy of customer feedback collection.
Original PR description
This commit adds tests for the customer ratings flow introduced in odoo/enterprise#109696. Specifically, it checks that the customer rating request email is only sent upon completing the slot, or after signing the customer report. It also tests the rating itself. task-6147846
This update prevents portal users from seeing the 'View Timesheets' button on invoices when they lack the necessary permissions. Previously, the system incorrectly displayed the button based on the presence of timesheets linked to the sale order. This fix ensures users only see timesheets they are authorized to view, improving data security and user experience.
Original PR description
sale: add sale order specific hook to extend page values ------ Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values sale_timesheet: hide 'View Timesheets'…
sale: add sale order specific hook to extend page values
------
Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values
sale_timesheet: hide 'View Timesheets' button for users without access
-------
Steps to Reproduce:
-----------------
- Create a product with the invoice policy set to Based on Timesheets
- Enable Project and Tasks on the order.
- Create and confirm a sale order using a portal user.
- Log timesheets on the related task.
- Create an invoice from the sale order.
- Log in as the portal user and open the invoice.
- Click the 'View Timesheets' button.
Issue:
-------------
The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.
Root Cause:
------------
The timesheets are linked to the sale order, so the button appears based on the timesheet_count, but the portal user does not actually have permission to access those timesheets.
Fix:
-----------
We replaced the timesheet_count check with a check that verifies whether the user actually has access to any of the related timesheets.
task-4745519
Forward-Port-Of: odoo/odoo#261859
Forward-Port-Of: odoo/odoo#209552This update resolves a bug where portal users were incorrectly seeing the 'View Timesheets' button, even without the necessary permissions. The fix involved updating a helper method to ensure users only see this button when they have the appropriate access rights. This improves the user experience and prevents unauthorized access.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#115533 Forward-Port-Of: odoo/enterprise#113481
This update resolves a critical bug that prevented the AI chat feature from working correctly alongside the FileViewer. It now correctly passes context information and restores the chat overlay, while also preventing AI actions on video files to avoid errors. This ensures a smoother and more reliable experience for users.
Original PR description
*={ai_documents}
- Fix crash caused by calling `.values()` on `_ai_read()` result (list), now using it correctly.
- Correct context passed from FileViewer in ai_documents when launching AI chat.
- Fix AI chat appearing behind FileViewer by updating outdated CSS selector.
- Prevent AI actions on video files by showing a warning instead of attempting unsupported processing.
Backport PR of https://github.com/odoo/enterprise/pull/113287
task-5955968This update corrects a technical issue where quotation templates created from tasks were incorrectly assigning task IDs to non-product lines (like notes). This prevented proper task completion and could lead to errors. The change ensures that task IDs are only applied to product lines, improving the reliability of task management within quotations.
Original PR description
When a sales order is created from a task, if a template is used, the first line is given a task ID from the context's default_task_id. If this first line were to be a non-product line (section/note), this would still be given a task_id. This is unneeded and can cause issues such as a float precision error when trying to mark the task as done. This change checks to see if the line has a display_type, in which case it will set the task_id to false. Steps to reproduce: 1. Create a new Quotation Template with a single section line 2. Create a new project 3. Open the project settings 4. Enable 'Billable' and 'Extra Quotations' 5. Create a new task 6. Select 'New Quotation' 7. Select the quotation template with just a section 8. Enter customer (to allow saving) 9. There will be a single order line, a section, with a task_id opw-6122235 Forward-Port-Of: odoo/odoo#261298
This update makes the timesheet assistant view more user-friendly by implementing small adjustments for better clarity. These changes enhance the overall experience for users managing their timesheets within the Odoo Enterprise system.
Original PR description
Improve the assistant view with small adjustments to enhance clarity and user‑friendliness. Forward-Port-Of: odoo/enterprise#115288 Forward-Port-Of: odoo/enterprise#114339
This update resolves a bug that prevented the cumulated balance from being correctly calculated when using journal groups in the general ledger. The fix ensures that the system properly handles scenarios where all journals are selected via the filter, leading to accurate balance reporting.
Original PR description
Usually the journal filters doesn't allow the selection of all journals when no journal group is present. However, when a journal group is added, the journal filters allow the selection of all the journal groups to be valid. So, we end up with a filter Journals, with all journals selected but the cumulated balance is not computed. To fix this, if all the journals are selected in the Journals filter, we dont add the journal_ids filter. Step to reproduce: - On any journal, create a journal group - Go to the general ledger - In the Journals filter select "Local Gapp" and the created journal group - Click the journal items button on the line of any account - The cumulated balance will be at 0 even when all the journals are selected. Forward-Port-Of: odoo/enterprise#112943
This update resolves a visual issue where the 'is typing' indicator icon was misaligned in Safari browsers. The fix avoids complex animation techniques within Safari, preventing a technical problem related to CSS rules and `foreignObject`. This ensures consistent display of the typing indicator across all browsers.
Original PR description
Before this commit, "is typing" icon in Safari browser was misplaced with relative to Discuss Avatar image. This happens due to a bug in Safari that affects `foreignObject` with elements that use…
Before this commit, "is typing" icon in Safari browser was misplaced with relative to Discuss Avatar image. This happens due to a bug in Safari that affects `foreignObject` with elements that use some CSS rules, like `opacity`. A prior fix was done to apply on change of opacity with classnames [1], which fixed "offline" icon but is typing still has issues: - change of opacity doesn't use classname, this is coupled to animation frame in CSS - the "is typing" icon uses `filter` and `transform`, both of which are also a problem This commit fixes the issue by not using icon animation for Safari browsers. The rules were mostly used for the animation, and while it's feasible to support the visual in Safari, this would mean a lot of code gymnastic that is not worth supporting this nice-to-have visual. To give an idea of implementation: this would mean a `<g>` for each dot of the typing icon that requires deep integration of `Typing` and `DiscussAvatar` icons, and we should make sure that the styles are applied on the `<g>`. Also a `filter` was used to give better contrast of the typing dot and the green background, notably in dark theme. This is also removed by this commit specifically in Safari, as the technique uses `filter` which causes the bug in Safari. [1]: https://github.com/odoo/odoo/pull/260341 Task-6173311 Before / After <img width="630" height="296" alt="before" src="https://github.com/user-attachments/assets/e600a162-93be-4c11-b5bb-371c01eed773" /> <img width="630" height="298" alt="after" src="https://github.com/user-attachments/assets/36be873a-d24b-49b5-bf1e-e5e462491bde" /> Forward-Port-Of: odoo/odoo#261837
This update corrects a bug in the holiday calculation process. Previously, the system incorrectly used contract start dates instead of version dates, leading to unnecessary recalculations. This change ensures holiday calculations are accurate and efficient, especially when dealing with multiple contract versions.
Original PR description
Currently if we have 2 versions on the same contract dates, we check leaves from the contract_start_date, instead of the version date. Meaning if we only have versions on 1 contract date, we will recalculate ALL the leaves all the time. This should not be the case. Forward-Port-Of: odoo/odoo#261963
This update fixes an issue where the Belgian payroll system incorrectly parsed birthdates when dealing with 'numéros bis' NISS numbers (which have a 20 or 40-month offset). The change normalizes the month value to ensure accurate date calculations and prevents errors in payroll processing.
Original PR description
The NISS month field can be increased by 20 or 40 for "numéros bis". This caused invalid date parsing. Use modulo 20 to normalize the month before constructing the birthday. task-6144297 Forward-Port-Of: odoo/enterprise#114485