Daily updates from Odoo
Tuesday, February 17, 2026
40 changes · master
Resolved issues and error corrections
A recent change in how salary rules are defined in Odoo Enterprise caused issues with generating payroll reports, specifically PDFs. This update corrects the underlying logic to properly handle the new salary rule category structure, ensuring reports like the Yearly Salary by Employee and Salary Statements are generated without errors.
Original PR description
Issue: - Payroll reports were crashing or failing to generate PDFs. - This started after salary rule category was changed from `category_id` to `category_ids`. Fix: - Updated report queries and salary statement logic to use the new salary rule category relation (`category_ids`). - Fixed grouping and deduction checks to match the new structure. Impact: - Yearly Salary by Employee report now prints without errors. - Salary Statement PDFs are generated correctly. Task: 5886956
This update ensures accurate reporting of work accidents for employees on PFI (IVT) and Apprenticeship (ALT) contracts. It now issues a warning when 'Paid Work Accident' entries are used, prompting the correct selection of 'Unpaid Work Accident' entries, aligning with Belgian payroll regulations.
Original PR description
For PFI (IVT) and Apprenticeship (ALT) contracts, work accidents are not paid by the employer. If an employee with Dimona category **ALT** or **IVT** has work entries of type "Work Accident (Paid)" (LEAVE115), a warning issue is raised to inform the user that "Work Accident (Unpaid)" (LEAVE117) should be used instead. task: 5484866
This update resolves a potential issue with salary rule configurations. By clearing category IDs from salary rules, the system becomes more stable and easier to update without causing conflicts. This ensures smoother future maintenance and avoids disruptions to payroll processing.
Original PR description
We should clear category_ids on salary rules to avoid any issues if an update is required. task-5942496
This update restores the anonymization of journal entries within the HR Payroll module. Previously, certain financial records were not properly masked, which is now corrected. This ensures compliance with accounting regulations and improves data privacy.
Original PR description
Task: 5852493
This update resolves a problem where test environments were using the incorrect timezone. The fix was identified through automated build errors and ensures that test results accurately reflect the intended timezones. This improves the reliability of our testing process.
Original PR description
* = appointment, project_enterprise_hr This commit fixes a timezone wrongly setup in a test. Related Runbot Build Errors: - https://runbot.odoo.com/odoo/runbot.build.error/238019 - https://runbot.odoo.com/odoo/runbot.build.error/238021 task-5890477
This update adjusts the timeframe considered a 'relapse' for sick leave calculations, aligning with new Belgian tax regulations. Starting January 1, 2026, the period between sick leave occurrences will be 56 days instead of 14, ensuring accurate payroll reporting. The change includes updated logic and testing to reflect this new standard.
Original PR description
Spec :- Since 01/01/2026, the period between two sick time off to consider it as a relapse has been increased from 14 days to 56 days. Implementation :- . Update sickness relapse period from 14 to 56 days if the leave starts from 2026 . Add leave work_entry type where work_entry use date_start . Add corresponding tests task-5476174 Forward-Port-Of: odoo/enterprise#107294 Forward-Port-Of: odoo/enterprise#104782
This update resolves a bug that prevented invoices with lines having a product price of zero from being saved correctly. The fix ensures that required tax object fields are properly populated, allowing invoices with zero-priced items to be saved without errors. This improves invoice creation functionality for Mexican clients.
Original PR description
**PROBLEM** If you create an invoice, and add a line with a product with a price of 0, you cannot save the invoice. **STEP TO REPRODUCE** 1. On a mx company, create an invoice for a mx client. 2. Add a line with a product with a price of 0. 3. Try saving the invoice, it will fails. **CAUSE** Field `l10n_mx_edi_tax_object` is required on invoice line with mx company. However, for lines with a price of 0, it is not set by `_compute_l10n_mx_edi_tax_object` because `_l10n_mx_edi_cfdi_invoice_line_ids()` filters them. opw-5402045 Forward-Port-Of: odoo/enterprise#103981
This update resolves an issue where feedback wasn't properly recorded when approving approvals through activities. Recent changes inadvertently broke the feature, preventing feedback from being posted. Now, feedback is correctly attached as a message when an approval is completed.
Original PR description
Approving an approval via an activity with feedback did not work properly as the feedback was never posted. This was due to the consecutive refactoring that broke the feature. After this commit, the feedback is posted as a message opw-5782803 Forward-Port-Of: odoo/enterprise#106185
This update corrects an issue where payslip calculations were sometimes inaccurate, particularly after updates to payroll data. The fix ensures that net pay is computed correctly, resolving a technical problem identified through automated testing. This improves the reliability of payroll reporting for our Chinese clients.
Original PR description
Related runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/237852 Task-5881260 Forward-Port-Of: odoo/enterprise#106341
This update fixes an issue with how withholding taxes are reported in Spanish accounting. Specifically, the 'type for 347' field in certain accounting moves has been corrected to be blank, aligning with Spanish tax regulations. This ensures accurate reporting and compliance.
Original PR description
- Moves that use withholding taxes should have the `type for 347` unselected and left blank. Related PR : https://github.com/odoo/odoo/pull/245828 task-5732679 Forward-Port-Of: odoo/enterprise#106889 Forward-Port-Of: odoo/enterprise#105597
This update fixes an issue where invoices generated for Ecuador (l10n_ec) were incorrectly creating discount lines due to rounding differences during tax calculations. The change aligns the XML generation process with Mexico (l10n_mx) to ensure accurate negative line handling and proper discount application, improving invoice accuracy.
Original PR description
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can…
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased. ## Steps to reproduce With **l10n_ec**: 1. Change the decimal accuracy to 6 digits. 2. Set the rounding method to *global rounding*. 3. Create an invoice with the following lines: | Quantity | Price | Taxes | |-----------|----------|-----------| | 20 | 1.4235 | VAT 0% G | | 20 | 1.6425 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.4235 | VAT 0% G | | 6 | 3.747768 | VAT 15% G | | 6 | 3.747768 | VAT 15% G | In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`. This happens due to rounding differences in how the `descuento` is computed in the `common_details_info_template` from **l10n_ec_edi**: format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount']) where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere. This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**. Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed. opw-5128612 Forward-Port-Of: odoo/enterprise#104659 Forward-Port-Of: odoo/enterprise#97337
A minor bug in the knowledge calendar tour was preventing it from finishing correctly. This PR corrects a reference to a button, ensuring the tour completes as intended. This resolves a test failure and improves the overall user experience for the knowledge calendar feature.
Original PR description
In test_knowledge_calendar_command_tour there was a miss-referenced button towards the end. This caused the tour to fail because it didn't find the button to click. With this PR we correctly reference the button and allow the tour to finish. Runbot Error: 234898 Forward-Port-Of: odoo/enterprise#105354
This update resolves a potential issue in the HR payroll system where validated work entries could incorrectly trigger conflicts. A new conflict state has been added to accurately reflect situations where days have been validated, streamlining payroll processing and reducing manual intervention. This ensures more reliable and accurate payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#101803
This update resolves an issue where users selecting time off by hours were seeing "InvalidDateTime" instead of the correct start and end times. This was caused by a recent change in how date/time formatting is handled. Now, the system correctly displays the selected time off hours.
Original PR description
**Issue:** - When users selected time off based on hours, "InvalidDateTime" was shown instead of the correct "From" and "To" time. This happened after a recent refactor:https://github.com/odoo/odoo/pull/240555/changes#diff-0beecbb730e1c7762f2a8d5f7038c02e123da10a85dec2e5d16a02748373f2fe of getFormatValue, which now returns DateTime in a different format than before. **Fix:** - Updated the method and adapt the new refactored format. **Impact:** - The correct DateTime values are now displayed instead of "InvalidDateTime". Task-5940185
This update adjusts how Odoo checks for product tracking, specifically for service products. A recent change allows service products to have tracking set to 'False' instead of 'none'. This update ensures that checks previously targeting 'none' now correctly identify service products without tracking, preventing inaccurate tracking assignments.
Original PR description
Adapt tracking checks to handle the new tracking=False value for service products. After the change in odoo/odoo that allows tracking to be False for non-storable products, we need to update all checks that were comparing tracking to 'none'. Service products now have tracking=False instead of tracking='none', so checks like `tracking != 'none'` were incorrectly treating them as tracked products. Updated checks in: - industry_fsm_stock: serial_missing compute, action_assign_serial - mrp_workorder: UI visibility logic for tracked products Task-5446456
This update resolves an issue where Amazon FBM pickings wouldn't validate properly, leading to delays and errors. Now, deliveries can be validated regardless of missing carrier information, and any resulting sync issues are handled efficiently with error reporting. This ensures smoother integration with Amazon.
Original PR description
Before this commit: - Amazon FBM pickings fail to validate if carrier or tracking reference is missing, blocking test flows, and causing infinite delivery retry loops. After this commit: - Pickings can be validated regardless of missing carrier or tracking info. - Sync issues are deferred to `sync_feed` and flagged via error reporting. - Supports retryable and observable sync logic, enabling test and edge-case flows. task-4789260 SEE also: Community PR:https://github.com/odoo/odoo/pull/213908
This update resolves an issue where users encountered an error when editing reconciled invoice lines within the Bank journal. The fix initializes necessary variables to avoid a runtime error, ensuring users can now successfully adjust these lines without disruption.
Original PR description
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting`…
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting` module. - Create an `invoice` with an `invoice line` having an amount greater than zero. - `Confirm` the invoice. - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice. - Click `Reconcile` on that `statement line` and select the newly `created invoice line`. - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save. `UnboundLocalError: local variable 'original_base_lines' referenced before assignment` The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2]. This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error. [1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394 [2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411 sentry-7189027839 Forward-Port-Of: odoo/enterprise#107454 Forward-Port-Of: odoo/enterprise#104432
This update corrects a technical issue in the account reports module that was causing errors related to invalid record IDs. The fix filters out incorrect 'falsy' IDs, ensuring the reports display accurate data and prevents potential system instability. This improves the reliability of financial reporting.
Original PR description
Previously, get_unknown_partner_aml_ids collected AML IDs and included falsy IDs from the total lines. For a while, this had no side effects. However, in commit 4290724, the odoo/orm/models.py browse method was changed to disallow browsing for falsy IDs. get_unknown_partner_aml_ids has been caught by this and needs to not include total lines to prevent adding lines with no res_id. A simple option to ignore total lines fixes this issue. Steps to replicate: Create and post a journal entry with a line for accounts receivable Open Accounting > Tax Returns > Error (Invalid falsy real id) task: 5919319 Browse Change PR: 227477 Forward-Port-Of: odoo/enterprise#107458
This pull request restores the previous calculation of holiday accrual based on a two-week period in the Belgian HR payroll module. The removal of this feature was previously implemented, and this change reverts that change, ensuring accurate and compliant holiday calculations for Belgian employees. This ensures consistent payroll processing.
This update corrects a recent issue where uploading new templates disrupted the connection between activities and their associated sign requests. The fix ensures that sign requests remain properly linked to activities, streamlining the workflow for users managing document signatures. This resolves a disruption in the activity revamp feature.
Original PR description
This hotfix resolves an issue introduced in the activity revamp feature that caused the link between the activity and its sign request to break when a new template was uploaded via the upload button. task-5379922
This update adjusts the layout of the HR leave form to place dates above time off types, enhancing usability. Additionally, a technical adjustment was made to resolve an issue caused by removing attachments from the form view. This ensures the form functions correctly.
Original PR description
In the enterprise PR, the order of time off type and dates was swapped, to have the date above the type. Also, the attachments were removed from the normal form view, since it would be redundant. This PR fixes an xpath issue that happened due to removing that field. task-5008161
This update ensures that a key automated report process in the Odoo Enterprise system continues to run correctly after updates. Previously, the cron job was disabled upon module upgrades due to a missing configuration setting. Adding the 'noupdate' attribute prevents this disabling, preserving user-defined settings and ensuring reliable report generation.
Original PR description
Currently, the 'Fetch E-Invoice detail bill' cron is set to active=False in the XML, but lacks the noupdate=1 attribute. This causes the cron to be disabled every time the module is updated. By wrapping the record in <data noupdate=1>, we ensure that user-defined configurations (active status, frequency, etc.) are preserved across module upgrades. task-5885482
This update adjusts the automated tour test to reflect a recent change in the label of the payrun button, which was updated from 'Confirm' to 'Validate'. This ensures the tour test accurately reflects the current user interface and functionality.
Original PR description
The payrun button label was changed from "Confirm" to "Validate" (task-5376223), this commit is simply adapting the tour test to the previous change task-5942337
This update resolves an issue where selecting 'Local Gaap' in account reporting incorrectly switched the selection states of multiple journals. Now, selecting 'Local Gaap' consistently includes all local gaap journals regardless of their previous state, ensuring accurate reporting.
Original PR description
When installing the 'account_transfer' module, the tests of 'test_account_reports_journal_filter' failed because the tests took into account the demo journal group created in the module. Also, fixing a problem with the selection of the group 'Local Gaap'. Before this PR: When some of the local gaap journals are selected but not all of them, selecting 'Local Gaap' switched all the selected states of the journals. Those who were selected are not, and those who were not are. After this PR: When selecting 'Local Gaap', all the local gaap journals are selected, no matter their state before. task-5404526
This update ensures the OCR functionality correctly processes receipts, addressing a previous bug where it wasn't available. Previously, setting an invoice as a receipt wouldn't trigger the 'Digitize document' button. This fix now accurately identifies receipts and ensures correct tax calculations for sale receipts, resolving a potential issue with purchase taxes being applied.
Original PR description
Since the OCR is available on receipts (commit a7e9575), the calls to `is_purchase_document`/`is_sale_document`/`is_invoice` need to have the `include_receipts` parameter set to `True` to return an accurate value. This was omitted in the original commit and later fixed in commit 0dc9352, but only for calls to `is_purchase_document`. This commit fixes it for calls to `is_sale_document` and `is_invoice`. The missing parameters caused the following bugs: - OCR not available on receipts, i.e. if the user manually sets the invoice as a receipt, the "Digitize document" button was there, but it wouldn't work. - Purchase taxes would be used instead of sale taxes for sale receipts. These use cases aren't very common, probably why there was no ticket to report it. task-none Forward-Port-Of: odoo/enterprise#107272
This update corrects an issue where rental order display names were failing due to a blank delivery contact name. The fix utilizes the partner's `display_name` instead, ensuring consistent and accurate name formatting for rental orders. This prevents errors and improves the user experience.
Original PR description
Steps to produce: --- - Install `sale_renting` and `contacts` modules. - Go to contact and open `yourcompany` record. - Add a new contact of type Delivery and save (leave the name empty). - Go to…
Steps to produce: --- - Install `sale_renting` and `contacts` modules. - Go to contact and open `yourcompany` record. - Add a new contact of type Delivery and save (leave the name empty). - Go to Rental > New Order. - Select YourCompany, Delivery as the customer. - Add a rental product and confirm the order. - Open the Schedule view. Traceback: --- `TypeError: sequence item 0: expected str instance, bool found`. Root cause: --- - At [1], the system tries to use the customer's name when computing the display name. However, in this case, the delivery contact has no name, resulting in a False value. This False value is then included in the description list, causing the TypeError when joining the sequence. Solution: --- - Use the partner's `display_name` instead of `name`. The `name` field can be `False` in some cases. The `display_name` field is a computed field that always provides a valid, formatted string by using fallback values such as the company name, parent name, or contact type. This ensures consistency and prevents errors [1] https://github.com/odoo/enterprise/blob/f5fea1d7b40e42b7bc1c323cc9613b1aa347da09/sale_renting/models/sale_order_line.py#L61 opw-5914084 --- Forward-Port-Of: odoo/enterprise#107451 Forward-Port-Of: odoo/enterprise#106827
This update resolves several critical issues impacting the accuracy of Single Touch Payroll reporting in Australia. Specifically, it corrects rounding errors, improves opening balance imports, and addresses date discrepancies, ensuring more reliable payroll calculations and compliance.
Original PR description
- Unable to import opening balances when zeroed out. This should not require Previous Payroll and BMS IDs - Float creates an overflow while computing the YTD sums, which results in too many digits in decimal places. Round all monetary amounts reported to the rounding precision of the currency. - Issues with run date and submit dates for the prior fiscal year. - Fix payslips computation on update actions post finalisation Task - 5685790 Forward-Port-Of: odoo/enterprise#105952
This update corrects a minor issue in the VoIP unit tests, ensuring they accurately verify expected behavior. The change replaced a misleading assertion with a more precise one, improving test reliability and streamlining the code.
Original PR description
Introduced by [1]. The use of `:value()` is always truthy, making that assertion useless in the related unit test. Replaced by `:empty` as intended and took the opportunity to remove the non-required extra assertion around that code. [1]: https://github.com/odoo/enterprise/commit/0ff7c35c266c547ed3cc63155ffba54727d43c07 Forward-Port-Of: odoo/enterprise#106739
This update fixes a minor issue where the Employer File Number field was hidden in the payroll settings after installing the l10n_hk_hr_payroll_empf module. The fix removes the setting that previously obscured this important data, ensuring it's now readily accessible for accurate payroll reporting.
Original PR description
Issue: - Employer File Number was hidden in Payroll settings after installing the l10n_hk_hr_payroll_empf module. Fix: - Removed the setting that hid the Employer File Number field. task-5476454 Forward-Port-Of: odoo/enterprise#103987
This update resolves issues preventing conflicts in rental scheduling, ensuring resources are correctly allocated and avoiding errors related to double-booking. Specifically, the system now validates date changes to rental shifts, preventing conflicts and ensuring accurate resource availability. These fixes improve the reliability of the rental planning process.
Original PR description
## [FIX] sale_renting_planning: prevent user to do a conflict with rental shift Before this commit, the user could update the shift linked to a rental order and creating a conflict with another shift…
## [FIX] sale_renting_planning: prevent user to do a conflict with rental shift Before this commit, the user could update the shift linked to a rental order and creating a conflict with another shift for the same resource and so, it would be impossible for the resource to be in 2 spaces at the same time (or it is impossible to rent a room to 2 different customers). This commit returns an Validation Error if the user updates the planned dates of a rental shift and creates a conflict. ## [FIX] sale_renting_planning: add problematic shifts only if rental order Before this commit, the previous fix making sure the error, saying no resource is available during the generation of a shifts when the user confirms a sale order, is only displayed when the `Sync Shifts and Rental Orders` is enabled, could potentially never display the error when it should be expected because we only check if the last SOL of the batch to generate shifts has the feature enable or not. This commit makes sure the error is correctly displayed as expected. ## [FIX] sale_renting_planning: update condition of Rental buttons in shift Before this commit, the user could click on Create order button for an open shift is the role having the rental feature enabled. To problem is a resource is required to make sure the rental order can be delivered. About the other button shown, `Add to Last Order` one, this one could be clicked even if the shift is in conflict with another shift and so, it will display a warning saying no resource is available. This commit makes sure - `Create Order` button in shift form view is not visible when the shift is a open shift. - `Create Order` and `Add to Last Order` buttons in shift form view are not displayed when the shift is in conflict. task-5065930 Forward-Port-Of: odoo/enterprise#97024
This update resolves an issue where manual deletion of WhatsApp templates during production upgrades caused database migration blocks. By adding a safety check, the system now gracefully handles missing templates instead of throwing an error, ensuring smoother and more reliable upgrades.
Original PR description
Issue: ------ The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6)…
Issue:
------
The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6) phase. This occurred because several `ir.config_parameter` records used `ref()` to point to [whatsapp templates](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml) that were manually deleted in the production environment.
ValueError is raised:
```py
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: whatsapp_sign.sign_request_whatsapp_template
```
Cause:
-------
Since these whatsapp templates are defined with [`forcecreate="0"`](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml#L3), Odoo does not recreate them automatically during migration. This left the External IDs (IMD) pointing to non-existent records, causing a `ValueError: External ID not found in the system` that blocked the migration.
Solution:
-----------
Updated the `ref()` calls in the XML for these configuration parameters to include `raise_if_not_found=False`. This allows the registry to initialize successfully by returning None instead of crashing if a template is missing.
tgb: [2448](https://upgrade.odoo.com/odoo/tbg/2448?debug=1)
upg: [3895200](https://upgrade.odoo.com/odoo/upgrade.request/3895200?debug=1)
opw: [5931388](https://www.odoo.com/odoo/project/70/tasks/5931388?debug=1)
Forward-Port-Of: odoo/enterprise#107477This update fixes an issue where duplicate DateV identifiers could be assigned to partners, even after archiving. The change ensures that a validation error is triggered when attempting to use a DateV ID already assigned to a partner, regardless of its archived status. This prevents data inconsistencies and improves reporting accuracy.
Original PR description
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later…
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived. ### **Steps to reproduce:** 1) Install **l10n_de_reports, Contacts** App with Demo Data. 2) Switch to a **DE company**. 3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 4) Archive 'Test-A'. 5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 6) Unarchive 'Test-A'. ### **Observed Behavior:** 'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier. ### **Expected Behavior:** A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined. ### **Root Cause:** Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint. However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions. Fix: Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones. opw-5474106 Forward-Port-Of: odoo/enterprise#106146
This update enhances the payroll system by allowing users to directly edit time off records through a new, interactive Gantt view. Previously, time off records were only viewable in a non-editable format. This change provides greater flexibility and control for HR teams managing employee time off.
Original PR description
In this commit, Update Payroll > Time Offs action to open the management gantt view, allowing users to review and edit time off records instead of a non-editable view. Task-5941094
This update fixes an issue where the number of employees flagged with invalid bank account warnings on the payroll dashboard was inaccurate when employees had multiple payroll versions. The fix ensures a more precise count of employees with incorrect bank account information, improving the accuracy of payroll reporting.
Original PR description
description: - `warning_count` for `hr_payroll_dashboard_warning_employee_invalid_bank_account` is wrong when there are multiple versions for a single employee. steps to reproduce: - install `hr_payroll_account_iso20022` - open Payroll (note: have atleast one employee with multiple versions) - find "Employees With Invalid IBAN Bank Accounts" warning on the dashboard - note the count and click on it, the record count differs fix: - returned unique employee ids from `_get_invalid_iban_employee_ids` - also optimized the query in `_get_account_holder_employees_data` method. reasoning: we do not need bank account data from all the versions, because all the versions share same bank account data. task-5407494 Forward-Port-Of: odoo/enterprise#101678
This update resolves an issue where the selected journal wasn't reflected when viewing journal items within the general ledger report. Now, when you filter by a journal, the 'Journal Items' view correctly displays both the related invoices and the corresponding journal entry. This ensures accurate reporting and analysis of financial data.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update fixes an issue where the activity menu in web_studio was incorrectly displaying all records for custom models instead of just those associated with the current user. Now, the activity menu filters records to show only those with activities assigned to the user, improving the user experience and data accuracy.
Original PR description
After commit odoo/odoo@5c5fbc10b7024c7227f03e37897d421bba64df82 , actions spawned by the activities menu have their domain managed by dynamic <filter /> rather than a plain readonly domain. Before this commit, clicking on the activity menu to go to a custom model showed every record, not just ones with activities after this commit, only records with activities assigned to the current user are showed opw-5778806 Forward-Port-Of: odoo/enterprise#107277 Forward-Port-Of: odoo/enterprise#106622
This update fixes a misleading error message displayed when validating Argentine electronic invoices (ARCA). The message has been corrected to accurately reflect the requirement that the invoice date cannot be before the last validated invoice, preventing incorrect invoice processing. This ensures compliance with AFIP regulations.
Original PR description
WSFE error 10016-1 must be "The invoice date cannot be before the last invoice validated in AFIP." instead of "The invoice date cannot be after the last invoice validated in AFIP". Steps to reproduce: validate argentinean customer electronic invoice with invoice date before than the last invoice date validated in ARCA. Task Adhoc side: 44290 Task latam: 1376 Forward-Port-Of: odoo/enterprise#106687 Forward-Port-Of: odoo/enterprise#106305
This update fixes a reporting issue by ensuring that all partners, including those without VAT numbers, are included in the inf-a and inf-b reports. It also harmonizes warning messages related to VAT data, providing clearer insights for businesses and improving the accuracy of financial reports.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/" Forward-Port-Of: odoo/enterprise#106954
This update resolves a bug where the VoIP call history scrolling feature was not functioning correctly in Chrome. The fix addresses an issue with how the system detects the end of the scrolling list, ensuring that all recent calls are displayed. This improves the user experience for accessing call history.
Original PR description
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to…
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to the end => You are stuck seeing only the 13 last calls. This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration. This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item. Note that [1] disabled a test that was testing the feature. This commit of course re-enables it. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#106768 Forward-Port-Of: odoo/enterprise#106658
A recent update to the Odoo IoT device functionality caused a traceback when users attempted to change keyboard layouts. This fix resolves the issue, ensuring that keyboard layouts are now updated successfully as expected. This prevents disruptions to users interacting with IoT devices through the Odoo backend.
Original PR description
Steps to reproduce: - Connect an IoT box - Connect a USB keyboard to the IoT box - In the Odoo backend, attempt to change the keyboard layout of the keyboard device EXPECTED behaviour: Layout is updated successfully ACTUAL behaviour: Traceback occurs Forward-Port-Of: odoo/enterprise#107483