Daily updates from Odoo
Friday, February 20, 2026
203 changes
16 changes
Resolved issues and error corrections
A recent update allowed users to confirm dialogs with CTRL+Enter, but this also caused floors to be created twice. This fix prevents the double confirmation by stopping the event propagation, ensuring data integrity and preventing unintended duplicate entries in the restaurant floor management.
Original PR description
For the `TextInputPopup` component a feature was introduced in 2f5c5c15644412cfb6493c661b2f1b927c8cc7e2 that allows the user to confirm the popup by simply clicking enter. The problem is that the dialog itself has a hotkey on "CTRL+Enter" that will also confirm the popup. This means that if a user uses the "CTRL+Enter" hotkey, the popup will be confirmed twice. Steps to reproduce: 1. In restaurant, click the button to add a new floor 2. Write a name for the floor 3. Click "CTRL+Enter" 4. Observe that 2 floors with the given name were created instead of one. The fix: We stop the propagation of the event Task: 4698289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212134
This update corrects a minor issue in the Point of Sale system's testing functionality. The system now correctly uses the 'printer_ip' field instead of the outdated 'epson_printer_ip' field for configuring printers. This ensures consistent and reliable test button operation.
Original PR description
IP address field changed from epson_printer_ip to printer_ip
This update resolves a bug that was causing forum posts to fail to create when the Odoo system was in debug mode. The issue stemmed from incorrect property settings being passed to a key component. By changing 'disabled' to 'isReadOnly', the system now correctly handles forum post creation, ensuring a stable user experience.
Original PR description
Following rewrite in odoo/odoo@33206fd1941ae, this commit update passed props (`disabled` -> `isReadOnly`) to avoid a crash when creating a new forum post while being in debug mode: `OwlError: Invalid props for component 'WebsiteForumTagsWrapper': unknown key 'disabled'` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249477 Forward-Port-Of: odoo/odoo#244063
This update resolves a technical issue that caused email generation to fail when processing multiple equity transactions. The fix corrects a configuration error in the email template, ensuring accurate record context and preventing errors during email creation. This improves the reliability of sending shareholder communications.
Original PR description
## Issue Before This Commit A missing record error occurred during email generation when the number of `equity.transaction` records exceeded the `res.partner` records. ## Cause of the Issue The issue was caused by an incorrect `model_id` configuration in the `equity_shareholder_email_template`. This created a mismatch between the template model and the record context passed to the mail compose wizard, leading to a missing record error during template rendering. ## With This Commit The template `model_id` has been corrected `equity.transaction`. This ensures that the mail compose wizard receives the correct model context and prevents missing record errors during email generation. Steps to reproduce : [Video](https://drive.google.com/file/d/19WXbjmYPKh0IjQHcEGU4FdUbGSF4GGlx/view?usp=drive_link) opw-5899070 Forward-Port-Of: odoo/enterprise#107891
This update resolves an issue where changing a partner in Odoo would erase the previously set default payment term for invoices. Now, the default payment term will remain consistent even after switching partners, ensuring a smoother and more reliable invoicing process. This prevents frustration and maintains data integrity.
Original PR description
When you want to set a default payment term for an invoice, it will be there when you create the invoice. But then, when you change the partner, even if there is no default payment term defined on there, it will empty it, so setting a default does not work. This can even be annoying if you set the payment term first and then the partner. In odoo/odoo#112360 this condition was added for perf issues. opw-5387239 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#242041
This update ensures that when creating transactions (like expenses), the correct company account is used, regardless of the user's main company selection. Previously, transactions were linked to the user's default company, even when processing transactions for a different company. This fix improves data accuracy and consistency across company transactions.
Original PR description
The aim of this commit is to ensure the account select through product is related to the correct company. (ie. the one related to the processed model) Before this commit: If a user has company_a selected as the main company in the company switcher and create an expense for company_b, the account selected from the product will be an account from company_a. (because product is shared between company but the account properties on those are company dependent) This could also happens in other places so we fixed it. After this commit: The account selected from the product will be from the company set on the model. task-4699717 Forward-Port-Of: odoo/odoo#249194 Forward-Port-Of: odoo/odoo#209144
This update resolves an issue where changes made to email marketing records were not being saved when switching between form tabs. The fix ensures that the last edits to the email body are correctly preserved, improving the user experience and preventing data loss. This enhancement provides greater reliability for email marketing campaigns.
Original PR description
Problem: While editing an email marketing record, switching tabs in the form view causes the last changes in the editor to be lost. Cause: The `blur` event on the iframe is not triggered when clicking outside of it. If the iframe is not fully ready when listeners are attached, the required events are not properly registered, so the latest changes are not saved before switching tabs. Solution: Attach the `blur` listener only once the iframe is fully loaded, ensuring that changes are correctly detected and saved when focus is lost. Steps to reproduce: - Create a new email marketing record. - Add a text snippet. - Change the text and save. - Modify the text again. - Switch to another tab in the form view, then return to the "Mail body" tab. - Observe that the last changes are lost. opw-5921800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248974
This update resolves an issue where clicking 'View' on certain activity types (like 'Eat cookies') in the calendar view would cause a technical error. The fix ensures that activities, even those without a linked model, can be properly displayed and accessed, improving user experience.
Original PR description
Steps to reproduce ================= 1. Go to “View all activities”. 2. Switch to calendar view. 3. Click on an activity not linked to any model (e.g. “Eat cookies”, “Send Email to Alfred”). 4. Click…
Steps to reproduce ================= 1. Go to “View all activities”. 2. Switch to calendar view. 3. Click on an activity not linked to any model (e.g. “Eat cookies”, “Send Email to Alfred”). 4. Click “View” in the popover. => Traceback Reason ====== The commit [1] allow activities without a linked model and from commit [2] such activities can be opened in the activity form view. In the calendar view, the action is retrieved from the model and executed using `doAction`. Since the action does not define `views`, and the `doAction` depends on `action['views']`, an error occurs when the action service attempts to copy it. After this commit ================== This commit fixes the issue by modifying the action returned from `action_open_document` for non-linked models to include `views`, similar structure used when a model is present. [1] https://github.com/odoo/odoo/commit/165b060473be8a5d33d62d311f0dc55ed6332d69 [2] https://github.com/odoo/odoo/commit/abeac135b9bb7aec4bcddd84fb0705743297f80d Task-5857887 Forward-Port-Of: odoo/odoo#246442
This update fixes an issue where tables copied from the Knowledge editor were only partially copied, resulting in incomplete table structures when pasted elsewhere. The change ensures that tables are copied fully, providing a consistent and reliable experience for users adding and sharing tables within Knowledge.
Original PR description
Problem: In Knowledge, when adding a clipboard block and inserting a table inside it, clicking on the copy button only copies the text inside the table instead of the full table structure. Cause: In…
Problem: In Knowledge, when adding a clipboard block and inserting a table inside it, clicking on the copy button only copies the text inside the table instead of the full table structure. Cause: In `html_viewer`, the copy logic clones only the deepest selected node. In contrast, `html_editor` (via `clipboard_plugin`) copies the entire selection range. This difference causes inconsistent behavior between editable and locked content. Solution: Align the behavior by copying the full selection in `html_viewer`, ensuring tables and other complex structures are copied entirely and consistently. Steps to reproduce: - Open Knowledge. - Add a clipboard block. - Insert a table inside the block. - Lock the content. - Click the copy button. - Paste into any editable field. - Observe that only the text (not the table) is pasted. opw-5476320 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248213 Forward-Port-Of: odoo/odoo#247930
This update corrects a bug where vertical videos would lose their orientation after a page was saved and reloaded. The fix ensures that vertical video settings are properly preserved, maintaining the intended layout for users. This improves the visual consistency of video content on our website.
Original PR description
Problem: When setting a video to vertical and saving the page, the alignment is not preserved after reload. Cause: `generateVideoIframe` always sets the `media_iframe_video_size` class, even for vertical videos. As a result, the vertical configuration is lost after saving. Solution: Apply `media_iframe_video_size_for_vertical` when the video is marked as vertical, so the correct layout is preserved after saving. Steps to reproduce: - Drop a Video snippet on a page. - In the selector, enable the vertical option. - Add the video. - Save the page. - Observe that the video is no longer vertical. opw-5941900 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249335
A bug was causing the total time displayed in the Timesheet list view to be formatted incorrectly after a page refresh. This update ensures the total is always displayed as a time value, regardless of whether the user is viewing the data in a grid or list format. This improves the accuracy and usability of the Timesheet reporting feature.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget…
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954 Forward-Port-Of: odoo/enterprise#107203 Forward-Port-Of: odoo/enterprise#107006
This update resolves a technical issue within the Lu payroll module that was causing incorrect calculations for employee pay. The fix ensures accurate payroll processing, maintaining the integrity of financial data. This change primarily impacts payroll reporting and employee compensation.
Original PR description
Forward-Port-Of: odoo/enterprise#107635
The AI translation feature in the website builder was experiencing timeouts, preventing users from translating large amounts of text. This update removes the timeout restriction, allowing translations to complete successfully even with extensive or complex content. This improves the user experience and ensures accurate translations for our website.
Original PR description
Scenario: - have lot of untranslated text in a page - in a secondary language, open translation editor - click on "Translate to [current language]" in side panel Result: the translation fails completely or partially, and there is a notification saying "A technical issue occurred in the builder, you should save or discard your changes.". Reason: since 6df83abb35c95ab42e55d9a08cf6c411efa64b3e website builder action have a default timeout of 10 seconds to prevent deadlocks. But the /html_editor/generate_text can easily take more than 10 secondes depending on latency and quantity of text to translate. Fix: prevent the timeout when using the AI translation feature. opw-5892402 Forward-Port-Of: odoo/odoo#249464
This update resolves an issue where the expense report generation process would fail when encountering encrypted PDF attachments. The fix skips these encrypted files, preventing errors and ensuring reports can be created successfully. This improves the reliability of expense reporting for users.
Original PR description
**Steps to reproduce:** - Install hr_expense - Create an expense - Attach several receipts with at least one encrypted PDF - Create Report - From cog menu, print "Expenses Report" **Issue:** A traceback is raised while trying to add the attachments to the report: 1) With a version of PyPDF2 lower than 2.12.1 (e.g. 1.26.0), a PdfReadError is raised: "File has not been decrypted". 2) With version 2.12.1 of PyPDF2, if PyCryptodome library is not installed, a DependencyError is raised: "PyCryptodome is required for AES algorithm". **Cause:** The encrypted file cannot be appended to the report PDF. **Solution:** Skip encrypted files and log a note with the reason in the report. opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249365 Forward-Port-Of: odoo/odoo#248869
This update clarifies the label for the 'Remove from Bookmarks' action within the Discuss app. By capitalizing 'Bookmarks,' the change aligns with existing labels and improves user understanding of this specific action. This ensures consistency and reduces potential confusion for users.
Original PR description
Backport of https://github.com/odoo/odoo/pull/249454 Use capital letter for "Bookmarks" in this label, for consistency with labels of other actions but also to make it clearer this is related to the "Bookmarks" item in Discuss app. Before / After <img width="212" height="226" alt="Screenshot 2026-02-19 at 12 40 06" src="https://github.com/user-attachments/assets/28f8777e-521f-4ce5-ac07-2c8ff19539d2" /> <img width="211" height="230" alt="Screenshot 2026-02-19 at 12 40 24" src="https://github.com/user-attachments/assets/fa6168ef-7128-42a0-a2eb-d94bf381db5f" />
This update resolves issues with the website builder's option folding and overlay behavior. Specifically, it fixes a bug where the last group of options wasn't unfolding correctly and addressed overlapping hover overlays, ensuring a smoother and more reliable user experience. These changes improve the overall usability of the website builder.
Original PR description
### [FIX] website: avoid empty option for grid Commit 64d35ccd6fade9e0473686b8484f561b5f4215ce added folding for groups of options, and folds them automatically, except the last group. But in some…
### [FIX] website: avoid empty option for grid Commit 64d35ccd6fade9e0473686b8484f561b5f4215ce added folding for groups of options, and folds them automatically, except the last group. But in some cases, the last container with options did not have any options displayed, and thus the last group shown was not unfolded. This commit fixes the issue for the case it was found by avoiding having the option completely (instead of having it, but being empty), by changing the selector. Steps to reproduce: - Open website builder on `/jobs` - Click on the bottom of the right column - Bug: the last group is not unfolded task-5946692 ### [FIX] html_builder: avoid hover overlay on top of active overlay Commit 53ae0a9f646808632ca1ca396466e1c0bb5a73c7 adds overlays on hover on elements with option. But it showed it also when there is already another active overlay, which preventing correct dragging of handles and caused an ugly color. This commit avoid showing the hover overlay if there is another overlay active for that element. Steps to reproduce: - Open website builder - Drop the `s_banner` snippet - Click on the column with text - Drag a handle to resize it - Bug: the overlay does not moved when dragged (the column is correctly resized) - Open website builder - Drop the `s_banner` snippet - Click on the column with text - Move the cursor a bit (stay inside the column) - Bug: The hover overlay is shown in addition to the "resize" overlay task-5946671 ### [FIX] html_builder: keep oberver of overlays when removing hover one Commit 53ae0a9f646808632ca1ca396466e1c0bb5a73c7 adds overlays on hover on elements with option. To adapt the size, it adds them to the resize observer with the other overlay. But when the hover overlay is removed, it removed the element from the observer even if it was also used for another overlay. This commit only removes the element targetted by the hover overlay from the observer if there is no other overlays for that same element. There is no issues the other way because the hover overlay disappears for any action that would remove the other overlays. Steps to reproduce: - Open website builder - Click on the "Contact Us" button in the header - Click in the blank space in the sidebar - Press `escape` - Bug: The overlay moves away from the button task-5942812 ### [FIX] html_builder: refresh overlays when document resizes When the iframe is resized because the user opens the builder, or hides the sidebar, the overlays were not always correctly following the elements which they were targetting. This commit adds a resize observer on the document. This observer makes the listener for `resize` events and implementation of `on_mobile_preview_clicked` both redundant, thus they are removed. Steps to reproduce: - Open the website builder while moving the pointer over a column in the footer - Bug: the hover overlay moves not following the column - Find (or create) a page with no options on any element covering the whole page, but with elements with options, whose size are not affected by the size of the page. - Open website builder - Click on the element with the option - Click in the blank space in the sidebar - Press `escape` - Bug: The overlay moves away from the element task-5942812
28 changes
Resolved issues and error corrections
This update optimizes the master production schedule to significantly reduce order processing times. The previous system was pulling unnecessary data, leading to delays. This change improves efficiency and responsiveness for order fulfillment.
Original PR description
When traversing X2many fields (bom_ids, bom_line_ids) during prefetching in filtered, the _prefetch_ids data grew excessively. Prefetching bom lines pulled in IDs for lines belonging to all boms across all associated products, even though _skip_bom_line in this case only operates on the current product's context. Use prefetch() with no args to avoiding unnecessary record loading for unrelated boms. Benchmark: | |Before |After| |-----------------|-------|-----| |action_replenish |Timeout|577ms| Related ticket: opw-5928055
A recent update allowed users to confirm dialogs with CTRL+Enter, but this caused a double confirmation issue. This fix prevents the dialog from being confirmed twice, ensuring that only one floor is created when a user uses CTRL+Enter. This resolves a data inconsistency issue.
Original PR description
For the `TextInputPopup` component a feature was introduced in 2f5c5c15644412cfb6493c661b2f1b927c8cc7e2 that allows the user to confirm the popup by simply clicking enter. The problem is that the dialog itself has a hotkey on "CTRL+Enter" that will also confirm the popup. This means that if a user uses the "CTRL+Enter" hotkey, the popup will be confirmed twice. Steps to reproduce: 1. In restaurant, click the button to add a new floor 2. Write a name for the floor 3. Click "CTRL+Enter" 4. Observe that 2 floors with the given name were created instead of one. The fix: We stop the propagation of the event Task: 4698289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212134
This update resolves a technical issue within the Luembourg payroll module that was causing incorrect calculations for employee pay. The fix ensures accurate payroll processing, maintaining data integrity and compliance. This change primarily impacts payroll reporting and employee compensation.
Original PR description
Forward-Port-Of: odoo/enterprise#107635
This update automatically calculates and transmits the 2050 pension contribution for employees in Switzerland using the Swissdec standard. This ensures accurate and compliant payroll processing, addressing a previous calculation error and streamlining the process for our Swiss clients.
Original PR description
task-5166226 Forward-Port-Of: odoo/enterprise#104140 Forward-Port-Of: odoo/enterprise#103453
This update fixes a potential issue in Australian payroll tax calculations by ensuring that historical data is used, not current employee settings. Previously, tax calculations relied on the employee's current information, which could lead to inaccuracies when an employee's details changed. Now, payslips correctly reference the historical configuration data for each pay period, guaranteeing accurate tax and withholding calculations.
Original PR description
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields…
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values. This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state). This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period. The following rules/fields are updated to use the version object: - Tax Treatment Category - Additional Withholding Amount - Extra Pay - TFN Declaration - Medicare (Reduction, Exemption, and Levy) - Training Loans - NAT 3093 Amount (Tax Offset) - Child Support (Garnishee and Deduction) A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates. Task-5002697 Forward-Port-Of: odoo/enterprise#107568 Forward-Port-Of: odoo/enterprise#106550
This update corrects a bug where snippet placement within the Forum editor was unreliable. The fix ensures that dropzones are correctly activated based on the selected snippet, resolving issues where snippets were incorrectly available or unavailable due to sanitization rules. This improves the user experience and allows for consistent snippet integration within Forum content.
Original PR description
Before this commit, the dropzones activated would not always be correct clicked on a group and then selected a snippet. The dropzones would be determined based on a default section and not based on the selected snippet. Therefore, even though there could be rules preventing a snippet from behing in a certain dropzone, the dropzone would still be activated because the snippet chosen would not be taken into account. This commit fixes the issue by using the chosen snippet to activate the dropzones. task-5428387 Forward-Port-Of: odoo/odoo#240547
This update resolves an issue where the 'Expenses Report' feature in the HR module would fail when encountering encrypted PDF attachments. The fix skips these encrypted files and adds a note to the report, ensuring reports can be generated without errors. This improves the reliability of expense reporting.
Original PR description
**Steps to reproduce:** - Install hr_expense - Create an expense - Attach several receipts with at least one encrypted PDF - Create Report - From cog menu, print "Expenses Report" **Issue:** A traceback is raised while trying to add the attachments to the report: "File has not been decrypted". **Cause:** The encrypted file cannot be appended to the report PDF. **Solution:** Skip encrypted files and log a note with the reason in the report. opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249365 Forward-Port-Of: odoo/odoo#248869
This update corrects a visual bug in the HTML editor where the cursor placement after using backspace was incorrect. Specifically, after backspace, text was inserted after the button instead of within it. This fix ensures the cursor behaves as expected, improving the user experience when editing text within the editor.
Original PR description
When using backspace after a button, the cursor is visually displayed as being inside the button, but it a character is typed, it is inserted after the button, while it should be inside. What actually happens is that after backspace after a button, the selection is set around the FEFF that follows the button. This commit fixes this by putting the selection before the FEFF inside the button instead. Steps to reproduce: - Go to a "To do" note - Insert a button - Insert text after the button - Put cursor before text after button - Press backspace: the cursor is displayed inside the button - Type a letter => The letter was inserted after the button. task-5928806 Forward-Port-Of: odoo/odoo#249285 Forward-Port-Of: odoo/odoo#248179
This update resolves an issue where imported vendor bills with a product price of $0.00 were incorrectly increasing the total price due to floating-point calculation errors. The fix ensures that the product price remains accurate, aligning the Odoo total with the original XML invoice total. This prevents overcharging and maintains data integrity.
Original PR description
Whenever a line with price `0.0` with `AllowanceCharge`s got imported, Odoo used to update the `price_unit` to the sum of price, allowance and charges, because of a wrong float comparison condition between this sum and the XML total. So the product price was increased, but the allowances were maintained. The total imported in Odoo became double the one in the XML. Step to reproduce: - Import vendor bill from XML with a product: - price: `0.00` - quantity: `1` - an AllowanceCharge, amount: `0.2` - an AllowanceCharge, amount: `0.1` - `0.0 + 0.2 + 0.1 (sum of price and allowances) != 0.3 (subtotal)` (but `float_compare(0.1 + 0.2, 0.3, precision_digits=4) == 0`) - `price_unit` is updated to `0.3` - Total in Odoo is `0.6` Ticket [link](https://www.odoo.com/odoo/project.task/5499525) opw-5499525 Forward-Port-Of: odoo/odoo#249357 Forward-Port-Of: odoo/odoo#248043
A previous error during the Payroll data update process has been fixed. This issue occurred because a necessary file was accidentally removed, causing the system to fail. This update ensures the Payroll data is correctly refreshed after module installation.
Original PR description
When the ``Payroll: Update data`` cron is executed after installing the ``l10n_lu_hr_payroll`` module, a traceback is raised. Steps to reproduce the error: - Install ``l10n_lu_hr_payroll`` module - Run the ``Payroll: Update data`` cron Traceback: ```py FileNotFoundError: [Errno 2] No such file or directory: '/home/odoo/src/enterprise/saas-19.1/l10n_lu_hr_payroll/data/hr_payslip_input_type_data.xml' ``` In commit [1], ``hr_payslip_input_type_data.xml`` file was removed. However, it is still being referenced in the code below here. https://github.com/odoo/enterprise/blob/4174108cb98a9fd84a012ff9dca81ae322c5f338/l10n_lu_hr_payroll/models/hr_payslip.py#L209 As a result, when the ``Payroll: Update data`` cron runs, the system attempts to update a file that no longer exists, causing a FileNotFoundError. [1]: https://github.com/odoo/enterprise/commit/0fecd57652c8c72a4fb91d44bd0c5d75f621541a sentry-7278209115
This update resolves an issue where printing Italian fiscal receipts was failing due to a missing currency setting in the order. The fix ensures the ticket is printed only after the order has been fully synced, guaranteeing the correct currency information is available. This prevents printing errors and ensures accurate fiscal receipts for Italian POS users.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem that prevented Italian fiscal printers from working correctly. The fix ensures the order's currency information is properly synced before printing the receipt, guaranteeing accurate and reliable printing for Italian businesses using Odoo Enterprise.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced.
This update resolves an issue where demo data in the Project module created duplicate personal stages (like Inbox) when new tasks were created. The fix ensures personal stages are loaded before tasks are assigned, preventing this duplication and improving the consistency of demo data. This ensures a better experience for users testing the Project module.
Original PR description
Steps to reproduce: -- 1. Install the Project module with demo data enabled. 2. Create a new private task. Issue: -- The personal stages (Inbox, Today, This Week, etc.) are duplicated. Cause: -- In project_demo.xml, some tasks assigned to users (introduced in https://github.com/odoo/odoo/pull/224307) were defined before the personal stage records. Creating these tasks triggered the automatic stage generation logic (_populate_missing_personal_stages) because the personal stages in demo data were not loaded yet. This resulted in a duplicate set of stages being created once the demo data records were processed. Fix: -- The personal stage definitions in project_demo.xml have been moved higher up in the file so they load before any user is assigned to a task. task-5454658
This update adds a back button to the combo product configuration screen, making it easier for users to navigate and adjust settings. The change also improves the readability of the code. This enhancement streamlines the user experience for managing product attributes.
Original PR description
The goal of this pr was to always have a Back button visible on the combo product configuration. I also change method name to be more readable. task: 5877219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245870
This update ensures payslips display the employee's actual start date with the company, rather than the contract's start date. This corrects inaccuracies when employees transition between roles or contracts within the organization, providing a more reliable and accurate record of their employment history.
Original PR description
In the paysplip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Here we create a new function, similar to _get_first_version_date() which returns the beginning of the contract tied to the first version of the period, instead of the beginning of the version itself, which might be before or after the actual date of the start of the contract. We call this function _get_first_contract_date(). Task: 5909637 Enterprise PR: https://github.com/odoo/enterprise/pull/106692 Forward-Port-Of: odoo/odoo#248598
This update ensures payslips accurately reflect an employee's start date with the company, regardless of internal job changes. Previously, payslips used the current contract's start date, which was inaccurate for long-term employees. This change, primarily impacting payroll in Switzerland and the UAE, provides a more reliable and accurate representation of employee tenure.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598 Forward-Port-Of: odoo/enterprise#106692
This update addresses a bug that prevented users from successfully executing commands (like '/help') within Odoo's AI chat channels. The fix corrects an error where the 'message' data was unexpectedly undefined, ensuring commands now function correctly. This improves the AI chat experience for all users.
Original PR description
When trying to use commands (for example '/help') in 'ai_chat' channels, an error occurrs. This happens because the 'message' returned from Thread.post method is undefined in that case.
This update resolves an issue where users without write access to the `ir.sequence` model would encounter an error when generating serial numbers for manufacturing orders. The change simplifies the serial number generation process by using `sudo()` to increment the sequence, eliminating the need for write permissions.
Original PR description
## Issue When generating a batch of serial numbers, an AccessError is raised if the user does not have the *Write* access on the `ir.sequence` model. ## Steps to reproduce 1. Install *Manufacturing*…
## Issue
When generating a batch of serial numbers, an AccessError is raised if the user does not have the *Write* access on the `ir.sequence` model.
## Steps to reproduce
1. Install *Manufacturing* (`mrp`)
2. In Settings, enable *Lots & Serial Numbers*
3. Create a Product P
- Tracked *By Unique Serial Number*
- Create a BoM for product P
5. As a user without *Write* access on the `ir.sequence` model:
- Create and confirm a Manufacturing Order for product P - Quantity >= 2
- Click *Generate Serial*, *Generate*, *Apply*
6. **An Access Error is displayed, stating that you are not allowed to modify 'Sequence' records.**
## Cause
Commit https://github.com/odoo/odoo/commit/3ff0f2e3ef4f (and https://github.com/odoo/odoo/commit/9cd0c4affeb1) changed the way the serial sequence was updated by replacing `IrSequence.next_by_id()` with manual incrementation (`IrSequence.number_next_actual += 1`). The former method requires read access but does not require write access, whereas the latter does.
https://github.com/odoo/odoo/blob/8f0a5d31d62ea6fc2a1c94be8501735a01323954/odoo/addons/base/models/ir_sequence.py#L272-L275
Since the write access should not be required to generate serial numbers, the sequence is incremented using `sudo()`.
(related to)
opw-5882578
Forward-Port-Of: odoo/odoo#249662This update fixes a bug preventing users from searching the Colombian Daily Journal (Libro Diario) effectively. Previously, report lines were missing key information, resulting in an unusable search bar. The fix ensures all journal entries are searchable by move, partner, account, and label, improving reporting accuracy.
Original PR description
Steps to reproduce: 1. Open the Colombian Daily Journal (Libro Diario). 2. Type a move name or partner in the search bar. 3. Observe that no results are returned. Cause: Report lines were generated with an empty 'name' attribute. The accounting report framework uses this field for client-side filtering. Empty names make the search bar non-functional. Solution: Populate the 'name' field with move, partner, account, and label data. This enables the frontend search bar to match against these strings. opw-5495558 Forward-Port-Of: odoo/enterprise#106179
This update fixes an issue where OCR-extracted expense amounts were incorrectly converting to USD, forcing a 1:1 exchange rate. The change ensures that expenses with foreign currencies are accurately converted to the company's base currency, improving the reliability of financial reporting. This resolves a discrepancy in total amounts displayed for expenses.
Original PR description
Steps to reproduce: 1. Initialize an expense with a foreign currency (e.g., EUR). 2. Trigger OCR extraction on a receipt with a specific total. 3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value. 4. The exchange rate is forced to 1.0, ignoring the system's exchange rate. Cause: The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1. Solution: Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate. opw-5437611 Forward-Port-Of: odoo/enterprise#107862 Forward-Port-Of: odoo/enterprise#107534
This update resolves an issue where the delivery amount was being calculated twice during Stripe express checkout, leading to incorrect order totals. The fix focuses on excluding delivery lines from the tax calculation process, ensuring accurate pricing for customers using express payment methods like Apple Pay or Google Pay. This improves the reliability of the checkout experience.
Original PR description
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay…
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay express checkout but we also reproduced it in google pay) 2- Set fixed price on standard delivery: 10 3- Navigate to website: add a product to cart. Use express checkout. Outcome: The delivery price is calculated twice which is wrong. Cause: --- This regression is due to #238574. Once `/compute_taxes` is called, there is delivery lines included in SO. As a result returning `amount_total` will cause `this.paymentContext['minorAmount']` to include delivery amount. Then we add delivery carrier `minorAmount`: https://github.com/odoo/odoo/blob/469220cde82ecebf4a59451cc1325add6bfc3e69/addons/payment_stripe/static/src/js/express_checkout_form.js#L188-L196 Which cause delivery amount be added twice. Fix: --- We could exclude delivery amount from total amount in `express_checkout_shipping_address_compute_taxes`, which is going to calculate the tax for lines excluding delivery lines. opw-5424398 Forward-Port-Of: odoo/odoo#249340 Forward-Port-Of: odoo/odoo#248415
This update corrects a technical issue where delivery and invoicing addresses weren't being displayed correctly on reports using the 'lines' layout. The fix ensures that address information is now consistently shown, improving the accuracy of reports for customers. This was part of a larger effort to refine the layout and spacing of information blocks.
Original PR description
The `information_block` is always false on the `external_layout_lines` this means that when a delivery address and invoicing address is specified they are not rendered. Reviews the spacing of the bubble layout `information_block` task-5951799 Part of task-5949213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical error where employee and resource IDs were incorrectly mixed during holiday calculations, leading to inaccurate results. The fix ensures that these IDs are correctly distinguished, preventing potential scheduling conflicts and improving the reliability of holiday planning. This change was identified and addressed as a priority.
Original PR description
Employee and resource ids were the same during testing. These were mixed in the function. runbot-240926 Note: https://github.com/odoo/odoo/pull/248661 aims to avoid such errors in the future --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue in how the point-of-sale system handles client payments. Previously, change amounts were always rounded for cash transactions. Now, the system correctly accounts for different payment methods (like cards) and ensures change is accurately calculated, regardless of the payment type. This improves the accuracy of financial reporting within the POS.
Original PR description
We extract the condition into a getter so we can override it elsewhere. For now, it is overriden in `pos_settle_order`. See below for explanation. `change` is the amount we return to the client, so it's in cash, and therefore, we always round it if `cash_rounding` is true. However, in pos_settle_order, when a client 'deposits money', the order `change` is what we get paid by that client, and he might choose a payment method different than cash (card for e.g.). We change the `shouldRoundChange` logic to count for such cases. opw-5222985 Forward-Port-Of: odoo/odoo#248787
This update ensures that the amount due for customer deposits is rounded correctly based on the selected payment method. Previously, rounding was applied regardless of the payment type, leading to inaccurate amounts. This change now respects cash rounding configurations for deposits, ensuring accurate financial reporting.
Original PR description
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the…
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27. 3. Close the session and reopen it, then select that customer, and click settle due 4. Select the Bank payment method, so a NON-Cash payment method. Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27. That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round. The fix ------- Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings. We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method. opw-5222985 Forward-Port-Of: odoo/enterprise#105368 Forward-Port-Of: odoo/enterprise#100278
This update resolves a visual glitch preventing live chat visitors from adding reactions on mobile. The fix removes an outdated override of quick action counts, allowing the emoji picker to display properly. This ensures a smoother and more functional live chat experience for all users.
Original PR description
Before this commit, live chat visitors in mobile could not add a message reaction due to visual glitch. This happens because there's an override in livechat to show 3 quick message actions rather…
Before this commit, live chat visitors in mobile could not add a message reaction due to visual glitch. This happens because there's an override in livechat to show 3 quick message actions rather than 4, and this patch also applies in mobile where there's only 1 with the "..." button. The "Add reaction" message action in mobile, when shown as a quick action, is buggy: click on it glitches the visual of message in a way that disrupt the viewing of message... And this doesn't show the emoji picker. This commit fixes the issue by removing the override of quick action count of live chat visitors. This overrides was added a long time ago when the "Add reaction" and "View reactions" had the same icon, and playing with the amount of quick actions was a way to avoid showing these 2 actions as quick actions with similar icons [1]. Also quick actions in chat window has been tweaked to show 2 actions at most in desktop, which is the best presentation in chat window. Removal of the override let it use this better quick action count. [1]: https://github.com/odoo/odoo/pull/140335 Task-5953287 Before / After <img width="399" height="767" alt="Screenshot 2026-02-19 at 17 41 21" src="https://github.com/user-attachments/assets/4f1fb8e7-fa0b-4c8c-8f41-552432224064" /> <img width="401" height="771" alt="Screenshot 2026-02-19 at 17 56 20" src="https://github.com/user-attachments/assets/5aadc9df-d858-49ec-b894-d2c424396f54" /> Forward-Port-Of: odoo/odoo#249550
The Time Off balance report was incorrectly calculating remaining time off days due to how allocations were aggregated. This fix reorders allocations by their start date to ensure accurate calculations, particularly when employees have multiple allocations across different periods. This ensures the report accurately reflects available time off.
Original PR description
The balance report aggregates allocations regardless of the period in which they occur resulting in wrong information when an employee has two allocations in different periods and a filter is used in the report Steps to reproduce: 1. Install Time Off app 2. Open Time Off app and go to Management > Allocations 3. Create a new allocation of 100 days for employee "Mitchell Admin" of time off type "Paid Time Off" with a validity period from 01/01/2027 to 31/12/2027 and approve it 4. Activate debug mode 5. Go to Time Off > Reporting > Balance 6. The number of days left for "Mitchell Admin" for "Paid Time Off" is 120 days even though the default filter is on the period of 2026 Solution: Refactor the entire query: we order the allocations by date_from so we can subtract taken leaves from the allocations in that order opw-5156142 Forward-Port-Of: odoo/odoo#249512 Forward-Port-Of: odoo/odoo#245860
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. The report templates have been updated to the final 20251210 NT20 taxonomy, ensuring compatibility and accurate data submission.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
4 changes
Resolved issues and error corrections
This update corrects a discrepancy in payslip calculations related to the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves payroll accuracy and reporting.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#107576 Forward-Port-Of: odoo/enterprise#106753
This update resolves an issue preventing early bill printing with the Italian fiscal printer. The fix addresses a traceback caused by incorrect data handling during the printing process, ensuring receipts are now printed correctly when the 'early print' option is enabled. This improves the restaurant's ability to efficiently manage and print customer bills.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#107720
Forward-Port-Of: odoo/enterprise#105511This update fixes a compatibility issue with the Dutch tax (OB) and ICP report templates. It replaces outdated taxonomy data with the final 20251210 NT20 taxonomy, ensuring successful processing of these reports by the Digipoort system. This ensures accurate reporting for Dutch tax compliance.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
This update ensures that timesheet entries with excessively large negative hour values (over six digits) are now properly flagged as errors. Previously, these entries could be added without warning, leading to potential data inaccuracies. This fix maintains data integrity by enforcing consistent hour limits across all timesheet entries.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#106781
17 changes
Resolved issues and error corrections
This update fixes a bug preventing users from searching the Colombian Daily Journal (Libro Diario) effectively. The issue was caused by missing data in the journal entries, which blocked the search function. Now, all journal entries are searchable by move, partner, account, and label.
Original PR description
Steps to reproduce: 1. Open the Colombian Daily Journal (Libro Diario). 2. Type a move name or partner in the search bar. 3. Observe that no results are returned. Cause: Report lines were generated with an empty 'name' attribute. The accounting report framework uses this field for client-side filtering. Empty names make the search bar non-functional. Solution: Populate the 'name' field with move, partner, account, and label data. This enables the frontend search bar to match against these strings. opw-5495558 Forward-Port-Of: odoo/enterprise#106179
This update resolves an issue related to how Odoo handles customizations for UBL (Universal Business Language) invoices. Specifically, it corrects a problem with retrieving customization IDs, ensuring that UBL invoice processing across various international accounting modules (like ANZ, Japan, My, and SG) functions correctly. This ensures accurate invoice generation and compliance with local regulations.
Original PR description
no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249192 Forward-Port-Of: odoo/odoo#248992
This update ensures that invoices generated for Spain (using the facturae module) comply with Spanish tax regulations. Previously, the XML format included excessive decimal places, causing validation errors. This change limits the decimal places to two for EUR invoices, resolving the validation issue and ensuring accurate submission to the Spanish tax authority.
Original PR description
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit…
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost. When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)." According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places. This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies. [1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844 Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf) opw-5927356 Forward-Port-Of: odoo/odoo#248882
This update fixes an error in how holiday pay recovery is calculated for employees in Belgium with non-standard working schedules. Previously, the calculation used a default 38-hour week, leading to inaccurate deductions. Now, the system correctly uses the employee's actual 40-hour week, ensuring accurate holiday pay recovery amounts.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied. Forward-Port-Of: odoo/enterprise#107858 Forward-Port-Of: odoo/enterprise#106205
This update fixes an issue where clicking the 'More options' button in the HTML editor would cause the editor to lose focus. The fix ensures the editor remains focused after the button is clicked, improving the user experience. Additionally, the powerbox filtering now correctly displays commands based on user input.
Original PR description
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: -…
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: - After clicking the power button, the button becomes focused and the editor loses focus. Solution - When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused. **Issue 2:** Steps to reproduce - Click More options in the Power Buttons to open the powerbox. - Start typing `heading`. Description of the issue: - The powerbox does not filter commands and continues to show all commands. Cause: - In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true. - `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`. - Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered. Solution: - Introduced `openSearchPowerbox` in `searchPowerboxPlugin`. - Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`. - Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress. task-5485088 Forward-Port-Of: odoo/odoo#244454
This update resolves an issue where the 'Expenses Report' feature couldn't process receipts with encrypted PDFs. The fix skips these files and logs a note in the report, preventing errors and ensuring all receipts can be included. This improves the reliability of expense reporting.
Original PR description
**Steps to reproduce:** - Install hr_expense - Create an expense - Attach several receipts with at least one encrypted PDF - Create Report - From cog menu, print "Expenses Report" **Issue:** A traceback is raised while trying to add the attachments to the report: 1) With a version of PyPDF2 lower than 2.12.1 (e.g. 1.26.0), a PdfReadError is raised: "File has not been decrypted". 2) With version 2.12.1 of PyPDF2, if PyCryptodome library is not installed, a DependencyError is raised: "PyCryptodome is required for AES algorithm". **Cause:** The encrypted file cannot be appended to the report PDF. **Solution:** Skip encrypted files and log a note with the reason in the report. opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249365 Forward-Port-Of: odoo/odoo#248869
This update corrects a default VAT setting in the Odoo Estonia module to reflect the recent change in Estonian VAT law (24% instead of 22%). This ensures accurate sales and purchase tax calculations for users operating in Estonia. The change was backported from a previous Odoo commit.
Original PR description
Issue: Estonia increased its standard VAT rate from 22% to 24% effective July 1, 2025. Existing Odoo installations and new databases created with older templates still default to the outdated 22%…
Issue: Estonia increased its standard VAT rate from 22% to 24% effective July 1, 2025. Existing Odoo installations and new databases created with older templates still default to the outdated 22% rate for sales and purchases. Steps to Reproduce: 1. Install l10n_ee on a fresh database. 2. Go to Accounting > Configuration > Settings. 3. Observe that the default Sales and Purchase taxes are set to 22%. 4. Create a new product; observe it automatically assigns the 22% tax. Solution: - Updated account.tax-ee.csv to set active=False for 22% tax templates and ensure 24% templates are active. - Modified template_ee.py to update account_sale_tax_id and account_purchase_tax_id to point to the new 24% tax IDs. - Updated EU_TAX_MAP in l10n_eu_oss to reflect the 24% destination rate for Estonia across all EU member states. backport of: https://github.com/odoo/odoo/commit/55e3853313969918005757203fc63ee1bd0a3b43 opw-5407921 Forward-Port-Of: odoo/odoo#249385 Forward-Port-Of: odoo/odoo#248156
This update corrects an issue where pick-up point names and days of the week were incorrectly capitalized in the website's 'Click and Collect' feature, particularly in Dutch. The fix ensures consistent and proper formatting of pick-up point information regardless of the selected language, improving the user experience.
Original PR description
Issue: --- In pick-up point list, the case formatting should be: 1- Pick-up point's `name`, `street` and `city` should not be auto-capitalized. 2- Weekdays should must be always capitalized regardless of language. Steps to reproduce: --- 1- Create a second Company named `store`. 2- Create a wh for the created company and add the wh to click-and-collect pick-up points. (There should be more than 1 pick-up points) 3- In the website, add Dutch lang. 4- In website, open a product and, open the `Click and Collect`. Outcome: --- Name is capitalized to `Store` and the days are not capitalized if you switch to dutch lang. Cause: --- Due to CLDR, luxon doesn't capitalize weekdays in some languages. opw-5941830 Forward-Port-Of: odoo/odoo#249078
This update corrects a discrepancy in how the private car daily allowance is calculated and displayed on payslips. Previously, the displayed amount didn't always match the calculated quantity multiplied by the amount. This change ensures that payslip figures accurately reflect the daily allowance, improving payroll reporting and financial accuracy.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#107576 Forward-Port-Of: odoo/enterprise#106753
This update fixes a bug where inactive accounts were excluded from key financial reports (P&L, Balance Sheet, Accounts Coverage). The change addresses a shift in how Odoo identifies accounts and ensures all accounts, including inactive ones, are accurately reflected in these reports. This improves the reliability of financial reporting.
Original PR description
Purpose: In P&L, Balance Sheet and Accounts Coverage Report, inactive accounts are not considered. Root cause: `deprecated` field on `account.account` is replaced with `active`, and orm search by default returns only active records. Solution: add `active_test=False` in the context. task- 5906024
This update resolves an error that prevented users from setting accounting periods when creating tax returns in Invoicing. The issue stemmed from incorrect module initialization, now corrected to ensure proper onboarding progress tracking. This ensures smooth tax return setup for users.
Original PR description
Currently, an error occurs when a user tries to set the accounting period. **Step to Reproduce:** 1. Install Invoicing without demo data and log-in as a super user. (from v19.0, no need to log-in as super user) 2. Invoicing > Accounting > Tax Returns. 3. Set an Opening Date in the wizard and try to apply the accounting period. **Error:** `ValueError - Expected singleton: onboarding.progress()` **Cause:** PR 1, added `_initiate_account_onboardings()` in the accountant (**accounting**) module. However, the onboarding progress should be initialized in the account (**invoicing**) module. **Fix:** This commit ensures that `_initiate_account_onboardings()` is called from the `account` module instead of the `accountant` module. [1] - odoo/enterprise#101442 Enterprise PR: https://github.com/odoo/enterprise/pull/107476 sentry-7064593163
This update resolves an issue where setting accounting periods for tax returns sometimes failed when the Invoicing module was also installed. The change ensures that a key setup process is consistently executed, improving the reliability of tax return configuration. This aligns with recent community updates.
Original PR description
To align with the changes introduced in **community PR** [1], this commit moves the `_initiate_account_onboardings()` method in the `account` module to ensure it is executed even when Invoicing is installed. [1] - https://github.com/odoo/odoo/pull/248790 sentry-7064593163
This update fixes a visual issue where date picker arrows appeared reversed when the website was displayed in RTL (Right-to-Left) languages like Arabic. The fix ensures that date pickers function correctly regardless of the user's language setting, improving usability for international users. This was achieved by applying the necessary styling to the main container component.
Original PR description
### Steps to reproduce: - Download Rental and eCommerce apps. - Install an RTL language (e.g., Arabic) on the website. - Create a rental and go to website. - Try to pick a date for the rental. ###…
### Steps to reproduce: - Download Rental and eCommerce apps. - Install an RTL language (e.g., Arabic) on the website. - Create a rental and go to website. - Try to pick a date for the rental. ### Issue: When the website is viewed in an RTL language, the navigation arrows of the date picker are displayed in the wrong direction. This happens because the date picker is not inside `o_rtl` component, but inside `o-main-components-container` component. So, when `o_rtl` is called in css (for example): https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/web/static/lib/odoo_ui_icons/style.css#L67-L76 Since the arrows are not inside `o_rtl`, the transformation doesn't apply to them. ### Solution: The `o_rtl` class has been appended to `o-main-components-container` class in case of a RTL language, so that had the css file contain rules for `o_rtl`, they would be applied automatically. opw-5498615 Forward-Port-Of: odoo/odoo#248554 Forward-Port-Of: odoo/odoo#246190
This update ensures the 'Request Signature' menu item consistently appears on form views when a chatter is present. Previously, the system wasn't reliably checking for chatter, leading to the menu item sometimes being missing. This change improves the user experience by guaranteeing the signature option is available where it should be.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423 Forward-Port-Of: odoo/enterprise#97401
This update fixes a technical issue related to invoice generation when using BIS3 files for B2C transactions. Previously, checks for R010/R020 were always performed, even when not needed. This change ensures these checks only occur when PEPPOL data is present, streamlining the process for B2C customers who manually import their invoices.
Original PR description
…peppol checked Some people are using BIS3 files even for B2C. They give the xml files to the accountant for him/her to import the file and generate the invoice in the accounting software. In that case, since it's a B2C transaction, the EndpointId might not be set but that's ok since it's only used to generate the invoice. opw-5952109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249751
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. The report templates have been updated to the final 20251210 NT20 taxonomy, ensuring compatibility and accurate data transmission. This change is critical for compliance with Dutch tax regulations.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
This update ensures that timesheet entries, regardless of whether the hours spent are positive or negative, are limited to a maximum of six digits. Previously, users could enter excessively large negative values without any error message. This fix prevents data inconsistencies and ensures accurate timesheet reporting.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#106781
2 changes
Resolved issues and error corrections
This update fixes a bug preventing users from searching the Colombian Daily Journal (Libro Diario) effectively. The issue was caused by missing data in the journal entries, which blocked the search function. Now, all journal entries are searchable by move, partner, account, and label.
Original PR description
Steps to reproduce: 1. Open the Colombian Daily Journal (Libro Diario). 2. Type a move name or partner in the search bar. 3. Observe that no results are returned. Cause: Report lines were generated with an empty 'name' attribute. The accounting report framework uses this field for client-side filtering. Empty names make the search bar non-functional. Solution: Populate the 'name' field with move, partner, account, and label data. This enables the frontend search bar to match against these strings. opw-5495558 Forward-Port-Of: odoo/enterprise#106179
This update resolves a rounding issue that occasionally occurred when scanning stock barcodes during delivery order processing. Specifically, the system was incorrectly rounding stock quantities, leading to discrepancies in the recorded stock levels. This fix ensures more accurate stock tracking and reduces potential errors in order fulfillment.
Original PR description
To reproduce the issue: - Create a stock quantity of product1 for example of 275.84 kg in PACK1 - Create a delivery order of 3.6 kg - Go to the delivery order on stock barcode - Scan PACK1 - The new line is created as 272.2399999999 Forward-Port-Of: odoo/enterprise#89300
10 changes
Resolved issues and error corrections
This update fixes a technical issue that previously caused errors when closing a Point of Sale (POS) session if the partner's address (street or postal code) was missing. Now, the system gracefully handles these empty address fields, ensuring a smoother POS session closure and preventing disruptions to order processing. This improves the reliability of the German POS certification process.
Original PR description
Before this commit, if a POS order was created with a partner that had an empty street or postal code, the system would raise an error when closing the POS session. opw-5897334 Forward-Port-Of: odoo/enterprise#106300
This update fixes a discrepancy in accounting calculations within the Point of Sale (POS) module for the Mexican tax reporting (l10n_mx_edi_pos) functionality. Previously, the POS was not correctly processing assets, leading to inaccurate amounts compared to calculations performed in Python. This change ensures consistent and accurate financial reporting.
Original PR description
Before this commit, the needed assets were not correctly loaded in the POS, which caused the amounts to be different from the ones computed in python. opw-5935191 Forward-Port-Of: odoo/enterprise#107657
This update addresses a potential issue where global invoices sent from the POS in Mexico could fail to send correctly, leading to duplicate documents being submitted to the SAT portal. Increasing the timeout for communication with the SW sapien system helps ensure these invoices are reliably processed, preventing errors and maintaining compliance. This resolves a reported problem impacting invoice accuracy.
Original PR description
**Fix:** Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again. opw-5347962 Forward-Port-Of: odoo/enterprise#107735
This update removes an unnecessary step in the HR payroll process, streamlining operations and improving performance. Additionally, the commit addresses minor formatting issues identified by a code quality tool, ensuring consistent and maintainable code. This change focuses on internal efficiency within the HR payroll module.
Original PR description
Before this commit, a useless call to `generate_work_entries` was made since the result needs to be assigned to a variable in order to be used. This commit also fixes the 2 ruff formatting warnings in the file (useless import + ambiguous variable name)
This update resolves a bug where the minimum wage warning wasn't displayed correctly for employees without assigned jobs in the Belgian payroll system. The fix removed a redundant condition within the payroll calculation, ensuring the warning appears as expected when a low salary is set for employees lacking a job assignment. This ensures accurate payroll reporting for Belgian companies.
Original PR description
Steps to reproduce: - Open an employee on the Employees app for a Belgian company - On the payroll tab, set the salary to lower than the minimum wage for an employee that has no job - The warning will not show unless the employee has a job set to him Cause of the bug: - Condition inside _compute_l10n_be_is_below_scale function returned false if an employee had no job Fix done: - Removed unneccessary condition task-5424012
This update adjusts how accents are handled in CFDI documents for Mexico, aligning with SAT regulations. Previously, all accents were removed, which was incorrect. Now, users can individually exempt partner records from accent sanitization, ensuring accurate data submission to the tax authority.
Original PR description
An improvement in September (PR #95207) began removing accents from legal names in CFDI documents, since we assume most customers did not include accents in their legal names. However, this change…
An improvement in September (PR #95207) began removing accents from legal names in CFDI documents, since we assume most customers did not include accents in their legal names. However, this change prevented all accents (save `ñ` and `Ñ`) from being sent to the SAT. The SAT does allow accents in legal names. Please refer to [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17 for an example. Because of this, several PRs have been merged to prevent individual accents from being sanitized (PRs #96043, #106557, and #107859). This fix aims to remove these individual exemptions. Instead, individual `res.partner` records can be exempted from accent sanitization entirely through the field `l10n_mx_edi_sanitize_name`. This commit also adds a server action (visible in debug mode) to mass-exempt `res.partner` records from accent sanitization. [opw-5915515](https://www.odoo.com/odoo/project.task/5915515)
This update ensures Odoo's payroll system fully complies with Belgian ONSS (Organisatie voor Sociale Verzekeringen) regulations. It includes improvements to carbon emission calculations, ATN (BIK) car taxes, and employee data tracking, ultimately improving accuracy and adherence to local tax laws.
This update resolves an issue where test runs were repeatedly generating unnecessary assets, slowing down the testing process. By adding a specific asset bundle to the test generation list, we've eliminated this redundancy and significantly improved test performance. This change ensures tests run more efficiently and reliably.
Original PR description
During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot). This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs. Forward-Port-Of: odoo/enterprise#107147
This update clarifies the visibility of specific fields within the Belgian payroll and fleet modules. Previously, generic fields were consolidated across all countries, but this change restores the original design, keeping all BE-specific fiscal logic within the Belgian module. This ensures accurate reporting and compliance for our Belgian clients.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656 Forward-Port-Of: odoo/enterprise#107620 Forward-Port-Of: odoo/enterprise#106456
This update fixes a technical issue in the account return process where incorrect check codes were being processed. The fix ensures that only the intended checks are executed, preventing potential errors and maintaining accurate reporting. While previously shielded by a safeguard, this change reinforces the system's reliability.
Original PR description
the check codes to ignore was wrongly defined, leading to contain records instead of 'code', plus having the exact opposite of what it was supposed to contains, i.e. codes that aren't supposed to be run at the current state of the return. However, it didn't have any impact functionally because it was "protected" by the function _should_run_checks(), which might disapear in the future. Forward-Port-Of: odoo/enterprise#107158
13 changes
Resolved issues and error corrections
This update resolves an issue where color dots weren't appearing on shift previews for employees with flexible schedules. The fix ensures that color dots are consistently displayed when a shift spans multiple days, improving the planning calendar's usability for all employee types.
Original PR description
## Short functional explanation of the error When setting a shift spread on multiple days for an employee who has a flexible schedule and previewing the planning of this employee, on the shown…
## Short functional explanation of the error When setting a shift spread on multiple days for an employee who has a flexible schedule and previewing the planning of this employee, on the shown calendar, the color dot doesn't show. Instead, 'null' appears. ## Reproduction Steps 1. Go to planning and create a shift extended on multiple days for an employee who has a flexible schedule. 2. Click Publish and Send. 3. Click on Actions on the left top side and click Preview. 4. Select the employee you just created the shift for. 5. Click on Preview. 6. It opens a window with the employee's planning. On the left top side, click Month. ### Expected behavior A shift spread on multiple days should show, with a color dot on the left of the schedule. ### Unexpected behavior Null appears instead of the color dot. Moreover, the background of the shift has the color of the color dot that should be there. ## Origin of the issue For employees with specified working schedules, multiple-days shifts are limited to their schedule. Thus, these shifts are split on the working hours of the employee. But flexible employees have no specified working hours, so the shifts aren't split. This creates multiple day slots. FullCalendar generates different html codes for such slots, which don't contain class ```fc-daygrid-event-dot```, responsible for the creation of the color dot next to the shift schedule. However, even if this color dot isn't created, we still mention it here: https://github.com/odoo/enterprise/blob/59cec3e8c6a0880178aa93651dca66c367d36841/planning/static/src/js/planning_calendar_front.js#L116 to display shifts. Therefore, we have to create it if it doesn't exist. __ opw-5437257
This update resolves a bug where a notification was incorrectly triggered every time multiple statement lines were selected for action. The fix ensures that a warning notification is only sent when a reconciled line is selected, improving the user experience and preventing unnecessary alerts.
Original PR description
This commit:https://github.com/odoo/enterprise/commit/fa8fedc4e2501a273e7f8f3f7f4462b2b58907b9 introduced a way to select multiple statement lines and apply an action on it. When selecting a reconciled line, a notification should be sent to warn the user. But for the moment the notification is sent everytime. no task id
This update resolves an issue related to the Belgian payroll reporting of cycle transportation benefits. The changes ensure accurate calculation and declaration of these expenses, aligning with Belgian tax regulations. This fix improves compliance and reduces the risk of errors in payroll processing for employees receiving this benefit.
This update fixes a bug where clicking the header of a manufacturing order (MO) removed the filter applied in the shopfloor search bar. The fix ensures that the filter remains active after interacting with the MO, improving usability and allowing users to efficiently locate work orders.
Original PR description
### Steps to reproduce: - Download MRP app. - Create a product and its corresponding BOM (including at least a single operation) - Create and confirm a manufacturing order for 1 unit of that product…
### Steps to reproduce: - Download MRP app. - Create a product and its corresponding BOM (including at least a single operation) - Create and confirm a manufacturing order for 1 unit of that product - Click on the Shop Floor smart button > Click on the header of the MO - The MO filter applied on the shopfloor search bar is removed ### Issue: The MO search filter is removed after you click the header of the workorder order. This bug was introduced by another commit https://github.com/odoo/enterprise/pull/94584/changes/c83ab24a8d037a339db8067c7e9794cba5c16eab to remove the filter when a workorder's barcode is scanned. Hence, https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L289-L292 the change resulted in the filter being removed every time the header is clicked. In the case where a user clicks to start the workorder, we need to keep the filter. ### Fix: Based on https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L6-L8 `onClickHeader()` is called every time a shopfloor record is clicked, which (based on the reference in the previous section) removes the filter, then calls `startWorking()`. By removing `this.env.searchModel.removeMOFilter()` from this method, it's ensured that clicks preserve the user's current search context. For https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display.js#L248-L250 since the original workflow of removing the filter in case of a barcode scan should be kept, moving `removeMOFilter()` call here with the appropriate reference of `workorder.component.env.searchModel`matches the expected behaviour. opw-5877418
This update resolves an issue where CABA taxes were incorrectly included in tax reports when part of a tax group. The fix ensures that CABA taxes are excluded from reports, preventing duplicated amounts after reconciliation and improving the accuracy of tax reporting. This impacts invoice reporting and financial reconciliation.
Original PR description
How to reproduce: - Create one CABA tax and one normal tax. - Create a tax group containing both taxes. - Create an invoice using this tax group. - In the tax report, the CABA tax appears even when the invoice is unpaid. - After reconciliation, the CABA tax amount is duplicated in the report. When the CABA tax is part of a tax group, it is selected in _read_generic_tax_report_amounts_no_tax_details. Since the tax group has tax_exigibility = 'on_invoice', the CABA tax inside the group is incorrectly included by the query. opw-5468074
This update resolves an issue where Invoicing and Banks users were unable to access certain standard financial reports. The change reverts a previous update that inadvertently granted access, ensuring these groups can now properly view the necessary reports. This improves usability and reporting capabilities for these key user groups.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#107957 Forward-Port-Of: odoo/enterprise#107654
This update fixes an issue where OCR-extracted expense amounts weren't correctly converting to the company's standard currency (USD). The change ensures that the 'Total' amount accurately reflects the receipt's original currency value, improving the reliability of expense reporting. This prevents inaccurate financial data.
Original PR description
Steps to reproduce: 1. Initialize an expense with a foreign currency (e.g., EUR). 2. Trigger OCR extraction on a receipt with a specific total. 3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value. 4. The exchange rate is forced to 1.0, ignoring the system's exchange rate. Cause: The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1. Solution: Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate. opw-5437611 Forward-Port-Of: odoo/enterprise#107862 Forward-Port-Of: odoo/enterprise#107534
This update resolves a problem where CFDI-compliant invoices generated for Mexican companies were producing PDF reports with incorrectly sized section lines. The fix ensures that all invoice details are accurately displayed in the CFDI document, meeting regulatory requirements. This prevents potential issues with invoice acceptance by tax authorities.
Original PR description
**STEP TO REPRODUCE** 1. Select a MX company. 2. Create an invoice for a MX company with a section. 3. Send the invoice via CFDI. 4. Notice the section line in the section pdf is no long enough and does not cover the lines below. opw-5501379
This update fixes a bug preventing users from searching the Colombian Daily Journal (Libro Diario) effectively. The issue was caused by missing data in the search field, which blocked filtering. Now, the search bar correctly displays all journal entries based on move, partner, account, and label information.
Original PR description
Steps to reproduce: 1. Open the Colombian Daily Journal (Libro Diario). 2. Type a move name or partner in the search bar. 3. Observe that no results are returned. Cause: Report lines were generated with an empty 'name' attribute. The accounting report framework uses this field for client-side filtering. Empty names make the search bar non-functional. Solution: Populate the 'name' field with move, partner, account, and label data. This enables the frontend search bar to match against these strings. opw-5495558 Forward-Port-Of: odoo/enterprise#106179
This update resolves an issue where the contract type field was incorrectly displayed in the employee offer view when the Belgium payroll localization was not installed. The fix removes the unnecessary addition of this field, ensuring correct behavior across all Odoo versions. This prevents future conflicts and maintains consistent functionality.
Original PR description
Bug reproduction: Ensure that belgium payroll localization is not installed, go to offer of employee, contract type field is not there. Bug cause: Contract type field does not exist in the model, it was adding to the view by l10n_be_hr_payroll. Bug solution: I added new field contract_type_id to the hr_contract_salary_offer model (to show it on UI). Solved from 17.0 Note: I need to fix after version 19.0, because by starting from 19.0, the Belgium one will try to add the same field to the view again task - 5500488 Forward-Port-Of: odoo/enterprise#107855 Forward-Port-Of: odoo/enterprise#104578
This update resolves a previous issue where multi-action sequences involving document movement often failed due to security restrictions. Now, users can reliably create automation flows that move documents and then trigger subsequent actions, regardless of the final folder location. This enhances the flexibility and usability of Odoo's document management features.
Original PR description
Prior to this commit, creating a multi-action that moved a document to a new folder and immediately triggered another action (e.g., "Create Invoice") often failed. This occurred because the security…
Prior to this commit, creating a multi-action that moved a document to a new folder and immediately triggered another action (e.g., "Create Invoice") often failed. This occurred because the security check required the sub-action to be explicitly embedded (pinned) on the *destination* folder. Since the record was moved during the process, the subsequent action failed the security check on the new folder where it wasn't pinned. This limitation caused confusion for users setting up automation flows, as the intent of the sequence (Move -> Action) was clear and initiated from a valid context (the source folder), but strict per-action security rules blocked execution. This commit improves the `ir.actions.server` execution logic to support this pattern by introducing a context-based security sentinel: 1. Entry Point Validation: When a Documents action (root) is triggered, the system enforces strict security: the action must be explicitly embedded on the record's current folder. 2. Context Inheritance: Once the root action is authorized and begins execution, it sets a secure sentinel in the context. 3. Trusted Execution: Any subsequent sub-actions (children) detect this sentinel and are allowed to run, regardless of the record's current folder location. This ensures that if a user has the right to start the process (the root action), they have the right to complete the defined sequence, even if intermediate steps move the record to a folder where the sub-actions are not explicitly pinned. As a result, the `_can_execute_action_on_records` override in `documents_account` is no longer necessary and has been removed. Tests have been extended in the `documents` and `documents_account` modules to cover these scenarios (using Tags in the `documents` module instead of Accounting-specific models to make the tests generic). A new test file `test_documents_ir_actions_server.py` was created to maintain a clean testing environment, covering nesting, move sequences, and RPC spoofing attempts. Task-5916630
This update corrects a bug in the Enterprise pipeline dashboard that was preventing accurate field matching for one of the key lists. This ensures that data displayed in the dashboard is consistent and reliable, improving sales team visibility and decision-making. The fix addresses a minor issue impacting dashboard accuracy.
Original PR description
…oard Field matching was missing for the list #1 in the pipeline dashboard. Task: 5092979
This update resolves an issue where the FAIA report incorrectly classified partners as suppliers. The change allows a partner to be recognized as both a customer and supplier, particularly when balances are zero, ensuring accurate reporting of financial transactions. This fix addresses a discrepancy related to credit notes and balances.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create…
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924 Forward-Port-Of: odoo/enterprise#106315 Forward-Port-Of: odoo/enterprise#100749
5 changes
Resolved issues and error corrections
This update ensures that Peppol invoices always include the attached PDF document. Previously, sending invoices via Peppol bypassed a process that automatically embedded the PDF, resulting in receivers only receiving the XML data. This fix guarantees compliance and a complete invoice delivery for Peppol transactions.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `accounting_peppol` modules. * Create Belgium company. * Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`. * Create…
**Steps to reproduce:** * Install `Accounting` and `accounting_peppol` modules. * Create Belgium company. * Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`. * Create and post a customer invoice. * Click **Send & Print**. * Select only **Email** and click **Send** to generate the PDF. * Click **Send & Print** again. * Select only **Peppol** (partner configured for Peppol). * Click **Send**. **Observed behavior:** * The invoice is sent via **Peppol**, but the generated UBL XML does **not** contain the embedded PDF. * The receiver gets the XML data without the PDF representation. **Cause:** * When a PDF already exists on the invoice, the send flow skips the document post-processing step to avoid regenerating it. * The PDF embedding into the UBL XML relies on this post-processing step. * Sending via Peppol after emailing the invoice therefore bypasses the PDF embedding logic. **Fix:** * When sending via **Peppol**, detect if a PDF already exists on the invoice. * If so, explicitly post-process the UBL XML to embed the existing PDF before sending. * Ensures the PDF is always included in Peppol messages, regardless of when it was generated. opw-5495465
This update fixes an issue where the system incorrectly predicted taxes on imported invoices. Previously, it relied on customer history, even if the XML invoice contained only one tax rate. Now, the system accurately uses the tax information directly from the imported XML file, ensuring correct tax calculations.
Original PR description
Context: When importing an XML invoice or vendor bill, the tax prediction was based on the customer’s invoice history. Example: if the imported invoice contains an item found in the history with two taxes (6% and 21%), the prediction would return both taxes (6% and 21%), even though only one tax is present in the XML file. The actual tax data present in the imported XML was not taken into account. After this commit, the prediction is more rigorous and correctly relies on the tax information provided in the XML (restricted search domain) task-5503126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246308
This update corrects a rounding issue that occurred when creating credit notes after a purchase made with a card. Previously, the system incorrectly rounded the price, leading to discrepancies. Now, the system ensures accurate pricing is reflected on credit notes, regardless of the original payment method.
Original PR description
**Steps to reproduce:** - Setup a rounding of 0.05 - Add it to the PoS settings, turn on the only for cash setting - Make a purchase for 13.01, pay by card - Go to the backend, we have the correct price of 13.01 - Revert the invoice by making a credit note - The price is only 13.00 and we have a rounding of -0.01 **Why the fix:** When making a credit note, we round the price if we find a rounding method, not taking the **only_round_cash_method** setting into account. After this commit, we now check if the reversed entry (the invoice) has a rounding line. If it does not, we skip the rounding. If a rounding is found on the reversed entry, we still round the current account move. opw-5871514
This update ensures that internal users viewing message links within slides are consistently directed to the backend form view, aligning with other portal documents. Previously, internal users were incorrectly redirected to the public website page. This change maintains a unified user experience across all user types.
Original PR description
Since #202555, a message link in slides redirects internal users to the website page if it's published. To ensure consistency with other documents in the portal, this commit redirects internal users to the backend form view of the slides. Portal and public users continue to be redirected to the published website page.
This update resolves an issue where a payment QR code remained visible on the customer display after an order was completed, requiring manual closure. The fix clears relevant data when an order is finalized, ensuring the QR code disappears automatically. This improves the customer experience and streamlines the checkout process.
Original PR description
Steps: --- - Configure online payment on the POS configuration. - Open a POS session and the customer display. - Add a product and an online payment line. - Validate the order and complete the payment via QR code. Issue: --- - The order is finalized, but the payment QR code remains visible on the customer display. - The QR popup must be closed manually every time. Cause: --- - The customer display popup lifecycle depends on `onlinePaymentData`. - This data was not cleared when the order was finalized. Fix: --- - Clear `onlinePaymentData` when the order is completed. task-5502344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
5 changes
Resolved issues and error corrections
This update resolves an issue where Odoo's expense report PDF generation would fail if the necessary security library (PyCryptodome) wasn't installed. The change ensures that encrypted files are gracefully skipped, preventing errors and allowing users to generate expense reports without needing to install additional software. This improves the reliability of the expense reporting process.
Original PR description
**Issue:** This is a complement to the previous commit: https://github.com/odoo/odoo/commit/2eb12ba5e8055c5a0aa3ab86d0e173b3ca3ff2f0 When using version 2.12.1 of PyPDF2 as required if python version > 3.10, if PyCryptodome library is not installed, a DependencyError will be raised when trying to decrypt the file: "PyCryptodome is required for AES algorithm". opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where helpdesk users with limited access were unable to view tickets due to a restriction on accessing related stock data. The fix adds a necessary permission group to allow read access to the required stock records, ensuring all helpdesk users can properly access and manage tickets.
Original PR description
To reproduce: ============= - install helpdesk_stock - with user having only User rights on helpdesk and nothing on other modules - try to access a ticket -> AccessError Problem: ======== when reading the ticket, the field `suitable_product_ids` is computed, and it requires read access to records the user doesn't have access to, which raises an AccessError. Solution: ========= Add the group `stock.group_stock_user` to the field, so that only users having access can read it. backport of https://github.com/odoo/enterprise/pull/59605 opw-5907657
This update fixes an issue where invoices weren't correctly using product category accounts. Now, Odoo automatically checks the entire category hierarchy (parent to child) to find an available account, ensuring invoices accurately reflect the intended income or expense classification. This improves financial reporting accuracy.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Create a product category hierarchy (grandparent → parent → child). * Set an **income account** on the grandparent category. * Set an…
**Steps to reproduce:** * Install the **Accounting** module. * Create a product category hierarchy (grandparent → parent → child). * Set an **income account** on the grandparent category. * Set an **expense account** on the child category. * Leave the parent category without any accounts. * Create a product assigned to the child category. * Create a customer invoice using this product. **Observed behavior:** * The invoice line uses the **default income account** from settings instead of the grandparent category’s income account. * The category hierarchy is not checked to retrieve parent accounts. **Expected behavior:** * If no account is defined on a category, Odoo should traverse the **parent categories** to find one. * Only if no account exists in the hierarchy should it fall back to journal or default accounts. **Cause:** * Account lookup only checked the **immediate category**. * Parent categories were not considered. **Fix:** * Traverse the product category hierarchy when searching for accounts. * Use the first account found in the parent chain. opw-5869592
This update resolves an issue in version 17.0 where the 'Send via Peppol' option was disabled after sending invoices via email. The previous system prevented the necessary UBL-CII XML file from being generated, blocking Peppol transmission. Now, invoices can be sent via Peppol regardless of whether a PDF was previously generated.
Original PR description
### Issue: In 17.0, the `Send via Peppol` option becomes unavailable after using `Send by email` on an invoice ### Cause: The `Send via Peppol` action depends on the UBL-CII XML file However, the XML…
### Issue: In 17.0, the `Send via Peppol` option becomes unavailable after using `Send by email` on an invoice ### Cause: The `Send via Peppol` action depends on the UBL-CII XML file However, the XML generation was conditioned on the absence of a PDF document After generating the PDF, the invoice was considered as already having all required documents, so no additional EDI documents (including the UBL-CII XML) were generated, which disabled the `Peppol` option ### Note: If the XML was already generated, it should still be possible to `Send via Peppol` However, the XML was not attached because it wasn't generated during Peppol sending This issue is also fixed in this PR ### Steps to reproduce: - Install `l10n_be` and switch to BE Company - Enable Peppol and activate the Demo mode in Settings - Create an invoice for the BE Company - Add any product with a Tax - Confirm -> Send & Print -> Email - Open Send & Print again Before the fix, the `Send via Peppol` option is no longer available opw-5490217
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. It replaces outdated report templates with the final 20251210 NT20 taxonomy, ensuring compliance and accurate data submission.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496