Daily updates from Odoo
Friday, February 20, 2026
115 changes
28 changes
Resolved issues and error corrections
This update corrects a problem where the timesheet approval reminder email was sending to an outdated action. The action was updated as part of a recent system change (17.3) to consolidate time tracking actions. This ensures the reminder email functions correctly and reliably.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107440 Forward-Port-Of: odoo/enterprise#107385
This update resolves an issue where test runs were repeatedly generating unnecessary assets, slowing down the testing process. By adding a key asset bundle to the test preparation list, we've eliminated redundant generation, resulting in faster and more reliable test execution. This improves overall development efficiency.
Original PR description
During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot). This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs. Forward-Port-Of: odoo/enterprise#107147
This update resolves an issue where closing a POS session would fail if the partner's address (street or postal code) was missing. Previously, an empty address caused an error, now the system gracefully handles this situation, ensuring POS sessions can be completed without interruption. This improves the reliability of the POS 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 minor error in the account return processing logic. The incorrect configuration of check codes was resolved, preventing potential issues with report generation. While previously shielded by a safeguard, this change ensures consistent and accurate account return processing.
Original PR description
the check codes to ignore was wrongly defined, leading to contain records instead of 'code', plus having the exact opposite of what it was supposed to contains, i.e. codes that aren't supposed to be run at the current state of the return. However, it didn't have any impact functionally because it was "protected" by the function _should_run_checks(), which might disapear in the future. Forward-Port-Of: odoo/enterprise#107158
This update clarifies the visibility of specific fields related to Belgian payroll and fleet within the Odoo Enterprise system. Previously, these fields were inconsistently displayed, and this change ensures they are only visible for Belgian companies, aligning with local tax regulations. This simplifies the system for users outside Belgium while maintaining the necessary functionality within the Belgian context.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656 Forward-Port-Of: odoo/enterprise#107620 Forward-Port-Of: odoo/enterprise#106456
This update fixes a bug that caused errors when trying to view sales order items from projects without a linked customer. The fix prevents the creation of sales orders from these projects, ensuring a smoother user experience. This resolves a technical issue impacting sales order functionality.
Original PR description
Currently, an assertion error is raised when opening "Sales Order Items" from a project without a customer. **Steps to Reproduce:** - Install `sale_project` module with demo data. - Create a new project using "Sale Order" project template. - Do not set a customer on project. - Project > Task (Kanban) > Show _Top Menu_ > Show _Sales Order Items_. - Click "**Sales Order Items**". Video Ref: https://drive.google.com/file/d/1xgYHZBvIt5Ep9Gt-wALGIb9f7mj4NPh_/view?usp=drive_link Error: AssertionError **Cause:** The sale order line depends on `default_partner_id` from the context to create a sale order when none exists. When the project has no customer set, this value is missing, causing an assertion failure. **Fix:** This commit returns the list view of SOLs and disables the creation when no partner is set for the project. sentry-7220116560 Forward-Port-Of: odoo/odoo#246058
This update resolves an issue that occurred when attempting to cancel a Point of Sale (POS) order with no items. The fix ensures the system handles empty orders gracefully, preventing errors and improving the user experience. The button to cancel the order is now disabled when no order lines are present.
Original PR description
Steps: --- - Open a Restaurant session. - Open a table with no order. - Click the control button and click Cancel Order. Issue: --- - A traceback occurs when cancelling an order. Cause: -- - The order is cancelled first, and then `isSelectedLineCombo` tries to access the current order, which is already null. Fix: --- - Safely check for the selected order before accessing combo data. - Disable the Cancel Order button when there are no order lines. task-5934004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248639
This update corrects a display issue with 'float_time' in the MRP module. Previously, the minutes were shown in a less intuitive format. This change ensures a clearer and more standard presentation of time values within the MRP workflow, improving usability for users.
Original PR description
odoo/odoo#240555 has changed the way the float_time widget shows minutes, so we need to adapt. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue with how time is recorded in the MRPO (Manufacturing Resource Planning) work order modules. The system now consistently uses minutes for time fields, ensuring more accurate calculations and reporting. This improves the reliability of production scheduling and cost tracking.
Original PR description
Make sure that time fields in mrp modules are in minutes.
This fix addresses an error that occurred when creating invoices with negative tax percentages. The issue stemmed from a filtering process within the accounting module that resulted in an empty list of tax factors. We've reverted a recent change to avoid this error and ensure invoices can be created correctly with various tax configurations.
Original PR description
Steps to reproduce: - Install `account` module - Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg:…
Steps to reproduce: - Install `account` module - Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg: [Image](https://www.awesomescreenshot.com/image/58851592?key=ce0017bb467a583ad020f33d21d4d8ba)) - Create a Invoice and add tax in move line and save Traceback: `IndexError: list index out of range` We are getting `factors` as empty because `target_factors` from `_add_accounting_data_to_base_line_tax_details` is empty. This happens because, in `tax_reps`, we are filtering repartition lines with a `factor` greater than `0`. However, when the `factor` is less than `0`, `tax_reps` becomes empty, which leads to the error. We are reverting this PR: https://github.com/odoo/odoo/pull/234334 because it prevents the validation error from being raised when there is a negative value in the repartition lines. [factors]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L1641 [tax_reps]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L2429-L2431 sentry-7102210210 Forward-Port-Of: odoo/odoo#249220
This update resolves an issue where PDFs embedded in XML files used to create bills via email aliases weren't correctly attached. The fix clears a specific field when attachments are removed, preventing a misassignment of the PDF to the XML document. This ensures that bills always have the correct associated attachments.
Original PR description
Problem: when a user uploads an XML file containing an embedded PDF to create a bill, the bill is created correctly and the PDF is set as the main attachment. However, when the same XML is used to…
Problem: when a user uploads an XML file containing an embedded PDF to create a bill, the bill is created correctly and the PDF is set as the main attachment. However, when the same XML is used to create a bill via email aliases, the PDF is not set as the bill’s main attachment. Root cause: 1. When an email is received, it's first posted as a message on the bill chatter 2. Posting the email sets its XML as the main attachment of the bill 3. _fix_attachments_on_record from account.document.import.mixin then removes res_id and res_model fields from the XML 4. The PDF is then attached as the main attachment of the bill 5. In documents_account module, when the PDF is set as the main attachment, it mistakenly assigns it as an attachment to the XML document because the XML was assigned as the bill main attachment, resulting in the bill having no attachment actually linked to it. Solution: This commit fixes this issue by clearing the field message_main_attachment_id whenever the attachment in it gets unattached in _fix_attachment_on_record. task-5900088 Forward-Port-Of: odoo/odoo#246991
This update corrects a discrepancy in how time data is handled within the MRP modules. Specifically, it ensures all time fields are recorded in minutes, improving the accuracy and consistency of reporting. The change involves updating widgets and formats to align with the new standard.
Original PR description
Make sure that time fields in mrp modules are in minutes. Add a new widget in mrp_plm for updates on time data types. Replace formatFloatTime by formatDuration.
A recent update caused a crash when users attempted to undo a duplicated list within the spreadsheet feature. This fix ensures that the undo function correctly handles list duplication, preventing unexpected errors and improving the user experience. This resolves a frustrating issue for users working with lists in spreadsheets.
Original PR description
How to reproduce: - insert an odoo list in a spreadsheet - duplicate the list from the sidepanel - undo with Ctrl+z -> crash The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry. Task-5943688 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#249475 Forward-Port-Of: odoo/odoo#248969
This update fixes a technical error that could cause a traceback when opening barcode rule forms within the Stock module. The change removes a dependency on a parent record, ensuring the form loads correctly and preventing disruptions to users. This improves stability and prevents potential data issues.
Original PR description
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type ==…
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type == 'alias') Steps to Reproduce: ========================= - Install the stock module. - Go to Configuration → Barcode Nomenclatures in the Stock app. - Open any Barcode Nomenclature form. - Go to the Rules tab and open a rule (pop-up form view). - Click on the Expand button. - A traceback is raised. Cause of the issue: ========================= The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record is not defined when the rule form view is opened directly (via expand), leading to a traceback. This happens because the form view is not defined as a child of any parent view, so no parent context is available, which leads to a traceback. With This Commit: ========================= Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature` directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a related field to `barcode.nomenclature`, so it can be safely used without relying on the parent. opw-5949083 Forward-Port-Of: odoo/odoo#249293
This update resolves a connection issue that occurred when Odoo was configured to use a replica database. The change ensures Odoo automatically uses the primary database port when a replica port isn't specified, preventing connection errors and improving overall stability. This enhances the reliability of the Odoo system.
Original PR description
Start postgres on an alternative port (e.g. 5434), start odoo with `--db_port 5434 --db_replica_host=''`, access /web/database/manager, there's a warning in the logs that says it is not possible to connect to the replica database.
The empty string for the replica host is Odoo 18 way to tell Odoo to simulate a replica database by connecting to the same db as the primary one. It should use `--db_replica_port` and when not set fallback on the same port as `--db_port`. The problem is that in case no `--db_replica_port` is set, the option is set `None` in the config, i.e. `get('db_replica_port', cfg)` was retuning `None` as was not using the fallback.
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#249291This update resolves an issue where tests were failing due to unexpected behavior when handling JSON responses. The fix ensures that test responses are correctly formatted as recordsets, preventing errors in the automated testing process. This improves the reliability of our test suite.
Original PR description
The return value of the patched methods was a MagicMock and not a recordset, and make_json_response was doing funny stuff with that returned MagicMock 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#249496
This update adjusts the size of the 'RedirectWarningDialog' in the Odoo web interface. Previously, the dialog was unnecessarily large, which negatively impacted the user experience. This change ensures the dialog is appropriately sized for its content, creating a cleaner and more user-friendly interface.
Original PR description
Currently `RedirectWarningDialog` are using `xl` size which is way too big for the content it displays. Dialog sizes were reviewed in commit[1], the RedirectWarning should follow the same styling. task-5477287 [1]: odoo/odoo@01741aa2619998078bd19aca848146ac75c027fc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249235
This update fixes an issue where users could accidentally select multiple accounts during the online synchronization process. The change adds a 'disable' feature, ensuring only one account can be selected at a time, improving data accuracy and streamlining the synchronization workflow. This enhances the reliability of our cloud accounting service.
Original PR description
Before this commit, it was possible to click on multiple card when doing the account selection from the wizard. This commit will add a disable feature so that when clicking on the card, other account cannot be clicked. task-5943474 Forward-Port-Of: odoo/enterprise#107637
This update adds a warning message in the batch wizard to alert users if the automated invoice sending cron job is disabled. This ensures users are aware that their invoices may not be sent as scheduled, preventing potential delays and improving invoice processing transparency. It addresses feedback from SBR to enhance user experience.
Original PR description
When the Cron responsible of sending the invoices asynchronously is disabled, the user has no clear indication that his invoices won't be sent as they should. Let's add a warning in the batch wizard that notify the user something is wrong. task-none (feedback from SBR) Message when no rights to update cron: <img width="990" height="328" alt="image" src="https://github.com/user-attachments/assets/1100ef6f-d047-49f2-bd8f-c8ef9fd543d8" /> Message when admin: <img width="999" height="308" alt="image" src="https://github.com/user-attachments/assets/28e90295-d225-4785-82a9-65be3ce79621" /> Forward-Port-Of: odoo/odoo#249270 Forward-Port-Of: odoo/odoo#248994
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 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 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
25 changes
Resolved issues and error corrections
This update resolves a connection issue that occurred when Odoo was configured to use a replica database. The change ensures Odoo automatically uses the primary database port when a replica port isn't specified, preventing errors and improving database connection stability. This enhances the overall reliability of the Odoo system.
Original PR description
Start postgres on an alternative port (e.g. 5434), start odoo with `--db_port 5434 --db_replica_host=''`, access /web/database/manager, there's a warning in the logs that says it is not possible to connect to the replica database.
The empty string for the replica host is Odoo 18 way to tell Odoo to simulate a replica database by connecting to the same db as the primary one. It should use `--db_replica_port` and when not set fallback on the same port as `--db_port`. The problem is that in case no `--db_replica_port` is set, the option is set `None` in the config, i.e. `get('db_replica_port', cfg)` was retuning `None` as was not using the fallback.
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#249291This update corrects a problem where the timesheet approval reminder email was sending to an outdated action. The action was updated to reflect a recent change in how timesheet validation is handled within the Odoo system. This ensures the email reminders function correctly.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107440 Forward-Port-Of: odoo/enterprise#107385
This update corrects a bug where PDFs attached to bills created via email aliases weren't correctly linked. The fix clears a key field when an attachment is removed, preventing misassignment of attachments between bills and XML documents. This ensures consistent attachment functionality regardless of the bill creation method.
Original PR description
Problem: when a user uploads an XML file containing an embedded PDF to create a bill, the bill is created correctly and the PDF is set as the main attachment. However, when the same XML is used to…
Problem: when a user uploads an XML file containing an embedded PDF to create a bill, the bill is created correctly and the PDF is set as the main attachment. However, when the same XML is used to create a bill via email aliases, the PDF is not set as the bill’s main attachment. Root cause: 1. When an email is received, it's first posted as a message on the bill chatter 2. Posting the email sets its XML as the main attachment of the bill 3. _fix_attachments_on_record from account.document.import.mixin then removes res_id and res_model fields from the XML 4. The PDF is then attached as the main attachment of the bill 5. In documents_account module, when the PDF is set as the main attachment, it mistakenly assigns it as an attachment to the XML document because the XML was assigned as the bill main attachment, resulting in the bill having no attachment actually linked to it. Solution: This commit fixes this issue by clearing the field message_main_attachment_id whenever the attachment in it gets unattached in _fix_attachment_on_record. task-5900088 Forward-Port-Of: odoo/odoo#246991
This update prepares the l10n_eu_iot_scale_cert module for compatibility with Odoo 19.0. It simplifies communication with IoT devices and removes outdated features related to manual quantity adjustments, ensuring accurate certification processes.
Original PR description
This PR adapts the l10n_eu_iot_scale_cert module for the certification in v19.0 1) It adapts the communication with the iot box to use the new iot_http_service 2) It removes the possibility to manually change the quantity on a weighed product 3) It removes the possibility to set a negative tare Related PR in v18: https://github.com/odoo/enterprise/pull/107103 task-5926814 Forward-Port-Of: odoo/enterprise#107123
This update ensures seamless communication between Odoo's IoT boxes and databases, specifically addressing a change in data format between versions 18.0 and 19.1. The update adjusts the IoT box to send both expected data values, resolving compatibility issues and maintaining reliable data flow.
Original PR description
This PR adds the scale commands compatibility for the iot box images in >= saas-19.1 with the dbs in v18.0 and less In v18.0 we read 'value' key sent by the iot box but the iot box doesn't send it anymore in 19.1 This PR makes the iot box send both 'result' as exepcted in v19 and 'value' expected in v18 Enterprise PR: https://github.com/odoo/enterprise/pull/107641
A recent update caused a crash when users tried to undo a duplicated list within the spreadsheet feature. This fix ensures that users can now correctly undo actions, including list duplication, without experiencing unexpected errors. This improves the stability and usability of the spreadsheet functionality.
Original PR description
How to reproduce: - insert an odoo list in a spreadsheet - duplicate the list from the sidepanel - undo with Ctrl+z -> crash The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry. Task-5943688 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#249475 Forward-Port-Of: odoo/odoo#248969
This update resolves a technical issue that could cause errors when opening barcode rule forms within the Stock module. The fix removes a dependency on a parent record, ensuring the form loads correctly and preventing unexpected errors. This improves stability and usability.
Original PR description
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type ==…
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type == 'alias') Steps to Reproduce: ========================= - Install the stock module. - Go to Configuration → Barcode Nomenclatures in the Stock app. - Open any Barcode Nomenclature form. - Go to the Rules tab and open a rule (pop-up form view). - Click on the Expand button. - A traceback is raised. Cause of the issue: ========================= The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record is not defined when the rule form view is opened directly (via expand), leading to a traceback. This happens because the form view is not defined as a child of any parent view, so no parent context is available, which leads to a traceback. With This Commit: ========================= Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature` directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a related field to `barcode.nomenclature`, so it can be safely used without relying on the parent. opw-5949083 Forward-Port-Of: odoo/odoo#249293
This update fixes an issue where the website filters disappeared when using the 'off-screen menu' style. The change ensures the filters button remains visible when no sort or pricelist options are selected, providing a consistent and user-friendly experience for browsing products.
Original PR description
Versions -------- - 19.1+ Steps ----- 1. Disable all pricelists to hide pricelist filter 2. Go to shop page 3. Change Filters style to "Off-screen Menu" - Note that a "Filters" button appears next to the sort by dropdown 4. Remove the sort by from the toolbar by untoggling it Issue ----- When the filters are set to off-screen and there is no sort by dropdown or pricelist dropdown, the filters button disappears. Cause ----- The div containing the filters button, sort by dropdown, and pricelist dropdown, is set to `d-lg-none` when there is no pricelist dropdown and no sort by dropdown, causing it do disappear. Solution -------- Only allow the div to disappear when the filter button shouldn't appear (`wsale_has_filters_btn` set to False) opw-5933858
This update corrects a technical issue within Odoo's testing framework related to how webjson responses are processed. Previously, a test was failing due to an unexpected data type being returned. This fix ensures that tests accurately reflect the expected behavior of the webjson functionality, improving overall test stability.
Original PR description
The return value of the patched methods was a MagicMock and not a recordset, and make_json_response was doing funny stuff with that returned MagicMock 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#249496
This update adds a warning message to the invoice batch wizard when the automated invoice sending cron job is disabled. This ensures users are alerted if their invoices won't be sent, preventing potential delays and improving invoice processing transparency. It addresses feedback from SBR to enhance user experience.
Original PR description
When the Cron responsible of sending the invoices asynchronously is disabled, the user has no clear indication that his invoices won't be sent as they should. Let's add a warning in the batch wizard that notify the user something is wrong. task-none (feedback from SBR) Message when no rights to update cron: <img width="990" height="328" alt="image" src="https://github.com/user-attachments/assets/1100ef6f-d047-49f2-bd8f-c8ef9fd543d8" /> Message when admin: <img width="999" height="308" alt="image" src="https://github.com/user-attachments/assets/28e90295-d225-4785-82a9-65be3ce79621" /> Forward-Port-Of: odoo/odoo#249270 Forward-Port-Of: odoo/odoo#248994
This update resolves a bug that caused 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 prevented emails from being sent correctly when processing multiple equity transactions. The fix corrects a configuration error within the email template, ensuring accurate record matching and preventing errors during email generation. This improves the reliability of equity transaction notifications.
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 clicking on certain activity types (like 'Eat cookies') in the calendar view would cause a technical error (traceback). The fix ensures that these activities can now be properly viewed, improving the user experience and preventing disruptions.
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 Italian company data (like tax ID and address) wasn't being properly transferred when creating a company from an ecommerce order. Previously, the system didn't consistently populate the required Italian tax fields. This change ensures that all necessary Italian business information is correctly recorded, improving data accuracy and compliance.
Original PR description
**STEP TO REPRODUCE** 1. Create a ecommerce order on a shop page of a italian company. 2. Goes to the checkout page, enter info (company_name, l10n_it_codice_fiscale, l10n_it_pa_index). 3. On the contact created, click on create company. 4. Notice l10n_it fields are not propagated to the company. opw-5477372 Forward-Port-Of: odoo/odoo#248524 Forward-Port-Of: odoo/odoo#246785
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 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
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 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 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
8 changes
Resolved issues and error corrections
This update resolves a display issue in the employee offer screen for the Belgium payroll localization. Previously, a contract type field was incorrectly shown, which has now been corrected by adding a new field to the model. This ensures the correct display of offer information for Belgian employees.
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#107755 Forward-Port-Of: odoo/enterprise#104578
This update corrects a problem where the timesheet approval reminder email was sending to an outdated action. The action was updated as part of a larger change in 17.3 to consolidate previous week/month actions. This ensures the approval reminder email functions correctly, sending to the appropriate timesheet records.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107440 Forward-Port-Of: odoo/enterprise#107385
This update corrects a technical issue related to the transmission of 13th month payroll data for Swiss clients using the LPP (Lump-Sum Payment) base. The change ensures accurate reporting and compliance with Swiss tax regulations, specifically addressing a requirement for including the 13th month payment in the LPP calculation.
Original PR description
Forward-Port-Of: odoo/enterprise#107908
This update resolves an issue where Invoicing and Banks users were unable to access key financial reports. The change adds necessary security permissions, allowing these groups to view basic reports like partner ledger and aged receivable/payable, improving their ability to manage financial data.
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#107851 Forward-Port-Of: odoo/enterprise#107654
This update resolves an issue preventing accurate report generation within the l10n_au_hr_payroll_account module. The change adjusts the report domain to use .ids instead of NewId, ensuring the reports correctly identify payroll records. This improves the reliability of financial reporting.
Original PR description
Domains do not support NewId, so we change the report domain to call .ids instead. [Runbot Error - 115303](https://runbot.odoo.com/odoo/error/115303)
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
17 changes
Resolved issues and error corrections
A recent update caused a crash when users tried to undo a duplicated list within the spreadsheet feature. This fix ensures that the undo function now correctly handles list duplication, preventing unexpected errors and improving the overall stability of the spreadsheet experience. This resolves a frustrating user experience issue.
Original PR description
How to reproduce: - insert an odoo list in a spreadsheet - duplicate the list from the sidepanel - undo with Ctrl+z -> crash The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry. Task-5943688 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#249475 Forward-Port-Of: odoo/odoo#248969
This update resolves a technical issue that could cause errors when opening barcode rule forms within the Stock module. The fix removes a dependency on a parent record, ensuring the form loads correctly and prevents unexpected tracebacks. This improves stability and usability for users managing barcode configurations.
Original PR description
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type ==…
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type == 'alias') Steps to Reproduce: ========================= - Install the stock module. - Go to Configuration → Barcode Nomenclatures in the Stock app. - Open any Barcode Nomenclature form. - Go to the Rules tab and open a rule (pop-up form view). - Click on the Expand button. - A traceback is raised. Cause of the issue: ========================= The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record is not defined when the rule form view is opened directly (via expand), leading to a traceback. This happens because the form view is not defined as a child of any parent view, so no parent context is available, which leads to a traceback. With This Commit: ========================= Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature` directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a related field to `barcode.nomenclature`, so it can be safely used without relying on the parent. opw-5949083 Forward-Port-Of: odoo/odoo#249293
This update resolves a bug that caused forum posts to fail to create when Odoo was running 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 experience for users.
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 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 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 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
3 changes
Resolved issues and error corrections
This update fixes a technical issue that previously caused errors when closing a Point of Sale (POS) session if the partner's address (street or postal code) was missing. Now, the system gracefully handles these empty address fields, ensuring a smoother POS session closure and preventing disruptions to order processing. This improves the reliability of the German POS certification process.
Original PR description
Before this commit, if a POS order was created with a partner that had an empty street or postal code, the system would raise an error when closing the POS session. opw-5897334 Forward-Port-Of: odoo/enterprise#106300
This update 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
9 changes
Resolved issues and error corrections
This update corrects a problem where the timesheet approval reminder email was sending to an outdated action. The action was updated as part of a recent Odoo release (17.3+) to align with a new system for managing timesheets. This ensures the reminder email functions correctly.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107440 Forward-Port-Of: odoo/enterprise#107385
This update adjusts the automated tests for the spreadsheet edition of Odoo. These changes ensure the tests accurately reflect the recent updates to the o-spreadsheet functionality. This improves the reliability of our testing process and helps maintain the quality of the spreadsheet features.
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 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 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
6 changes
Resolved issues and error corrections
This pull request updates the core spreadsheet component within Odoo. It addresses several minor bugs and improves the spreadsheet's functionality, specifically related to formula evaluation and button visibility. These updates ensure a smoother and more reliable spreadsheet experience for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ce74496c9 [REL] 18.0.57 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ce74496c9 [REL] 18.0.57 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/43731776d [FIX] Evaluation: Provide cell position on single formula evaluation [Task: 5798610](https://www.odoo.com/odoo/2328/tasks/5798610) https://github.com/odoo/o-spreadsheet/commit/979c0a365 [FIX] chart-panel: keep buttons visibles [Task: 5926661](https://www.odoo.com/odoo/2328/tasks/5926661) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
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 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 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 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.
4 changes
Resolved issues and error corrections
This update adjusts Odoo to comply with a new Italian law effective January 1, 2025. Forfettari (RF19) – a specific type of small business – can now utilize simplified invoices regardless of the total invoice amount. This simplifies invoicing processes for these businesses.
Original PR description
Since 01/01/2025, Italian law allows forfettari (RF19) to use simplified invoices even if the total amount exceeds 400€. References: - https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:legge:2014-12-23;190;1;59#:~:text=L'emissione%20della%20fattura%2C%20ove%20prevista%2C%20può%20avvenire%20in%20modalità%20semplificata%20ai%20sensi%20dell'articolo%2021%2Dbis%20del%20decreto%20del%20Presidente%20della%20Repubblica%2026%20ottobre%201972%2C%20n.%20633%2C%20anche%20se%20di%20ammontare%20complessivo%20superiore%20al%20limite%20indicato%20nel%20comma%201%20del%20medesimo%20articolo%2021%2Dbis. - https://www.dkpost.it/fattura-semplificata-senza-limiti-per-i-forfettari/ - https://www.gazzettaufficiale.it/eli/id/2024/11/30/24G00196/sg
This update resolves a technical issue preventing the Hungarian VAT integration from saving correctly. The problem stemmed from a shortened software ID string, requiring an 18-character value for compatibility with the NAV system. The fix pads the software ID to the correct length, ensuring successful data saving and integration.
Original PR description
**Steps to reproduce:** * Create a **Hungarian** database with **Accounting** or **Invoicing**. * Set a valid **VAT number** on the company. * Configure **NAV credentials** in **production mode**.…
**Steps to reproduce:**
* Create a **Hungarian** database with **Accounting** or **Invoicing**.
* Set a valid **VAT number** on the company.
* Configure **NAV credentials** in **production mode**. (use credentials from ticket)
* Try to save the Settings.
**Observed behavior:**
* Authentication fails with error: `INVALID_REQUEST: Helytelen kérés!`
* NAV returns schema violation: `Value 'BE477472701-19110' is not facet-valid with respect to pattern '[0-9A-Z\-]{18}' for type 'SoftwareIdType'.`
* The softwareId is only 17 characters instead of required 18.
**Cause:**
* The `version` parameter was removed from the module manifest by this [commit](https://github.com/odoo/odoo/commit/717619571d1297d6b299b7c47b728841bcd81e69#diff-d96ba04bb478d9dcbade7b9bf9f07305d42a38ce7a906f3387879271cde35fecL7)
* This change shortened the module version string used to build the `softwareId`.
* Truncating the value to 18 characters therefore produced a string shorter than required.
* The NAV API requires the `softwareId` to be **exactly 18 characters**.
**Fix:**
* Pad the generated `softwareId` to **18 characters** using `ljust(18, '0')`.
* Ensures the value always complies with NAV schema validation rules.
opw-5902414This 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