Daily updates from Odoo
Friday, February 20, 2026
237 changes
15 changes
New functionality added to Odoo
This update introduces support for JoFotara's Point of Sale system within Odoo. It allows for the generation of UBL invoices and credit notes directly from PoS orders, streamlining the invoicing process for JoFotara users. This enhancement ensures compatibility with their existing system and improves data exchange.
Original PR description
This commit adds support to JoFotara for pos.order model. task-4213323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248269 Forward-Port-Of: odoo/odoo#243844
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
23 changes
New functionality added to Odoo
This update allows administrators to create API keys programmatically, streamlining the process and reducing manual steps. Previously, API keys required interactive creation with a typed password. Now, existing keys can be renewed or replaced automatically, improving efficiency and automation.
Original PR description
Previously, API keys could only be created interactively: the method required an interactive session and a recently typed password. This commit adds a new method on `res.users.apikeys` that allows creating an API key when an existing one is provided. Optionally, in the case of a renewal, the new key can replace the old one, and the provided one is unlinked. Forward-Port-Of: odoo/odoo#246118
Enhancements to existing features
This update allows companies to automatically receive KSeF invoices directly from the tax authority, eliminating the need for traditional paper invoices. This streamlines the invoicing process and ensures legally compliant delivery of sales records. It improves efficiency and reduces manual handling of tax documents.
Original PR description
If a company sell me something, they can send me an invoice. With KSeF, they do not have to send an invoice to me by post or mail - they can send it directly to KSeF. And it is legally delivered to me. Implement fetching bills from KSeF task-5405257 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247812
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
4 changes
Resolved issues and error corrections
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 original receipt total after applying the correct exchange rate, improving the accuracy of expense reporting.
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 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 the search bar from returning results. 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 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#10551119 changes
Enhancements to existing features
This update allows companies to directly send invoices to KSeF for tax purposes, eliminating the need for traditional postal delivery. This streamlines the invoicing process and ensures legally compliant delivery of invoices, simplifying accounting for our users.
Original PR description
If a company sell me something, they can send me an invoice. With KSeF, they do not have to send an invoice to me by post or mail - they can send it directly to KSeF. And it is legally delivered to me. Implement fetching bills from KSeF task-5405257 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247812
Resolved issues and error corrections
A recent update to the Point of Sale system introduced a double confirmation issue when using CTRL+Enter in a popup dialog. This resulted in duplicate entries being created, such as multiple floors. This fix prevents this duplication, ensuring data integrity and accurate record-keeping.
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 an issue where the 'Update Prices' button disappeared after saving a quotation. The fix adds a field to the view that ensures the button remains visible, allowing users to easily adjust prices within the quotation record. This improves the user experience and streamlines the quotation process.
Original PR description
Steps to produce: --- - Install sales module. - Go to Settings and enable Pricelists (make sure we have 2 pricelists so that we able to change the pricelist value in quotation). - Create a new…
Steps to produce: --- - Install sales module. - Go to Settings and enable Pricelists (make sure we have 2 pricelists so that we able to change the pricelist value in quotation). - Create a new quotation > Add a customer and product. - Change the pricelist. - Save the record. Issue: --- - After saving the quotation, the `Update Prices` button becomes invisible. Root cause: --- - The field `show_update_pricelist`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible. - The field is removed from the view in this [commit]. Solution: --- - Added the `show_update_pricelist` field to the view to ensure its value is properly maintained. This allows the `Update Prices` button to remain visible when applicable. [commit]: https://github.com/odoo/odoo/commit/da4b588b272432095f549c012e0a0d7238f00dc0 **Enterprice PR:** https://github.com/odoo/enterprise/pull/107621 opw-5927659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the 'Update Rental Prices' button disappeared after saving a rental order in the Odoo Enterprise system. The fix adds a field to the view that ensures the button remains visible when a rental period is changed and the order is saved. This improves usability for users managing rental agreements.
Original PR description
Steps to produce: --- - Install `sale_renting` module. - Rental > Open any order > Change the rental period. - Save the record. Issue: --- - After saving the order, the `Update Rental Prices` button becomes invisible. Root cause: --- - The field `show_update_duration`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible. - The field is removed from the view in this [commit]. Solution: --- - Added the `show_update_duration` field to the view to ensure its value is properly maintained. This allows the `Update Rental Prices` button to remain visible when applicable. [commit]: https://github.com/odoo/enterprise/commit/b90bbdef10a7a37fb065626ba995811ab388c7a1 opw-5937145 ---
This update fixes an issue where OCR-extracted expense amounts were incorrectly converting to USD, overriding the system's exchange rates. The change ensures that expense amounts are accurately converted to the company's base currency, improving the reliability of financial reporting.
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 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
11 changes
New functionality added to Odoo
This update introduces sample data for the industry_fsm module, specifically focusing on allocated hours and timesheets. This new data will populate the tasks analysis reports, providing a better starting point for understanding project timelines and resource allocation. It's a helpful addition for initial demonstrations and testing.
Original PR description
This commit adds some demo data to the industry_fsm with a focus on adding allocated hours and timesheets in order to populate the tasks analysis. taskid:3514457
This update allows employees to correct inaccurate personal information within the system. Following changes in version 18.0, personal details are now managed through the 'My Preferences' menu. This commit adds two new fields to this menu, ensuring employees can maintain accurate records.
Original PR description
In versions after 18.0, the Personal Info tab on the employee form has been removed for public user, and only a limited set of details is now available under the My Preferences menu. While this keeps the interface minimal, employees should still be able to review and update certain personal details if they are incorrect. This commit adds two payroll-related fields to My Preferences. Related community PR: https://github.com/odoo/odoo/pull/248428 task: 5920455
Enhancements to existing features
This update improves the sales order process by now allowing users to select rental products when adding items outside of the rental app. Previously, this was restricted, creating an inconsistent experience and limiting a common business use case – selling products with rental options. This change enhances usability and flexibility.
Original PR description
When you select a product to add to the sales order outside the rental app, you can't select a product with a rental periodicity set. This is incosistent with the fact that you can sales and subscriptions products from sales, subscriptions, or rental app. It is also not very obvious that setting a rental periodicity will have this behaviour, and it is a valid usecase that you would be selling a product that you also offer for rent. For all these reasons, it is better to show rental products when selecting a product outside the rental app in the sale order. task-5887963
This update optimizes the storage of spreadsheet documents within Odoo, reducing their file size without sacrificing readability. A new feature allows for easy debugging by providing access to both compressed and uncompressed versions of the files. This change improves performance and storage efficiency.
Original PR description
Changing the storage of spreadsheet/dashboards and all other odoo spreadsheet documents to a more compressed version, while staying human readable-ish. Add a way to download the non compressed version of the spreadsheet as well as the compressed version, for debugging purposes. Add an menu to vefity the compression: it will load the spreadsheet multiple times and provide feedback if the compression doesn't work. For now we only store the uncompressed version in the database (like before) Task: 5489478
This update enhances the user experience when viewing VoIP call durations. Call durations are now displayed in a more easily understandable format (e.g., minutes and seconds) within call history and VoIP views. The live in-call timer remains in its current digital format for accurate timing.
Original PR description
Switch call duration displays to a human-readable format in VoIP views and recent history, while keeping the live in-call timer in digital format. task-5951753
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
Features or functions removed from Odoo
This update removes compatibility with an older version of the PyPDF2 library. This change ensures Odoo Enterprise utilizes the latest, more secure PDF handling capabilities. It primarily affects internal processes related to document generation and management within Odoo.
13 changes
New functionality added to Odoo
This update incorporates the National Bank of Kazakhstan as a currency rate provider. This change is necessary to comply with local regulations in Kazakhstan, ensuring Odoo Enterprise meets all legal requirements for financial transactions within that country.
Original PR description
This PR adds the National Bank of Kazakhstan as a provider in order to meet the requirements of the Kazakhstan code. Task-4144725
Enhancements to existing features
This update expands the range of Automatic Value-Added Tax (AVS) deductions within the Odoo Enterprise payroll module. Specifically, five new generic AVS codes have been added to ensure greater flexibility and accuracy in tax calculations for Swiss businesses. A new test has been implemented to verify the correct application of these deductions.
Original PR description
5 more generic AVS is added to l10n_ch_hr_payroll/hr_salary_rule_data and /hr_payroll_input_types. task - 5902593 Forward-Port-Of: odoo/enterprise#106218
Resolved issues and error corrections
This update corrects a bug in the planning Gantt view that was causing inaccurate total hour calculations due to timezone discrepancies. The fix ensures that shift hours are correctly displayed regardless of the employee's timezone, providing more reliable planning data. This improves the accuracy of time tracking and scheduling.
Original PR description
Description: ----------- When viewing planning shifts in the gantt view, the total hours column displayed wrong totals due to timezone misalignment in work interval calculations. Steps to reproduce:…
Description: ----------- When viewing planning shifts in the gantt view, the total hours column displayed wrong totals due to timezone misalignment in work interval calculations. Steps to reproduce: ------------------- 1. Create an employee with a fixed working schedule (e.g., 8am-12pm, 1pm-5pm with 1-hour lunch break) 2. Ensure the employee's timezone differs from UTC (e.g., Europe/Brussels UTC+1) 3. Create a shift for this employee covering their full working day (8am-5pm) 4. Open the planning gantt view and check the total hours column for that day 5. Expected: 8 hours total | Actual: 7 hours total (with hours misaligned by timezone offset) Root Cause: ----------- In version 19.0, `_gantt_progress_bar_resource_id` used `.replace(tzinfo=pytz.UTC)` when building work intervals, which only changes the timezone label without converting the actual time values. This caused a timezone offset mismatch in the frontend's hour-by-hour comparison. Solution: --------- Replace `.replace(tzinfo=pytz.UTC)` with `.astimezone(pytz.UTC)` to properly convert datetime values to UTC before sending to the frontend. opw-5190244
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
10 changes
Enhancements to existing features
This update optimizes the creation of global invoices in the Mexican EDI module. By changing the wizard to a 'TransientModel,' unnecessary data is no longer permanently stored in the database, leading to improved performance and reduced storage usage. This change ensures a smoother and more efficient invoice creation experience.
Original PR description
Change to TransientModel so a wizard is not permanently stored in db when creating a global invoice. Forward-Port-Of: odoo/enterprise#107244
Resolved issues and error corrections
This update corrects a bug that occurred when the 'commercial_partner_id' field was visible in the contact form (often through web_studio). Previously, an error would be triggered when using the autocomplete feature, preventing proper PEPPOL status validation. This change ensures the field is always populated, resolving the error and improving the contact creation process.
Original PR description
Before this commit, when commercial_partner_id is on the view (possible with web_studio), the value by default is False. When the autocomplete widget is used, many fields could be autofilled and raise _onchange_verify_peppol_status, that requires this field. To avoid this issue we review that the value has been filled. Steps to Reproduce: 1. Open the Contacts app 2. Open Studio on the contact form view 3. Add the field commercial_partner_id to the form view (make it visible) 4. Create a new contact 5. Type a name 6. Select a suggestion from the IAP autocomplete 7. An error is raised immediately OPW-[5896847](https://www.odoo.com/odoo/action-4043/5896847) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures shift start and end times automatically align with the selected shift template, even when employees have fixed schedules. Previously, shifts were incorrectly calculating hours based on employee schedules, leading to inaccurate shift durations. This change corrects this behavior, providing more reliable shift planning.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509
This update prevents unnecessary error alerts when the Codabox sync process (CRON) fails due to temporary server issues. This change ensures that the sync process doesn't get disabled prematurely if the servers recover, improving reliability and automation. It addresses a previous issue where frequent errors from CRON jobs would disrupt the process.
Original PR description
In case of a failure/downtime from the IAP/Codabox servers, an error is currently being raised. Although this is useful when manually clicking the Fetch button to see what happens, in the context of a CRON it's much less desirable as multiple failures from a CRON will automatically disable it which is not useful as the servers might be back up later on. Now, instead, we only raise if we're not in a CRON environment. opw-5922549
This update resolves an issue where users in the 'Planning / User' group couldn't take open shifts. The fix ensures that the 'I Take It' button is consistently displayed for this group, allowing them to seamlessly accept shifts within the Planning app. This improves usability for a key group of users.
Original PR description
## Issue In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift. ## Steps to reproduce…
## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.
## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**
When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.
## Cause
The condition for the *I Take It* button to be displayed is the following:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283
The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716
When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636
Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.
opw-5451282This update resolves an issue where the description field in the project form was displaying duplicate content. The root cause was a default field content being incorrectly appended. This change ensures a cleaner and more accurate display of descriptions within project forms, improving the user experience.
Original PR description
Steps to reproduce: =================== 1. Go to website > contact us page 2. Submit a new task with description. 3. View the Description in the project app. -> The description field is already shown in the form by default. You will find another time it is repeated. Cause: ====== The default field content is always appended to the form content. Solution: ========= Avoid adding description to the description field content. opw-5868382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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.
5 changes
Enhancements to existing features
This update simplifies the process of running Odoo tests by introducing a convenient alias for the `--test-tags` command. This change streamlines testing workflows and makes it easier for developers to target specific tests. It's a minor improvement that enhances the overall testing experience.
Original PR description
Backport of https://github.com/odoo/odoo/pull/234287 <img width="408" height="151" alt="image" src="https://github.com/user-attachments/assets/7f22826f-6887-432b-8baf-8a6778b9cadf" />
This update allows accountants to group invoice lines by tax, reducing clutter and improving journal item clarity. The system provides a toggle to easily group or ungroup lines, streamlining the invoice import process and making it more efficient for accounting tasks.
Original PR description
[IMP] account_edi_ubl_cii: (un)group lines by tax
Once an invoice is imported, a server action allows the user to group
lines by tax, and then if the same action is triggered again it will
ungroup all lines from the origin file
This feature is useful because accountants don't always need the
detail of the vendor bills, and also all the lines clutter up the
journal items
task-5047859Resolved 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