Wednesday, March 18, 2026
23 changes · saas-19.2
New functionality added to Odoo
This update introduces a new report for Polish businesses that still need to generate JPK_FA XML reports even when using the KSeF online invoicing platform. This report ensures compliance with Polish tax regulations by listing outstanding invoices and lines that haven't been validated by KSeF, aligning with JPK-FA(4) norms.
Original PR description
In Poland, if a business chooses to keep B2C invoicing outside of KSeF (online platform), the JPK_FA obligation remains. It is a XML report that lists all the invoices and the invoice lines that have not been validated by KSeF during a desired period of time. The report follows the JPK-FA(4) norms. task-5166047 Forward-Port-Of: odoo/enterprise#103000
This update adds the capability to generate UBL (Universal Business Language) receipts from Point of Sale (PoS) orders. This allows businesses to meet specific tax and regulatory requirements by creating compliant electronic invoices. The changes also improve PoS testing and remove outdated documentation.
Original PR description
task: 4038651 Forward-Port-Of: odoo/odoo#248279 Forward-Port-Of: odoo/odoo#209578
This update enables direct electronic invoicing for POS sales and returns in Colombia, streamlining the process for businesses. It avoids creating intermediate invoices and leverages existing UBL generation, improving efficiency and reducing manual steps. This change is crucial for compliance with Colombian tax regulations.
Original PR description
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App.…
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App. This pr adds the possibility to generate and send the electronic documents directly to DIAN without leaving the POS store. This pr will not create intermediate invoices/credit notes that are supposed to be sent to DIAN, instead we adapted the already existing ubl-generation implementation (in `l10n_co_dian`) to be able to generate the correct files using data from `pos.order` models (implementation can be found in `models/account_edi_xml_ubl_dian.py`). During this process we created some 'common' functions that generate data for the ubl file independent of what model is used (`account.move` or `pos.order`), these common functions are a first step for the future refactoring of the ubl models. An important thing to note here is that the common functions are only used for the pos orders, generating documents for invoices is still done using the original implementation. Another important feature of this implementation is the possibility to share a single sequence, defined on the journal, between pos orders and account moves. This was implemented because in Colombia (and other latam countries) the sequence gets assigned to a company by the government, and can therefore be expensive. Important to note is that sharing a sequence is only possible if the company has never sent documents to DIAN before (~ no existing edi documents). task-4038651 Forward-Port-Of: odoo/enterprise#107170 Forward-Port-Of: odoo/enterprise#78742
Enhancements to existing features
This update modernizes the Chinese Chart of Accounts to align with current accounting standards (ASBE and ASSBE). A key change is the introduction of dot notation in account codes, improving readability and navigation for Chinese users and aligning with local industry practices.
Original PR description
### [IMP] l10n_cn: update CoA We update the Chart of Accounts to align with the latest ASBE and ASSBE standards. Notably, this introduces the dot (.) notation in account codes to clearly signify parent-child hierarchies. This format matches local industry standards, making the accounts much easier to read and navigate for Chinese users. enterprise-[109175](https://github.com/odoo/enterprise/pull/109175) task-[5939988](https://www.odoo.com/odoo/all-tasks/5939988) Forward-Port-Of: odoo/odoo#251681
Resolved issues and error corrections
This update fixes an issue where backorders were incorrectly doubling labour costs in the accounting system. When a backorder is created, the system was inadvertently posting labour twice. The fix ensures labour costs are only recorded once per workorder time entry, preventing inaccurate financial reporting.
Original PR description
When the Manufacturing operation type is configured with Create Backorder = Always, `mrp.production.pre_button_mark_done()` re-enters `button_mark_done()` in the same server execution path. This can trigger `_post_labour()` twice, causing two posted “<MO> - Labour” journal entries and doubling labour costs in Accounting. Labour costs should be posted only once per workorder time entry. Ensure labour is only posted once by skipping workorder times that were already linked to an accounting entry. This prevents a second execution from creating a duplicate labour journal entry. A test was added to cover the partial production flow when backorder is set to “Always.” Related ticket: opw-5931754 --- Forward-Port-Of: odoo/odoo#253689 Forward-Port-Of: odoo/odoo#250237
This update brings the Balance Sheet and Profit & Loss reports for our Chinese business customers in line with the latest accounting standards (ASBE and ASSBE). The changes improve the clarity and consistency of these reports, ensuring accurate financial reporting.
Original PR description
### [IMP] l10n_cn_reports: update BS & PnL We update the Balance Sheet and Profit & Loss reports to be consistent with updated ASBE and ASSBE standards odoo-[251681](https://github.com/odoo/odoo/pull/251681) task-[5939988](https://www.odoo.com/odoo/all-tasks/5939988) --- We encountered an issue where setting `groupby = False` still resulted in an error (no groupby and children lines). This was resolved by setting a co-dependent variable `user_groupby = False`. The reports has lines with "Includes:" and sibling lines' name are expected to be aligned with it. Hierarchy lines and using various space characters (CJK space `　`, and "en" space ` `) was a maintenance nightmare. We instead chose to remove `includes:` as it's implied by the natural indentation of grouped lines. Forward-Port-Of: odoo/enterprise#109175
This update resolves an issue where downpayment products weren't correctly linked to downpayment lines in sales orders. The fix ensures that downpayment products are properly added when a downpayment is made, addressing a previous reporting problem related to settlement processing. This improves the accuracy of sales order data.
Original PR description
Step to reproduce - install pos_sale - create a SO (make sure it is in draft) - open pos, make sure it has downpayment product - do a downpayment for that SO - go to backend, open SO Observation: - The downpayment product is not linked to downpayment line Cause: - After refactor [1], downpayment product is not added in sale line [1] https://github.com/odoo/odoo/commit/175daa5db6a3f16be6b636a36e2b8462306b2eb4 Fix: - Added the product when creating downpayment line **Note:** - Actual issue reported was different, and was side effect of this issue - there, the downpayment was not considered when trying to settle SO from pos opw-5934461 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250548
A recent change in required field validation caused an error when starting a new pay run in the Hong Kong payroll module. This update ensures that date fields are validated before the system attempts to process them, resolving the 'value.toFormat is not a function' error. This prevents users from being unable to initiate pay runs.
Original PR description
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` >…
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Payslips` > `Pay Runs`. - Click `New`, remove the `period value`, and click `Continue`. `TypeError: value.toFormat is not a function` After this recent [commit] that changed the required field validation behavior, when the date field is empty and it attempts to serialize the date [1], which raises the error here [2]. Although the start and end date field is required, the ORM call is executed without the value for the date field. This commit ensures that, similar to the base PayslipBatchFormController [3], the fields are validated before making the ORM call. [commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8 [1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14 [2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536 [3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20 sentry-7207509338 Forward-Port-Of: odoo/enterprise#108885
This update enhances the way error messages are handled within the Odoo account_peppol module. Previously, messages were based solely on error codes, making debugging difficult. Now, the system captures and uses the full server error, providing more detailed information for troubleshooting and improving client support.
Original PR description
Before this commit, all messages where mapped based on the error code and not from the server error. Schematron/XSD issues really need the full error to make easy for debugging/client. OPW-5980046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252252
This update fixes a bug where the product search bar didn't function correctly on mobile devices. The issue was due to a missing configuration in the search template, which prevented the search from executing. The fix ensures that product searches work as expected across all device views, improving the user experience for mobile shoppers.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Go to `website > shop`. - Open the `Customizable Desk` product page. - From the website editor, `enable the search bar` for the product page.…
Steps to produce: --- - Install `website_sale` module. - Go to `website > shop`. - Open the `Customizable Desk` product page. - From the website editor, `enable the search bar` for the product page. - Switch to `mobile view`. - Now search for `drawer` in product search. Issue: --- - In mobile view, the search does not work. When performing a search, nothing happens, and the request is not executed. Root cause: --- - At [1], in the search template definition, the action attribute is missing in the search form. Solution: --- - Set the form action using keep(search=0) instead of leaving it undefined. - This ensures that the search behaves correctly depending on the context (global or category-scoped). [1]https://github.com/odoo/odoo/blob/51f59a293de1e86f66f30257f8fc0c419463d18c/addons/website_sale/views/templates.xml#L2239-L2259 opw-5992052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254221 Forward-Port-Of: odoo/odoo#251694
This fix resolves an issue where orders created through the MPS weren't consistently grouped into single RFQs, leading to duplicate RFQs being generated. The update ensures that the system correctly handles date formats when searching for existing purchase orders, preventing the creation of new POs unnecessarily. This improves order management efficiency.
Original PR description
Issue ----- Orders created through the MPS aren't grouped in a single RFQ. Steps to reproduce ----- - Create a product with a vendor - Add it to the MPS with the buy route - Change the forecast to 2…
Issue ----- Orders created through the MPS aren't grouped in a single RFQ. Steps to reproduce ----- - Create a product with a vendor - Add it to the MPS with the buy route - Change the forecast to 2 - Order - Change the forecast to 5 - Order - Go to RFQs > There are 2 different RFQs Cause ----- When doing `_run_buy`, no existing PO is found https://github.com/odoo/odoo/blob/98e3020bcffaf449291d1e6664ba613761f37331/addons/purchase_stock/models/stock_rule.py#L102 so a new one gets created. The reason why the existing PO is not found is because we add `date_planned_mps` to the search domain https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/stock_rule.py#L10-L15 However, `values['date_planned']` is a datetime.date, whereas `date_planned_mps` is a datetime.datetime in DB. https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/purchase_order.py#L10 This poses some problems with timezones, as the client and db dates might differ. We can avoid the problem by converting the date to datetime. ----- Ticket: opw-5171041 Forward-Port-Of: odoo/enterprise#106968
This update resolves an issue where the Documents Activity view became unusable after exiting Studio, preventing users from filtering or adding new activities. The fix ensures the view correctly loads necessary data, restoring full functionality and preventing frustrating user experiences.
Original PR description
Problem: When returning to the Documents Activity view after closing Studio, the view becomes unusable with an error that `folderId` is `undefined`. Users are forced to refresh the page or switch…
Problem: When returning to the Documents Activity view after closing Studio, the view becomes unusable with an error that `folderId` is `undefined`. Users are forced to refresh the page or switch views to fix it. Specifically: - Filters can no longer be selected. - Adding new activities throws UI errors (even if technically successful). Cause: The `getSelectedFolder` method returned undefined because the `searchPanel` logic was skipped. The Activity view does not display the `searchPanel`, so the model failed to run `_fetchSections` which retrieves the data used by `getSelectedFolder`. Under normal circumstances, the view relies on data already loaded by the Kanban or List views, but that data is unavailable here. Solution: - Force the search model to load the data explicitly, ensuring the view initializes correctly regardless of the `searchPanel` visibility. We kept the dependency upon `_fetchSections` rather than removing it, as it is required by the `search_model` to maintain other features like `breadcrumbs`. - Add a test to verify the fix and prevent regression. Co-authored-by: Pierre-Yves Dufays <pydu@odoo.com> Co-authored-by: Charlier Florian <flch@odoo.com>
This update resolves an error that occurred when users attempted to change the employee within the salary simulation feature. The fix ensures the system correctly handles versioning during this process, preventing a runtime error. This improves the stability and usability of the salary simulation functionality.
Original PR description
Currently, an error occurs when user tries to change simulation employee in salary simulation. Steps to replicate: - Install `hr_contract_salary_payroll` with demo. - Open any employee (e.g.- Abigail…
Currently, an error occurs when user tries to change simulation employee in salary simulation.
Steps to replicate:
- Install `hr_contract_salary_payroll` with demo.
- Open any employee (e.g.- Abigail Peterson).
- Click `Simulation` > Change `Yearly Employer Cost` to `Gross Per Month`.
- Try to change the Employee, error will occur.
Error:
```
File '/home/odoo/odoo19/enterprise/hr_contract_salary_payroll/models/hr_contract_salary_offer.py', line 157, in _compute_offer_values_from_template
version = offer._get_version()
^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo19/enterprise/hr_contract_salary/utils/hr_version.py', line 39, in hr_version_context_wrapper
raise RuntimeError(
RuntimeError: Method '_get_version' must be called within a savepoint context. Use `hr_version_context(...)` context manager before calling this method.
```
Cause:
- The method `_get_version()` has the decorator `@requires_hr_version_context()` which makes the method to be callable within a savepoint context for `hr.version` [1] i.e. it can only be called within a `hr_version_context()` block.
- As here the method was not called under the `hr_version_context()`it raises an error from [here].
Solution:
- Used the `hr_version_context()`block instead of savepoint (similar to [this]).
[this]: https://github.com/odoo/enterprise/pull/108005/changes#diff-97aeb940d5058abc95cb617e5a2015320c37e8d50a15cffc2c08eac1839ac16dL98-R100
[here]: https://github.com/odoo/enterprise/blob/626598abe4fdbc8391a428928e197e7735cbb298/hr_contract_salary/utils/hr_version.py#L39-L42
[1]: https://github.com/odoo/enterprise/blob/626598abe4fdbc8391a428928e197e7735cbb298/hr_contract_salary/utils/hr_version.py#L14-L17
sentry-7335824597This update fixes a problem causing incorrect stock synchronization for Amazon listings, leading to phantom orders. The solution allows users to manually specify the fulfillment channel (FBA or FBM) for each listing, resolving a known Amazon issue and improving order accuracy. This ensures correct stock management and prevents revenue loss.
Original PR description
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and…
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662
This update fixes a discrepancy in invoice status after SDI validation for Italian tax invoices. Previously, the system didn't automatically update the invoice's status to reflect the Public Administration's (PA) state, leading to potential rejection issues. This change ensures accurate status tracking and prevents invoices from being incorrectly flagged as rejected.
Original PR description
### Issue: After the SDI validation, the state was never updated to match the PA state, resulting in a mismatch with the actual status ### Cause: When `l10n_it_edi_state` is set to `forwarded`, the cron `cron_l10n_it_edi_download_and_update` doesn't consider that a new state could occur However, invoices sent to Public Administration can still be rejected after being forwarded It is not possible to reproduce the issue with the demo system, as it only sets the state to `forwarded` Ticket [link](https://www.odoo.com/odoo/project.task/5391891) opw-5391891 Forward-Port-Of: odoo/odoo#254406 Forward-Port-Of: odoo/odoo#253525
This update corrects a bug in the DIAN invoice processing workflow. Previously, the system incorrectly deleted the original invoice document, potentially leading to data loss. This fix ensures the correct invoice document is protected during the update process, maintaining data integrity.
Original PR description
**PROBLEM** In some configurations, `_l10n_co_dian_cron_update_event_status()` would delete the original document of the invoice. **CAUSE** The logic that tried to exclude the original document from the code that unlinks duplicated documents is wrong. It protect the oldest document of `self` instead of `move`. So the document of the move we are currently working on is not protected, and could be deleted. **STEP TO REPRODUCE** 1. Setup DIAN. 2. Create multiples invoices and send them to DIAN. 3. Run _l10n_co_dian_cron_update_event_status() If the original document of the invoice have the same commercial_status as some other document, it could be destroyed. opw-5447147 Forward-Port-Of: odoo/enterprise#110455
This update fixes an issue where time off leaves were incorrectly displaying instead of accurate return dates. The change ensures that employee profiles now show the correct return date for worked-time leaves, improving the accuracy of leave scheduling and reporting.
Original PR description
Issue: - When a time off type was configured as , adding a leave for today caused the employee form to display instead of a real date. Fix: - Compute leave dates for all validated leaves, including worked-time leaves. - Ensure the date is always computed using the first working interval after the leave end date. Impact: - Employee profiles now display a correct return date for worked-time leaves. task-5421688 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#254040 Forward-Port-Of: odoo/odoo#241329
This update resolves an issue where users on Firefox couldn't hear incoming calls through their softphones. The fix ensures the system correctly processes incoming call tracks as soon as they're available, regardless of the session establishment timing. This improves the Odoo VoIP functionality for Firefox users.
Original PR description
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the…
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the call, answer => The caller can hear you but you cannot hear the caller. This happens since [1]. Before that commit, we had something like "when the session is established, listen to tracks being added to the call and also set up the audio". After that commit, this became "when the session is established *or is establishing*, listen to tracks being added to the call... *but don't set up the audio otherwise*". The problem is that on Firefox, the timing is such as the tracks of incoming calls are being added just before the session is establishing (or established), meaning we listen to tracks being added too late. Note that commit [1] was further diluted afterwards by commits like [2] (doing stuff with the audio before establishing) and [3] (which simply removed the "established" part, relying on "establishing" being done). Later on, commit [4] prepared some other work by moving and improving things around and it actually fixed this issue here by chance. What did the trick is listening to tracks being added from the start: as soon as SIP.js notifies that the remote stream exists. This commit fixes the issue in impacted versions (19.1 and 19.2) by backporting the relevant part: listening to tracks being added as soon as possible and not once establishing/established. A test was added. [1]: https://github.com/odoo/enterprise/commit/d24d7f3406ca47e7ac529d69957b0ad481d553bf [2]: https://github.com/odoo/enterprise/commit/71d78810ae7f6c9169912276da18e04ad4f7bef0 [3]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e [4]: https://github.com/odoo/enterprise/commit/33fc327c1c74ee874d546a98879dbbf468809850 task-5902700 Forward-Port-Of: odoo/enterprise#110833
This update resolves issues related to physical card processing, specifically for UK users, improving the reliability of expense tracking. It includes fixes for missing ETA information and shipping status errors, ensuring accurate expense reporting and preventing test failures.
Original PR description
Forward-Port-Of: odoo/enterprise#110263
This update resolves issues where the AI chat experienced unexpected errors and crashes, providing a better user experience. Now, the AI chat displays informative messages like 'oops' or 'Connection Interrupted' when errors occur, ensuring smoother operation and preventing data loss during interruptions.
Original PR description
Steps to reproduce: 1. Open the Website Editor 2. Select some text 3. Click the AI tool from the toolbar 4. Send a message in the chat window 5. Observe a non-standard error dialog showing 500 HTTP…
Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error
The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.
This commit improves error handling for both public and internal AI chat
by:
- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.
The following behavior will now be observed during error in the UI.
- Public AI chat:
- Initial fetch failed: shows "oops" message
- Stream interrupted:
- Server handled: shows "oops" message
- Server stopped: shows "Connection Interrupted" dialog
- Internal AI chat:
- Initial fetch failed: show RPCError dialog
- Stream interrupted:
- Server handled: shows RPCError dialog
- Server stopped: shows "Connection Interrupted" dialog
We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.
TASK-ID: 5886825
Forward-Port-Of: odoo/enterprise#105875This update fixes an error in the calculation of the mobility budget for Belgian HR contracts. The previous calculation incorrectly treated the budget as a fixed amount instead of a percentage, leading to inaccurate cost projections. This change ensures the yearly mobility budget cost is computed correctly, providing more reliable financial reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#110827
This update resolves an issue related to currency reconciliation in stock valuation processes. The changes streamline testing for accurate valuation calculations, particularly concerning invoice and purchase order impacts, ensuring consistent and reliable financial reporting. This improves the stability and accuracy of the purchase stock module.
Original PR description
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#246101 Forward-Port-Of: odoo/odoo#245551
This update fixes a calculation error related to leave allocations that don't have a defined end date. Previously, the system incorrectly tracked taken hours when allocations were open-ended. Now, allocations without end dates are treated as continuous, ensuring accurate leave hour calculations across all reports.
Original PR description
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after…
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after each allocation start date - Compare the number of hours remaining for the allocations' employee in his time off dashboard and in the Balance report. ### Cause: After this commit https://github.com/odoo/odoo/pull/245860/changes/d9bb4d206e91d10eac7311adede307b8c5019213 we changed the way we match leaves with allocations but we were strict that the leave has to lie in between the allocation dates and this created a wrong accumlated taken_hours in the taken_per_allocation subquery. ### Fix: Following the same approach we use in if the allocation has no expiry date we don't check if the leave.date_to > allocation.date_from as we are going to treat all allocations as they form one big allocation that started in the earliest start date opw-5474596 Forward-Port-Of: odoo/odoo#254053 Forward-Port-Of: odoo/odoo#250432