Daily updates from Odoo
Friday, February 20, 2026
203 changes
30 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 a potential issue where global invoices from the POS system in Mexico could fail to send correctly, leading to duplicate documents being submitted to the SAT portal. Increasing the timeout for communication with the SW sapien system helps ensure invoices are reliably transmitted, preventing errors and maintaining compliance. This improves the overall stability of the Odoo Enterprise system for Mexican businesses.
Original PR description
**Fix:** Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again. opw-5347962 Forward-Port-Of: odoo/enterprise#107735
This update resolves an issue where Odoo was incorrectly including an UETR tag in ISO 20022 payment files, causing rejection by strict banks. The fix ensures compliance with SEPA regulations, preventing errors and guaranteeing successful payment processing for our European customers. This improves compatibility with major banking systems.
Original PR description
In Odoo 18.0, when a user selects the pain.001.001.09 format (ISO 20022), Odoo systematically includes the <UETR> (Unique End-to-end Transaction Reference) tag for every transaction. While valid under the general ISO 20022 XML schema, the <UETR> tag is not authorized by the EPC (European Payments Council) within the standard SEPA Credit Transfer (SCT) Rulebook. Strict banks (e.g., UBS, German banks) reject the entire file with errors such as: "No child element is expected at this point" when an UETR is detected in a domestic or intra-SEPA flow. Task: 5871528 Forward-Port-Of: odoo/enterprise#107869 Forward-Port-Of: odoo/enterprise#105518
This update fixes a problem preventing wage statements in Switzerland (l10n_ch_hr_payroll) from being correctly sent out. The fix ensures accurate generation and delivery of these important financial documents, complying with Swiss regulations. This resolves a potential delay in reporting payroll information.
Original PR description
Forward-Port-Of: odoo/enterprise#107837 Forward-Port-Of: odoo/enterprise#107827
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 corrects a bug in the Belgian company structure type calculations. Previously, the system incorrectly calculated the amount of meal vouchers and private car benefits on payslips. This fix ensures accurate reporting of these benefits, resolving a potential discrepancy in payroll data.
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.
This update improves the odoo spreadsheet component by compressing data for faster loading and smaller file sizes. It also addresses issues with chart backgrounds and table auto-extension, enhancing the spreadsheet's performance and usability. This ensures a smoother experience for users working with spreadsheets within Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bd2d994f5a [REL] 19.2.0 [](https://www.odoo.com/odoo/2328/tasks/)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bd2d994f5a [REL] 19.2.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/5f0c837502 [REL] 19.2.0-alpha.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/bb4353b04b [IMP] export: reduce JSON size [Task: 5489478](https://www.odoo.com/odoo/2328/tasks/5489478) https://github.com/odoo/o-spreadsheet/commit/63a47b4005 [REF] cells: remove content from formula cells [Task: 5489478](https://www.odoo.com/odoo/2328/tasks/5489478) https://github.com/odoo/o-spreadsheet/commit/b9c86c5039 [REF] introduce CompiledFormula [Task: 5489478](https://www.odoo.com/odoo/2328/tasks/5489478) https://github.com/odoo/o-spreadsheet/commit/832a1cbbb8 [FIX] charts: chart have wrong background at copy/download [Task: 5925821](https://www.odoo.com/odoo/2328/tasks/5925821) https://github.com/odoo/o-spreadsheet/commit/734466abf0 [FIX] tables: avoid auto-extend on pivot formulas [Task: 5905874](https://www.odoo.com/odoo/2328/tasks/5905874) https://github.com/odoo/o-spreadsheet/commit/5d43c36551 [FIX] dynamic_tables: ignore dynamic pivot table inside static table [Task: 5905874](https://www.odoo.com/odoo/2328/tasks/5905874) https://github.com/odoo/o-spreadsheet/commit/4cb0fccd81 [FIX] dynamic_tables: enable total row style only when total is visible [Task: 5920830](https://www.odoo.com/odoo/2328/tasks/5920830) https://github.com/odoo/o-spreadsheet/commit/38bf6f006e [IMP] icons: add and uniformize some icons [Task: 5797703](https://www.odoo.com/odoo/2328/tasks/5797703) https://github.com/odoo/o-spreadsheet/commit/d263f13077 [FIX] topbar menu: fix formulas order in "insert formula" menu [Task: 5797703](https://www.odoo.com/odoo/2328/tasks/5797703) https://github.com/odoo/o-spreadsheet/commit/71bf1333b5 [IMP] formulas: move FORMAT_LARGE_NUMBER to text module [Task: 5797703](https://www.odoo.com/odoo/2328/tasks/5797703) https://github.com/odoo/o-spreadsheet/commit/be8f08f81b [FIX] tests: do not dispatch `UDPATE_CELL_POSITION` in monkey party [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/35a328913e [IMP] index: export Select component [Task: 5048552](https://www.odoo.com/odoo/2328/tasks/5048552) 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>
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 resolves an issue where upgrade processes incorrectly delayed constraint definitions, leading to failures. The change ensures that the latest constraint definition is always applied, particularly when modules are loaded in a different order. This improves the stability and reliability of Odoo upgrades.
Original PR description
Current issue: Module A fails to add constraint X with definition D1 -> (X,D1) is delayed Module B loaded after A, overrides constraint X to D2 and also fails to add the constraint -> still (X,D1) are in the delayed queue, instead of (X,D2) In this patch we ensure the delayed constraint gets the latest definition (D2) This issue affects upgrades. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249495
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 optimizes how Odoo retrieves related data, specifically when fetching multiple records at once. The change reduces the potential for performance slowdowns by preventing data duplication and improving efficiency in complex data relationships. This results in faster data retrieval, particularly when dealing with large datasets.
Original PR description
Various improvements to avoid non-linear growth of returned values when iterating over prefetches. Traversing a relational field introduces a duplication factor in the returned values. `records |=…
Various improvements to avoid non-linear growth of returned values when iterating over prefetches. Traversing a relational field introduces a duplication factor in the returned values. `records |= more` is syntactic sugar for `records = records | more`, which does not modify the recordset in place but makes one from scratch. Therefore the time complexity is not `O(len(more))` but `O(len(records) + len(more))`, which is what makes it quadratic when used in a loop. Since refactor in https://github.com/odoo/odoo/pull/229057, this quadratic complexity is introduced in the prefetching, too. Changes: - Keep same prefetch when accessing a single key as when iterating over a recordset. Small gain and more consistent results. - When iterating over prefetches, deduplicate at source. Without this, the overhead of the generator can be huge for each returned value, since the same value might be returned many times. In less trivial cases (like traversing two relational fields and making unions with it), the time speedup is several orders of magnitude. Forward-Port-Of: odoo/odoo#248770
This 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 prevents discounts applied to recurring subscription lines from being unexpectedly removed when an upsell is added to the order. Previously, confirming an upsell would reset the discount, causing revenue discrepancies. This change ensures accurate discount calculations and prevents financial errors during upsell transactions.
Original PR description
Before this commit, the discount of recurring lines in a sub would be reset in the following case: 1) create a sub, add a discount on recurring line 2) invoice the sub 3) create an upsell, add quanitty on the recurring product, change the start date of the upsell to trigger computation 4) confirm the upsell The discount of the parent order was reset. task-5886270 Forward-Port-Of: odoo/enterprise#105750
This update fixes a discrepancy in accounting calculations within the Point of Sale (POS) for Mexican tax reporting (l10n_mx_edi_pos). Previously, the POS wasn't correctly loading necessary data, leading to inaccurate amounts. This change ensures that POS transactions align with the calculations performed in Python, improving financial accuracy.
Original PR description
Before this commit, the needed assets were not correctly loaded in the POS, which caused the amounts to be different from the ones computed in python. opw-5935191 Forward-Port-Of: odoo/enterprise#107657
This update fixes a problem where orders wouldn't sync correctly after a terminal payment and an online payment were added and then removed. Previously, the server would remove the terminal payment even if it was still visible in the user interface. Now, only online payments are deleted, ensuring accurate order synchronization and a consistent view across the system.
Original PR description
Before this commit, if an order had a terminal payment and an online payment was added accidentally, and then get removed, the terminal payment would get removed from server, while it won't be removed from the UI, resulting in a mismatch between the server and the UI, and the order would no be synced correctly. opw-5911699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248430
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 resolves an issue where Peppol invoices were incorrectly using the wrong company context, leading to errors and inconsistencies when processing invoices across different companies. The fix ensures that invoices are processed with the correct company's information, preventing data mismatches and improving data accuracy for cross-company transactions.
Original PR description
Currently, the created move does not always use the company context of the related move/proxy user. As a result, default values may be taken from another company, which can lead to cross-company inconsistencies and access errors. Steps to reproduce: - Set up two companies, A and B - In company A, configure a default value for the partner.company_id field, applicable only to company A - When a Peppol invoice arrives for company B but is processed using the context of company A, and a new partner must be created, the partner is created with company A as the default value - This results in an incompatible companies on record error This fix ensures that the company context of the move or EDI user is used when creating the move, preventing cross-company issues. opw-5473233 Forward-Port-Of: odoo/odoo#249409 Forward-Port-Of: odoo/odoo#249059
26 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 resolves an issue where the AI translation feature in the website builder would fail due to a 10-second timeout. The fix removes this timeout restriction, allowing translations to complete successfully even with large amounts of untranslated text. This improves the user experience for translating website content.
Original PR description
Scenario: - have lot of untranslated text in a page - in a secondary language, open translation editor - click on "Translate to [current language]" in side panel Result: the translation fails completely or partially, and there is a notification saying "A technical issue occurred in the builder, you should save or discard your changes.". Reason: since 6df83abb35c95ab42e55d9a08cf6c411efa64b3e website builder action have a default timeout of 10 seconds to prevent deadlocks. But the /html_editor/generate_text can easily take more than 10 secondes depending on latency and quantity of text to translate. Fix: prevent the timeout when using the AI translation feature. opw-5892402 Forward-Port-Of: odoo/odoo#249464
This update ensures that expense accounts are linked to the correct company when using products. Previously, expenses created for one company would incorrectly use accounts from a different company. This fix resolves a potential issue with inaccurate financial reporting and improves data consistency.
Original PR description
The aim of this commit is to ensure the account select through product is related to the correct company. (ie. the one related to the processed model) Before this commit: If a user has company_a selected as the main company in the company switcher and create an expense for company_b, the account selected from the product will be an account from company_a. (because product is shared between company but the account properties on those are company dependent) This could also happens in other places so we fixed it. After this commit: The account selected from the product will be from the company set on the model. task-4699717 Forward-Port-Of: odoo/odoo#249194 Forward-Port-Of: odoo/odoo#209144
This update 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 an issue where upgrades were failing due to delayed constraint definitions. Specifically, when modules loaded in a different order, outdated constraint definitions were causing errors. This patch ensures the latest definition is always applied, improving the stability and reliability of Odoo upgrades.
Original PR description
Current issue: Module A fails to add constraint X with definition D1 -> (X,D1) is delayed Module B loaded after A, overrides constraint X to D2 and also fails to add the constraint -> still (X,D1) are in the delayed queue, instead of (X,D2) In this patch we ensure the delayed constraint gets the latest definition (D2) This issue affects upgrades. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249495
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 issues with how custom snippets are displayed in the website editor's preview. Specifically, it ensures consistent preview heights for carousel snippets and correctly shows zoom effects for parallax snippets, while also ensuring custom snippet labels are displayed. These changes improve the user experience when creating and managing website content.
Original PR description
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet…
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview height is too small. Before this commit, the preview height was computed from the scaled size, so shorter slides made the preview min-height too low. After this commit, the preview height uses the layout size so the min-height stays consistent with other slides. ---------- Steps to reproduce: - Open the website editor. - Open the snippet dialog and resize the window. => The parallax preview background shifts to the left. - Save a snippet with a parallax zoom in/out effect as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview shows a top to bottom effect instead of zoom. Before this commit, resizing the snippet dialog could offset the parallax background to the left, and zoom previews looked like top to bottom effects. After this commit, the preview keeps the background aligned and shows zoom in/out effects for custom snippets. Fixed parallax is still not previewed because it would require an oversized background in the dialog. ---------- Steps to reproduce: - Open the website editor. - Save a "Carousel" snippet as a custom snippet. - Open the snippet dialog. => The custom snippet shows no label. Before this commit, custom previews dropped the base label so the dialog showed no tag for custom snippets. After this commit, custom previews reuse the base label. task-5156137 **To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244251 must be present** Forward-Port-Of: odoo/odoo#248929 Forward-Port-Of: odoo/odoo#244295
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 enables users to remove orderlines when using the LNE certified scale module in Point of Sale (PoS). Importantly, the system still prevents manual quantity adjustments beyond zero, ensuring data accuracy for scale-based transactions. This resolves a previous limitation and improves the usability of the certified scale functionality.
Original PR description
This PR allows the user to delete PoS orderline when using LNE certified scale module while still forbidding to manually set quantity to anything other than 0 Forward-Port-Of: odoo/enterprise#107413
This update ensures the 'first_contract_in_company' field always reflects the employee's earliest contract start date, regardless of when it was created or modified. Previously, this information was unreliable due to a manual process, now it's automatically calculated and updated whenever a contract version changes, improving payroll accuracy and reporting.
Original PR description
Version-19.0 **Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late. We need that information at other places too. ### What This PR Does This PR restores…
Version-19.0
**Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late.
We need that information at other places too.
### What This PR Does
This PR restores the reliable computation of the employee's first contract date by:
- Computing the earliest contract start date across all versions of the employee.
- Automatically updating the `first_contract_in_company` field whenever:
1. A new contract is created
2. an existing version changes it start date, or
3. an existing version is deleted for the employee.
### Technical Summary
**Update the first contract date on create/write**
- when an hr.version is created or updated, it will recompute the employee's earliest
`contract_date_start` across all versions.
- The update is performed in `_compute_first_contract_in_company()`, which:
1. fetches all the active versions of employee
2. filter those having `contract_date_start`
3. Computes the earliest start date.
4. Updates `employee.first_contract_in_company` accordingly.
**Result**
The field `first_contract_in_company` is now always accurate and reflects real employee history.
Forward-Port-Of: odoo/enterprise#102198This 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 prevents discounts applied to recurring subscription lines from being removed when an upsell is added to the order. Previously, confirming an upsell would reset the discount, leading to incorrect pricing. This change ensures accurate discount calculations for subscription orders with upsells, improving order accuracy and customer satisfaction.
Original PR description
Before this commit, the discount of recurring lines in a sub would be reset in the following case: 1) create a sub, add a discount on recurring line 2) invoice the sub 3) create an upsell, add quanitty on the recurring product, change the start date of the upsell to trigger computation 4) confirm the upsell The discount of the parent order was reset. task-5886270 Forward-Port-Of: odoo/enterprise#105750
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 an issue where Peppol invoices were incorrectly using the wrong company context, leading to errors and inconsistencies when creating accounting records. The fix ensures invoices are processed with the correct company details, preventing data mismatches and improving data accuracy for cross-company transactions.
Original PR description
Currently, the created move does not always use the company context of the related move/proxy user. As a result, default values may be taken from another company, which can lead to cross-company inconsistencies and access errors. Steps to reproduce: - Set up two companies, A and B - In company A, configure a default value for the partner.company_id field, applicable only to company A - When a Peppol invoice arrives for company B but is processed using the context of company A, and a new partner must be created, the partner is created with company A as the default value - This results in an incompatible companies on record error This fix ensures that the company context of the move or EDI user is used when creating the move, preventing cross-company issues. opw-5473233 Forward-Port-Of: odoo/odoo#249409 Forward-Port-Of: odoo/odoo#249059
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 changing a partner in Odoo would erase the previously set default payment term for invoices. Now, the default payment term will remain consistent, regardless of the partner being used, 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 fixes an issue where the working time assigned to tasks wasn't accurately calculated when switching between companies with and without public holidays. The fix ensures that working time is correctly computed based on the last stage change and considers company-specific holiday impacts.
Original PR description
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2…
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation Nothing happens When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546 The company isn't taken into account in the domain, applying the holiday for every company. __ opw-5222883 Forward-Port-Of: odoo/odoo#246994
This update corrects a bug where high-priority applicants weren't appearing at the top of the applicant list in the Recruitment module. The fix resolves a technical issue with how applicant priority was being ordered, ensuring that the most important applications are now displayed first.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install the Recruitment module 2. Navigate to Recruitment > Applications > All Applications 3. Go to Kanban view 4. Make any…
Steps to reproduce: ---------------------------------------- 1. Install the Recruitment module 2. Navigate to Recruitment > Applications > All Applications 3. Go to Kanban view 4. Make any application Very High Priority (3 star) 5. Refresh the page Observation: ---------------------------------------- Applications marked as Very High Priority are not displayed on top, Applicants with higher priority should be displayed first within the same stage. Issue: ---------------------------------------- The `_order` attribute on the applicant model is declared twice, causing the intended priority-based ordering to be overridden by `sequence`. https://github.com/odoo/odoo/blob/6fed805389d878558e4139b270ee7a70269af767/addons/hr_recruitment/models/hr_applicant.py#L28-L41 Solution: ---------------------------------------- Reorder the fields in the `_order` attribute so that priority is applied before sequence, ensuring higher-priority applicants are shown first opw-5893371 Forward-Port-Of: odoo/odoo#247779
This update fixes an issue where changes made to email marketing records within the form editor were lost when switching between tabs. The fix ensures that the editor correctly saves changes when the focus is lost, improving the user experience and data integrity. This prevents data loss and ensures consistent email marketing campaigns.
Original PR description
Problem: While editing an email marketing record, switching tabs in the form view causes the last changes in the editor to be lost. Cause: The `blur` event on the iframe is not triggered when clicking outside of it. If the iframe is not fully ready when listeners are attached, the required events are not properly registered, so the latest changes are not saved before switching tabs. Solution: Attach the `blur` listener only once the iframe is fully loaded, ensuring that changes are correctly detected and saved when focus is lost. Steps to reproduce: - Create a new email marketing record. - Add a text snippet. - Change the text and save. - Modify the text again. - Switch to another tab in the form view, then return to the "Mail body" tab. - Observe that the last changes are lost. opw-5921800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248974
This update resolves an issue where clicking 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
9 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 where tasks remained linked to sales orders even without associated order items, preventing users from properly billing tasks. The change ensures tasks can be cleanly detached from sales orders when no items are linked, streamlining billing processes and improving task management. This fix maintains the ability to add materials to existing sales orders for field service tasks.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2] https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related community PR: https://github.com/odoo/odoo/pull/241446 opw-5215989 Forward-Port-Of: odoo/enterprise#107716 Forward-Port-Of: odoo/enterprise#103487
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 resolves an issue where users could inadvertently assign partners from different companies when managing multiple companies. The change ensures that partners are correctly associated with the intended company, improving data accuracy and streamlining accounting processes. This fix enhances the reliability of financial reporting across our enterprise solutions.
Original PR description
Before this commit, it was possible to add a partner that was from another company when multiple companies were selected. task-5941113 Forward-Port-Of: odoo/enterprise#107546
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
10 changes
Resolved issues and error corrections
This update resolves an issue where tasks remained linked to sales orders even after the associated sales order item was removed. Now, tasks can be properly detached from sales orders when no items are linked, allowing users to accurately bill tasks and manage them independently. This improves task management and billing accuracy.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty the Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2]: https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related Enterprise PR: https://github.com/odoo/enterprise/pull/103487 opw-5215989 Forward-Port-Of: odoo/odoo#249107 Forward-Port-Of: odoo/odoo#241446
This update resolves an issue where tasks remained linked to sales orders even without associated sales order items, preventing proper billing. The change ensures tasks can be correctly detached from sales orders when no items are linked, streamlining the billing process for field service tasks. This improves user efficiency and accuracy.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2] https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related community PR: https://github.com/odoo/odoo/pull/241446 opw-5215989 Forward-Port-Of: odoo/enterprise#107716 Forward-Port-Of: odoo/enterprise#103487
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 an incorrect reliance on Peppol BIS3 constraints within the RO and HR EDI modules. Previously, an unnecessary dependency caused issues with sending invoices, particularly to physical persons. This fix ensures proper functionality and compliance with standard EDI formats.
Original PR description
The CIUS RO and CIUS HR depends on the BIS3 which is fundamentally incorrect. This was probably made out of lazyness to redefine things that are almost the same in both these CIUS and the BIS3. Now, in previous PR [1], we added contraints for the Peppol BIS 3 that are impacting those formats. Indeed, the EndpointID can be empty in the context of CIUS RO and CIUS HR. In particular, it's breaking the sending to physical person at the moment. [1]: https://github.com/odoo/odoo/pull/246961 opw-5943698 Forward-Port-Of: odoo/odoo#249089
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
A recent update to the Point of Sale system introduced a double confirmation issue when using CTRL+Enter in a popup dialog. This resulted in duplicate entries being created, such as multiple floors. This fix prevents this duplication, ensuring data integrity and accurate record-keeping.
Original PR description
For the `TextInputPopup` component a feature was introduced in 2f5c5c15644412cfb6493c661b2f1b927c8cc7e2 that allows the user to confirm the popup by simply clicking enter. The problem is that the dialog itself has a hotkey on "CTRL+Enter" that will also confirm the popup. This means that if a user uses the "CTRL+Enter" hotkey, the popup will be confirmed twice. Steps to reproduce: 1. In restaurant, click the button to add a new floor 2. Write a name for the floor 3. Click "CTRL+Enter" 4. Observe that 2 floors with the given name were created instead of one. The fix: We stop the propagation of the event Task: 4698289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212134
This update resolves an issue where the 'Update Prices' button disappeared after saving a quotation. The fix adds a field to the view that ensures the button remains visible, allowing users to easily adjust prices within the quotation record. This improves the user experience and streamlines the quotation process.
Original PR description
Steps to produce: --- - Install sales module. - Go to Settings and enable Pricelists (make sure we have 2 pricelists so that we able to change the pricelist value in quotation). - Create a new…
Steps to produce: --- - Install sales module. - Go to Settings and enable Pricelists (make sure we have 2 pricelists so that we able to change the pricelist value in quotation). - Create a new quotation > Add a customer and product. - Change the pricelist. - Save the record. Issue: --- - After saving the quotation, the `Update Prices` button becomes invisible. Root cause: --- - The field `show_update_pricelist`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible. - The field is removed from the view in this [commit]. Solution: --- - Added the `show_update_pricelist` field to the view to ensure its value is properly maintained. This allows the `Update Prices` button to remain visible when applicable. [commit]: https://github.com/odoo/odoo/commit/da4b588b272432095f549c012e0a0d7238f00dc0 **Enterprice PR:** https://github.com/odoo/enterprise/pull/107621 opw-5927659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the 'Update Rental Prices' button disappeared after saving a rental order in the Odoo Enterprise system. The fix adds a field to the view that ensures the button remains visible when a rental period is changed and the order is saved. This improves usability for users managing rental agreements.
Original PR description
Steps to produce: --- - Install `sale_renting` module. - Rental > Open any order > Change the rental period. - Save the record. Issue: --- - After saving the order, the `Update Rental Prices` button becomes invisible. Root cause: --- - The field `show_update_duration`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible. - The field is removed from the view in this [commit]. Solution: --- - Added the `show_update_duration` field to the view to ensure its value is properly maintained. This allows the `Update Rental Prices` button to remain visible when applicable. [commit]: https://github.com/odoo/enterprise/commit/b90bbdef10a7a37fb065626ba995811ab388c7a1 opw-5937145 ---
This update fixes an issue where OCR-extracted expense amounts were incorrectly converting to USD, overriding the system's exchange rates. The change ensures that expense amounts are accurately converted to the company's base currency, improving the reliability of financial reporting.
Original PR description
Steps to reproduce: 1. Initialize an expense with a foreign currency (e.g., EUR). 2. Trigger OCR extraction on a receipt with a specific total. 3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value. 4. The exchange rate is forced to 1.0, ignoring the system's exchange rate. Cause: The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1. Solution: Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate. opw-5437611 Forward-Port-Of: odoo/enterprise#107862 Forward-Port-Of: odoo/enterprise#107534
1 change
Resolved issues and error corrections
This update resolves an issue where tasks remained linked to sales orders even without associated order items, hindering billing processes. The change ensures tasks can be properly detached from sales orders when no items are linked, streamlining billing and allowing for easier task management. This improves the flexibility of using tasks for non-billable services.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2] https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related community PR: https://github.com/odoo/odoo/pull/241446 opw-5215989 Forward-Port-Of: odoo/enterprise#107716 Forward-Port-Of: odoo/enterprise#103487
6 changes
Resolved issues and error corrections
This update resolves an issue where editing a value in a report would cause calculation errors. The fix ensures that report data is correctly processed when external values are modified, improving report accuracy and reliability. This impacts report generation and data consistency.
Original PR description
// Bug The following flow failed: 1) Create a report with 3 lines: - Line 1: using the "domain" engine - Line 2: using the "external" engine, with subformula="editable" - Line 3: an aggregation…
// Bug
The following flow failed:
1) Create a report with 3 lines:
- Line 1: using the "domain" engine
- Line 2: using the "external" engine, with subformula="editable"
- Line 3: an aggregation summing lines 1 and 2
2) Open the report, and edit the amount in line 2
===> Error message, stating Line 1 cannot be evaluated while evaluating Line 3's formula.
// Cause of the issue
When editing a manual value, to avoid recomputing the whole report uselessly, the client sends the column_groups_totals that were computed to render report back to the server. When modifying the external value, that data structure is used to get the results of all other expressions, and reevaluate the aggregations that depend on the modified external value. json is used to send the column_group_totals.
json conversion always forces the keys to be strings. In the past, this was no problem, since the column_group_totals' keys were column group keys, which were also strings server-side. However, https://github.com/odoo/enterprise/commit/ec3581cd759d8c4e03db9e08f6f95546e5724e1f now makes those key indices of a list, hence integers. So, when column_group_totals were sent from the client, they basically were ignored, since none of their keys matched any column group index, causing the bug.This update corrects a bug in the Indian payroll configuration, specifically preventing automatic payslip creation when new employees are generated. It also adjusts the default basic salary percentage to 50%, ensuring benefit updates only affect gross salary and employer costs, maintaining the employee's wage and payroll structure.
Original PR description
- Prevent automatic payslip creation when an employee is generated from an offer. - Fix the default Indian basic salary percentage to 50% instead of 60%. - Ensure benefit amounts are treated as additional employer payments and do not rebalance the employee’s wage or basic salary in the salary configurator. After this change, benefit updates only impact gross salary and employer cost, while the wage remain unchanged. task-[5501683](https://www.odoo.com/odoo/project/1251/tasks/5501683)
This update resolves an issue causing tour failures related to inconsistent state updates within the stock barcode module. The changes streamline tour execution, improve performance, and address a concurrency error, ensuring smoother and more reliable barcode scanning workflows. This enhances the user experience for inventory management.
Original PR description
Removes the `undeterministicTour_doNotCopy` from `stock_barcode` tours and fixes them to avoid the undeterministic error. This commit makes also minor changes like: - Removing useless `timeout`; - Using the new URL action path instead of old long action URL; - Creating records in batch when possible; - Renaming some tours to use the same name than the related python test; - Removing records created in specific test to use the records created in the setup instead. This PR also fixes a race condition which happened in `stock_barcode_mrp` `MainComponent` `saveFormView` .
This update fixes a bug in the Belgian payroll system that was causing incorrect calculations for meal vouchers and private car benefits on payslips. By assigning the correct work entry type, the system now accurately reflects these benefits, ensuring accurate reporting and compliance.
Original PR description
In this commit, we fixed the data of the existing Belgian structure types by setting the right work entry type as default_work_entry_type_id. Belgian's structure types should have the correct attendance work entry type to consider the meal vouchers and the private car in the benefits and payslip lines Before this change, the belgian payslips will have quantity 0 for meal vouchers and private car. After this change, the belgian payslips will have the correct quantity for both meal vouchers and private car. task-5946425
This update resolves an issue impacting the MRP Gantt view, specifically by reverting to a reliable view and introducing a new Work Center calendar. It also enhances the display of work orders and allows users to manage blocked workorders more effectively, improving overall planning efficiency.
Original PR description
- Use the old 'workcenter' gantt view rather than the 'production' (and remove it) - Create a new Work Center calendar - Add variant name in workorder display name - Add the falsy label to employee_assigned_ids (for Gantt view mainly) - Restore the possibility of not planning the 'blocked by' workorders - Reload after Plan in Gantt view task: 5946267
This update optimizes the recurring invoice process, resulting in faster performance and more reliable invoice generation. By streamlining data access and improving matching algorithms, the system now handles subscriptions more efficiently, reducing potential errors and improving overall user experience.
Original PR description
Before this commit, the recurring invoice process did extra searches, duplicated context handling, and used slower filtering logic. The parent line detection also rebuilt comparisons each time, which could lead to wrong matches or slow performance. After this commit, grouped subscriptions are merged more cleanly, context is applied once, closed orders are tracked with a set, and invoice lines are grouped by order for faster access. Parent line lookup now uses a precomputed map for quicker and safer matching. taskid-5265275
6 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 corrects a transmission issue related to the 13th month salary payment in Switzerland's LPP (Lohnsteuerhilfeverein) reporting. The change ensures that the 13th month is correctly included in the data sent for tax calculations, aligning with Swiss regulations. This improves accuracy and compliance for businesses using the Odoo Enterprise module in Switzerland.
Original PR description
Forward-Port-Of: odoo/enterprise#107908
This update fixes a potential issue in Australian payroll calculations by ensuring tax information is retrieved from the employee's historical pay period version instead of their current settings. This guarantees accurate withholding, Medicare, and other tax deductions, especially when employee details change over time, leading to more reliable payslips.
Original PR description
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields…
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values. This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state). This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period. The following rules/fields are updated to use the version object: - Tax Treatment Category - Additional Withholding Amount - Extra Pay - TFN Declaration - Medicare (Reduction, Exemption, and Levy) - Training Loans - NAT 3093 Amount (Tax Offset) - Child Support (Garnishee and Deduction) A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates. Task-5002697 Forward-Port-Of: odoo/enterprise#106550
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.
A technical error was preventing users from submitting their CIS monthly reports to HMRC. This fix addresses a problem where the system was incorrectly handling date formatting, causing a traceback. The update now correctly processes dates without timezone information, ensuring reliable report submissions.
Original PR description
Steps to Reproduce: Video Link - https://www.awesomescreenshot.com/video/48861703?key=b2eb19752b965cb72ad3e8a9215631ac - Install l10n_uk_reports_cis module - Enter HMRC credentials & Contractor…
Steps to Reproduce:
Video Link - https://www.awesomescreenshot.com/video/48861703?key=b2eb19752b965cb72ad3e8a9215631ac
- Install l10n_uk_reports_cis module
- Enter HMRC credentials & Contractor details in the HMRC tab in the UK Company
record
- Go to CIS Deduction (GB) report under the Reporting menu
- Select the Return Period already given in the report options
- Click on the Send to HMRC button
- Fill in the necessary details in the CIS monthly return wizard
- After that, click on the Send button on the appeared on the wizard
- Traceback will appear
<details><summary>Exact Traceback</summary>
<p>
```
RPC_ERROR
Odoo Server Error
Occured on 100019718-19-0-all.runbot216.odoo.com on model cis.monthly.return.wizard on 2026-02-04 07:21:51 GMT
Traceback (most recent call last):
File "/data/build/odoo/odoo/orm/domains.py", line 1492, in _value_to_date
value = parse_iso_date(value)
^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/tools/date_utils.py", line 104, in parse_iso_date
raise ValueError(f"expecting only datetimes with no timezone: {value!r}")
ValueError: expecting only datetimes with no timezone: '2026-01-05T00:00:00.000+05:30'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/data/build/odoo/odoo/http.py", line 2275, in _serve_db
return service_model.retrying(serve_func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/service/model.py", line 184, in retrying
result = func()
^^^^^^
File "/data/build/odoo/odoo/http.py", line 2330, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http.py", line 2545, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http.py", line 788, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/service/model.py", line 93, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_uk_reports_cis/wizard/monthly_return_wizard.py", line 75, in action_send_montlhy_return
lines = cis_report._get_lines(options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2678, in _get_lines
all_column_groups_expression_totals = self._compute_expression_totals_for_each_column_group(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 3327, in _compute_expression_totals_for_each_column_group
current_group_expression_totals = self._compute_expression_totals_for_single_column_group(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 3495, in _compute_expression_totals_for_single_column_group
formula_results = self._compute_formula_batch(column_group_options, engine, date_scope, formulas_dict, current_groupby, next_groupby,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 3853, in _compute_formula_batch
return getattr(self, engine_function_name)(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 4010, in _compute_formula_batch_with_engine_domain
query = self._get_report_query(options, date_scope, domain=aml_domain)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports_cash_basis/models/account_report.py", line 227, in _get_report_query
return super(AccountReport, context_self)._get_report_query(options, date_scope, domain=domain)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_analytic_report.py", line 154, in _get_report_query
query = super(AccountReport, context_self)._get_report_query(options, date_scope, domain)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2249, in _get_report_query
query = self.env['account.move.line']._search(domain)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports_cash_basis/models/account_move_line.py", line 15, in _search
query = super()._search(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_analytic_report.py", line 239, in _search
query = super()._search(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/models.py", line 5364, in _search
domain = domain.optimize_full(self)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 445, in optimize_full
return self._optimize(model, OptimizationLevel.FULL)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 653, in _optimize_step
children = self._flatten(child._optimize(model, level) for child in self.children)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/data/build/odoo/odoo/orm/domains.py", line 653, in <genexpr>
children = self._flatten(child._optimize(model, level) for child in self.children)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 971, in _optimize_step
domain = opt(self, model)
^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 1517, in _optimize_type_date
value = _value_to_date(condition.value, model.env, iso_only=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 1495, in _value_to_date
parse_date(value, env)
File "/data/build/odoo/odoo/tools/date_utils.py", line 146, in parse_date
return parse_iso_date(value)
^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/tools/date_utils.py", line 104, in parse_iso_date
raise ValueError(f"expecting only datetimes with no timezone: {value!r}")
ValueError: expecting only datetimes with no timezone: '2026-01-05T00:00:00.000+05:30'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://100019718-19-0-all.runbot216.odoo.com/web/assets/109aabb/web.assets_web.min.js:3190:165)
at XMLHttpRequest.<anonymous> (https://100019718-19-0-all.runbot216.odoo.com/web/assets/109aabb/web.assets_web.min.js:3196:13)
```
</p>
</details>
Reason:
- Action on the Send button in the CIS monthly return wizard is passing a string with DateTime + TimeZone info into the date_from and date_to, which is raising an error during domain optimization, stating that expecting only datetimes with no timezone.
Solution:
- We are now passing the parsed date with only Date info in the string to options.
Task-5865605This 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
8 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 ensures that manually added analytic accounts on sales order lines are retained after a project is confirmed. Previously, confirming a sales order with a project would overwrite these manually set accounts. This change corrects a bug impacting accurate revenue tracking and reporting, specifically within the sale and purchase order modules.
Original PR description
To reproduce: 1. Create a product of type service that creates a project on confirmation 2. Create an Analytic Distribution Model for that same product 3. Create a Sales Order with the same product…
To reproduce: 1. Create a product of type service that creates a project on confirmation 2. Create an Analytic Distribution Model for that same product 3. Create a Sales Order with the same product 4. Add another analytic account on the same line 5. Confirm the Sales Order The manually added account (step 4) is no longer in the sale order line. Cause: When the project is added at confirmation, `_compute_analytic_distribution()` is triggered and leads to the existing analytic distribution to be overwritten, using only the accounts of the matching distribution models and the project account. Solution: Instead of calling `super()._compute_analytic_distribution()` whenever the order_id.project_id changes, now the call is only performed if there is no project set in the order. If there is a project, the existing distribution is kept, and the project account is added, if there is no account of the project plan. This means that if the project is added before any lines, the distribution model accounts won't be added. Also, if the project is removed after the lines have been added, the compute will be triggered, still leading to the overwrite of any analytic distribution manually added. The same happens in Purchase Orders with projects, so this commit also handles project_purchase. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when users quickly created picking types in Odoo, specifically in versions 19.1 and above. The change disables quick creation to avoid a required field issue, ensuring smoother receipt creation and preventing data inconsistencies.
Original PR description
Currently an error occurs when user quick creates a picking type and tries to create a receipt with it. **Steps to replicate (only in saas-19.1 and above):** - Install stock. - Go to Inventory >…
Currently an error occurs when user quick creates a picking type and tries to create a receipt with it. **Steps to replicate (only in saas-19.1 and above):** - Install stock. - Go to Inventory > Receipts and create a new receipt > Save it. - Clear the Operation Type field, type `test` and quick create it. - Save and the error will occur. **Error:** ``` UndefinedFunction: operator does not exist: integer = boolean LINE 1: SELECT number_next FROM ir_sequence WHERE id=false FOR UPDAT... ``` **Cause:** - As the user quick created the picking type, the `sequence_code` field was not set and when we try to get `next_number` to create the name for the current stock picking this error occurs. - In the versions before `saas-19.1` trying to quick create picking type will lead to a `Not-Null Violation` as `sequence_code` is a required field and then stock picking type form view will open up. - This error occurs only after `saas-19.1` and above versions because this [PR] made the `sequence_code` field into a related field so its required constraint was removed and hence quick create creates a new picking type. **Solution:** - Since Quick Create always opens the picking type form view (same behavior as `Create and edit` before saas-19.1), it should be disabled to avoid redundancy. - This also prevents the error in versions `saas-19.1` and above. [PR]: https://github.com/odoo/odoo/pull/190305/changes#diff-79cbc763115661182c02285c07320098510f5686700359ddee67443b4893dc30L32-R32 sentry-7203804886 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug that occurred when the 'commercial_partner_id' field was visible in the contact form (often through web_studio). Previously, an error would be triggered when using the autocomplete feature, preventing proper PEPPOL status validation. This change ensures the field is always populated, resolving the error and improving the contact creation process.
Original PR description
Before this commit, when commercial_partner_id is on the view (possible with web_studio), the value by default is False. When the autocomplete widget is used, many fields could be autofilled and raise _onchange_verify_peppol_status, that requires this field. To avoid this issue we review that the value has been filled. Steps to Reproduce: 1. Open the Contacts app 2. Open Studio on the contact form view 3. Add the field commercial_partner_id to the form view (make it visible) 4. Create a new contact 5. Type a name 6. Select a suggestion from the IAP autocomplete 7. An error is raised immediately OPW-[5896847](https://www.odoo.com/odoo/action-4043/5896847) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures shift start and end times automatically align with the selected shift template, even when employees have fixed schedules. Previously, shifts were incorrectly calculating hours based on employee schedules, leading to inaccurate shift durations. This change corrects this behavior, providing more reliable shift planning.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509
This update prevents unnecessary error alerts when the Codabox sync process (CRON) fails due to temporary server issues. This change ensures that the sync process doesn't get disabled prematurely if the servers recover, improving reliability and automation. It addresses a previous issue where frequent errors from CRON jobs would disrupt the process.
Original PR description
In case of a failure/downtime from the IAP/Codabox servers, an error is currently being raised. Although this is useful when manually clicking the Fetch button to see what happens, in the context of a CRON it's much less desirable as multiple failures from a CRON will automatically disable it which is not useful as the servers might be back up later on. Now, instead, we only raise if we're not in a CRON environment. opw-5922549
This update resolves an issue where users in the 'Planning / User' group couldn't take open shifts. The fix ensures that the 'I Take It' button is consistently displayed for this group, allowing them to seamlessly accept shifts within the Planning app. This improves usability for a key group of users.
Original PR description
## Issue In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift. ## Steps to reproduce…
## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.
## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**
When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.
## Cause
The condition for the *I Take It* button to be displayed is the following:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283
The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716
When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636
Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.
opw-5451282This update resolves an issue where the description field in the project form was displaying duplicate content. The root cause was a default field content being incorrectly appended. This change ensures a cleaner and more accurate display of descriptions within project forms, improving the user experience.
Original PR description
Steps to reproduce: =================== 1. Go to website > contact us page 2. Submit a new task with description. 3. View the Description in the project app. -> The description field is already shown in the form by default. You will find another time it is repeated. Cause: ====== The default field content is always appended to the form content. Solution: ========= Avoid adding description to the description field content. opw-5868382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Resolved issues and error corrections
This update fixes a usability issue on mobile devices where the undo and redo buttons were hidden in the editor toolbar. The change ensures these buttons are always visible, improving the editing experience for mobile users. This enhancement streamlines the workflow and allows users to easily correct mistakes while editing content on their phones or tablets.
Original PR description
Problem: On mobile devices, the undo and redo buttons are not visible in the editor toolbar. Cause: `showHistory` is not enabled by default in mobile view, which hides the undo/redo controls. Solution: Pass `true` as the default value for `showHistory` when in mobile view, ensuring the undo/redo buttons are always visible. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 ensures timesheet entries with excessively large negative hours (over six digits) are properly flagged as errors. Previously, these entries could be added without warning, leading to potential data inaccuracies. This fix improves data integrity and prevents incorrect time tracking.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417
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-5902414