Daily updates from Odoo
Thursday, June 25, 2026
44 changes · saas-19.3
Enhancements to existing features
This update introduces a new automated process that runs every Sunday to reset configuration settings related to development tools (devtools). This ensures that features temporarily disabled for production environments are automatically re-enabled before the weekly update on Monday, streamlining the update process.
Original PR description
We add a new cron to re enable disabled features by unsetting devtools keys in configuration. This cron is meant to run every sunday at the end of the day, right before the monday update. Forward-Port-Of: odoo/odoo#270306
This update automatically sends emails to companies when their Stripe connected accounts are flagged for potential restrictions due to KYC compliance. Stripe handles verification, and these emails alert businesses to address any required documentation updates, preventing account limitations. This ensures timely compliance and minimizes disruption to business operations.
Original PR description
When a company tries to create a connected account, some official documentation need to be submitted to Stripe. Stripe takes care of the KYC steps and might restrict some account which don't meet the requirements. Odoo receives the details about the error and the date of the restriction. This task aims at sending automatic emails to the said companies to let them know that they need to fix the identified issues. task: 5441662 Forward-Port-Of: odoo/enterprise#107918
Resolved issues and error corrections
This change removes an unnecessary price check from the Peru POS refund test tour. It matters because the tour could fail when the POS configuration currency differed from the company currency, even though the price was not relevant to the workflow being tested.
Original PR description
Before this commit, the tour was checking the price of an article which was not the good one since the currency of the config was not the same as the company one. This commit removes the check of the price which is not even relevant for the tour.
The self-invoicing URL shown on point-of-sale receipts is now generated correctly instead of appearing as an invalid link. This helps customers access their invoice request page without confusion or extra support.
Original PR description
Before this commit: ------------------------- - The self-invoicing URL on the receipt was displayed as `undefined/pos/ticket`. After this commit: ------------------------- - The self-invoicing URL is now generated correctly and displayed properly on the receipt. Task-6271261 Forward-Port-Of: odoo/odoo#271762 Forward-Port-Of: odoo/odoo#270052
This change fixes a problem where importing certain valid UBL invoices could fail if a line had no quantity and no value. Those empty lines are now safely skipped, so the invoice import completes without showing an error message.
Original PR description
### Issue: Importing a UBL invoice containing a line with `LineExtensionAmount=0`, `InvoicedQuantity=0` and a non-zero `PriceAmount` failed with a `ZeroDivisionError`, reported in the chatter as an…
### Issue: Importing a UBL invoice containing a line with `LineExtensionAmount=0`, `InvoicedQuantity=0` and a non-zero `PriceAmount` failed with a `ZeroDivisionError`, reported in the chatter as an import error Such lines are valid UBL but carry no meaningful value, so they are silently skipped after the fix ### Cause: After this commit: https://github.com/odoo/odoo/commit/a7f77f3cfc42764328e7da73a60df8d4cafc968f The `line_extension_amount` was able to go in new parts of the code with a 0.0 value When `line_extension_amount` is set and `invoiced_quantity` is 0, `quantity` is computed as `subtotal * price_quantity / (...)` which resolves to 0 since `subtotal` is also 0 `price_unit = subtotal / quantity` then divides by zero ### Steps to reproduce: - Install `l10n_be` - Import a UBL invoice with a line where `LineExtensionAmount=0`, `InvoicedQuantity=0` and `PriceAmount` is non-zero (You can use the xml on the ticket) Before the fix, the import failed with an error in the chatter opw-6234453 Forward-Port-Of: odoo/odoo#271001
This update corrects how manufacturing work orders are scheduled when several tasks share the same upstream blocker. It now keeps already planned work orders in place, preventing later planning steps from rearranging them in a way that could violate dependencies.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/cfc5c998035b4268c36f5097782888e18e21b4fe Steps to reproduce the bug: - Create a product with a BoM with operation dependencies enabled - Add 4…
Bug introduced in: https://github.com/odoo/odoo/commit/cfc5c998035b4268c36f5097782888e18e21b4fe
Steps to reproduce the bug:
- Create a product with a BoM with operation dependencies enabled
- Add 4 operations on the same workcenter:
- opA: no blocker
- opB: blocked by opA
- opC: blocked by opA
- opD: blocked by opC
- Confirm a manufacturing order from this BoM
- Click Plan
Problem:
opA was scheduled after opB, violating the dependency.
`_plan_workorders` starts planning from the "leaf" workorders (those with no dependents). Given the structure above, the initial set is [opB, opD]. Processing opB first correctly plans opA then opB. But processing opD triggers a recursive chain opD→opC→opA which calls `action_unplan(opA)` and replans it from scratch. By then, opB already occupies the workcenter slot that opA originally held, so opA ends up scheduled after opB.
Solution:
Add `and not wo.is_planned` to the filter on `blocked_by_workorder_ids` in the recursive call inside `_plan_workorders`. Workorders that are already planned are skipped instead of being unplanned and replanned, preserving the correct order.
opw-6299179
Forward-Port-Of: odoo/odoo#271565This update resolves several problems affecting Cashmatic payment certification in Point of Sale. It prevents payment tokens from expiring during long checkout sessions, improves error handling when cash cannot be returned, and avoids delays when the device is unreachable.
Original PR description
First issue: While paying if a user takes more than 15min the token is revoked. Second issue: When cancelling a payment where a user has already inserted money and there is an issue with giving back the money, no popup was shown on the PoS. Third issue: Fetch took too long when the device was not reacheable. 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#268296
The executive summary now counts the start and end dates as part of the reporting period, instead of leaving out one day. This corrects date-based figures such as Average Debtor Days so report results match the actual calendar span.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#119346 Forward-Port-Of: odoo/enterprise#118953
This change makes a website test tour wait for the correct element before starting a drag-and-drop action. It prevents occasional test failures caused by the tour acting on the wrong target, improving reliability of website testing.
Original PR description
The tour `conditional_visibility_4` has non-deterministic failure, that appears to be caused by the `drag_and_drop` step dragging the element that was the target before the click of the previous step. This commit adds a step to ensure the target is the expected element before the "drag" step starts. runbot-242425 Forward-Port-Of: odoo/odoo#271760
This change prevents the web editor from failing when it processes extremely large documents. It improves reliability and response time by avoiding a browser limit that could otherwise make the page unresponsive.
Original PR description
For complex content, descendants(root) can return more than 100K elements. Using the spread operator expands all descendants into individual function arguments, which may exceed the JavaScript's argument limit and trigger a "Maximum call stack size exceeded" error. Replace with push() each node to the targetNodes. ||Before|After| |-|-|-| |getTargetNodes|Page Unresponsive|585 ms| Related ticket: opw-6303814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271250
When users quickly save a new calendar event, the title they typed is now preserved instead of sometimes being replaced by the default “no title” label. This prevents confusing event entries and ensures the saved calendar information matches what the user entered.
Original PR description
When creating an event using the quick create form from the calendar view if the user saves the record while the title is still being edited (using alt+c) the record will be saved with the default title: "(no title)" The code currently relies on the record data being up to date by the time onRecordSave is reached. However in the case of a text field, it is only saved when blurred. While there is a mechanism to blur the field when saving using a hotkey, it is completely asynchronous from the save logic of the form. To ensure all fields have comitted their data at save time, the framework has a mechanism to "request changes" which notifies all fields to update the record with their latest value and waits for them to do so. We can simply reuse this mechanism to ensure the data is up to date at recordSave time already, as we don't expect fields to have any changes after it. task-6321702 Forward-Port-Of: odoo/odoo#271850 Forward-Port-Of: odoo/odoo#271473
This change prevents overtime periods from overlapping when an employee’s attendance spans more than one day. It avoids an error that could interrupt work entry generation and ensures overtime is calculated correctly, especially around day boundaries.
Original PR description
**Problem:** When an attendance has overtimes across multiple days, those overtimes can overlap when calculating their intervals. There will always be rounding errors since only the durations are…
**Problem:** When an attendance has overtimes across multiple days, those overtimes can overlap when calculating their intervals. There will always be rounding errors since only the durations are saved to 3 decimals, but this is normally fine since the durations are accumulated when calculating the next interval. However, on a day boundary in the employee timezone, the end of the interval is forced to the end of day, which incidentally removes the rounding error. This causes the overlap when calculating the next interval since its start will be based on the rounded duration, not the actual end of day. **Steps to Reproduce:** - Configure an overtime rule where >8 hours is considered overtime, and a second rule applies to non-working days - Set Overtime Rule on employee "Anita Oliver" - Set employee work entry source to "Attendances" - Create an attendance that exceeds 8 hours in a day and crosses into a non-working day and creates enough of a rounding error (see unit test) -> Traceback error: `ValueError: Expected singleton: hr.attendance.overtime.line(1, 2)` **Solution:** Add an additional check to ensure the overtime cannot start on the previous day. opw-6067969 Forward-Port-Of: odoo/enterprise#119672 Forward-Port-Of: odoo/enterprise#118570
This update fixes an issue in the Time Off calendar view where users could not always scroll all the way to the bottom of the page. It improves the reliability of the page so employees can navigate the calendar more easily and reach all content as expected.
Original PR description
This PR expected to solve scrolling issue in Calender View Time Off module. In the Time Off module's Calender View, users aren't able to scroll down all the way to the bottom page. This behavior is intermittent so it's not deterministic. Root cause: This bug occurred in the earlist version and it might be related to an updated of Framework JS. task: 6328706
This update makes module installation more reliable when some referenced records were deleted earlier. It also fixes a case where new chart-of-accounts data could be incorrectly ignored during first-time setup, helping ensure accounting settings are applied as expected.
Original PR description
Installing a new module should be safe even when the module contains new data for records that have been deleted. It is not the responsibility of the localization to make sure of that. The fix in `l10n_sa_edi` had 2 issues: * calling `self.env.ref` instead of `self.ref` * Checking for the existence of records even in the case of installing the CoA for the first time on a company, which obviously doesn't contain anything. This results in always ignoring the data. Forward-Port-Of: odoo/odoo#271818
This update prevents the Czech accounting report setup from trying to take over records that already exist when reloading the chart of accounts. It helps avoid conflicts during setup and keeps existing accounting data safer and more consistent.
Original PR description
It is the burden of the CoA framework to check for that. See community commit for more information. Forward-Port-Of: odoo/enterprise#121643
The Mozambique demo company now uses a valid NUIT number. This prevents validation errors when newer standard number checks are applied, helping demo data load correctly and avoiding build failures.
Original PR description
Newer versions of stdnum (2.2) also test the number for MZ We did not have a valid NUIT number in the MZ demo company. Runbot error: https://runbot.odoo.com/runbot/build/114118067 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#271398 Forward-Port-Of: odoo/odoo#271299
The system now only detaches attachments when that is appropriate for outgoing invoices. Incoming XML files received through EDI stay linked to bills so they can still be included in bulk exports, while the special Italian Tax Integration XML flow continues to work correctly.
Original PR description
The feature introduced in odoo/enterprise#78429 allows users to detach attachments from moves, primarily to facilitate the regeneration and re-sending of outgoing XMLs (e.g., sales invoices) without needing to delete the original attachment. However, detaching should not apply to incoming XML attachments on bills that originate from EDI import, as these attachments are the received source document and are never regenerated by the system. Detaching them inadvertently prevents their inclusion in bulk XML exports. An exception exists for Italy: businesses need to send Tax Integration XMLs back to the SdI. In this specific case, detaching the Tax Integration XML is appropriate and ensures the bulk export finds the latest, correct attachment. Ticket [link](https://www.odoo.com/odoo/project.task/5062132) opw-5062132 Forward-Port-Of: odoo/odoo#270896 Forward-Port-Of: odoo/odoo#239701
This update fixes an issue where adding an image to a vendor bill could block users from opening bill options or printing the original bill. It ensures image attachments are handled correctly so everyday accounting actions continue to work without access errors.
Original PR description
**Steps to reproduce:** - Install the `accountant` module and log in as admin. - Create and confirm a vendor bill. - Send an image in the chatter of the vendor bill. - Open a new tab and log in as a…
**Steps to reproduce:** - Install the `accountant` module and log in as admin. - Create and confirm a vendor bill. - Send an image in the chatter of the vendor bill. - Open a new tab and log in as a demo user. - Open the same vendor bill. - Click the gear icon. **Observation:** An access error is raised, and the gear icon is not accessible. **Root Cause:** At [1], the method `_should_attach_to_record` incorrectly excludes image attachments, causing them to be treated as `extra_files_data` at [2]. As a result, in `_fix_attachments_on_record_from_files_data` at [3], these attachments are assigned `res_model=False` and `res_id=0`. When the code tries to access these attachments at [4], it leads to an access error. Additionally, when we try to print `Original Bills`, we get the same access error at [5], and later the code calls the `browse` function on `self.env[attachment.res_model]`, but for `extra_files_data` we set the `res_model=False`, which results in a `KeyError`(see [6]). **Fix:** This commit prevents the error and ensures that users can access the gear icon when an image is attached in the chatter and print the `Original Bills`. [1]: https://github.com/odoo/odoo/blob/95864190a71b68eb10ae59ae8f38ac35b0cb6a97/addons/account/models/account_document_import_mixin.py#L416-L429 [2]: https://github.com/odoo/odoo/blob/95864190a71b68eb10ae59ae8f38ac35b0cb6a97/addons/account/models/account_move.py#L6668-L6672 [3]: https://github.com/odoo/odoo/blob/95864190a71b68eb10ae59ae8f38ac35b0cb6a97/addons/account/models/account_document_import_mixin.py#L409-L414 [4]: https://github.com/odoo/odoo/blob/7e874e7db30e05a02d6eeb26d9d67ed6176b9704/addons/account/models/account_move.py#L6944-L6949 [5]: https://github.com/odoo/odoo/blob/7e874e7db30e05a02d6eeb26d9d67ed6176b9704/addons/account/models/ir_actions_report.py#L30-L34 [6]: https://github.com/odoo/odoo/pull/261463#issuecomment-4602692978 opw-6119155 Forward-Port-Of: odoo/odoo#261463
The embedded Mercado Pago payment form now follows the website’s language instead of always appearing in English. This creates a more consistent checkout experience for customers and can help reduce confusion during payment.
Original PR description
The Mercado Pago Bricks SDK was always initialized with the `en-US` locale, so the embedded (inline) payment form rendered in English for every customer regardless of their website language. Resolve the Bricks locale from the website language instead. The locale is keyed by country, since each supported country maps to a single locale (e.g. Brazil is always pt-BR), so the language's country part is enough to resolve it. For the shared es_419 language, which carries no country, fall back on the company's country, and default to en-US for unsupported languages. task-6281783 Forward-Port-Of: odoo/odoo#269406
This update corrects a problem where new accounting tags weren't being properly applied during the Danish localization module's setup. Moving the tag mapping process to occur after the database is loaded ensures all tags are present, preventing errors and data inconsistencies. This resolves a foreign key violation that previously caused issues with account cleanup.
Original PR description
The tag remapping was running in pre-migrate, before the module's data files are loaded. This caused the tag swap to be silently skipped for any new tag that didn't exist yet, and the subsequent…
The tag remapping was running in pre-migrate, before the module's data files are loaded. This caused the tag swap to be silently skipped for any new tag that didn't exist yet, and the subsequent cleanup to fail with a FK violation on account_account_account_tag.
```py
File "/home/odoo/src/odoo/saas-19.2/odoo/sql_db.py", line 417, in execute
self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_account_tag" violates foreign key constraint "account_account_account_tag_account_account_tag_id_fkey" on table "account_account_account_tag"
DETAIL: Key (id)=(356) is still referenced from table "account_account_account_tag".
```
Moving to post-migrate ensures all new account tags are present in the database before the remapping and cleanup run.
upg-[4341331]
[4341331]: https://upgrade.odoo.com/odoo/upgrade.request/4341331?debug=1
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#269809This update fixes an issue where rental prices weren't correctly formatted on the website, appearing without the necessary slash separator. The fix ensures that rental prices and durations are displayed clearly and accurately, improving the user experience for customers renting products. This resolves a visual inconsistency.
Original PR description
Steps to produce: --- - Install the `Rental and eCommerce `modules. - Create a rental product and configure a rental price for it. - Add an optional product from the Sales tab. - Publish the product…
Steps to produce: --- - Install the `Rental and eCommerce `modules. - Create a rental product and configure a rental price for it. - Add an optional product from the Sales tab. - Publish the product on the website. - Open the product page on the website and click` Add to Cart`. Issue: --- - In the product configurator, the rental price is displayed without the `/` separator between the price and the rental duration period. Cause: --- - The string used to generate the rental duration label does not include the `/` separator. Fix: --- - Add the missing `/` separator to the rental duration label so that rental prices are displayed correctly. Before: --- <img width="974" height="185" alt="image" src="https://github.com/user-attachments/assets/64a88a60-bcc0-4657-97fd-584da57d0aff" /> After: --- <img width="967" height="188" alt="image" src="https://github.com/user-attachments/assets/b4d50019-1db4-4817-a8ce-446cc3c55df4" /> opw-6293015 Forward-Port-Of: odoo/enterprise#121246 Forward-Port-Of: odoo/enterprise#120223
This update fixes an issue where customer addresses in the Field Service kanban view would be cut off and displayed incorrectly due to a design element that didn't properly constrain the address width. The fix ensures that long customer addresses now fit neatly within the kanban card, improving readability and usability. This improves the visual presentation of customer information.
Original PR description
Steps to reproduce: - 1. Open the Field Service planning view in kanban. 2. Make sure a shift's customer has a long address (long street lines). 3. Look at that shift's card in the kanban view. Issue: - The customer address overflows the card and is clipped at its right edge instead of staying within the card boundaries. Cause: - The customer is rendered with the `many2one` widget and `show_address`, which marks each address line `text-truncate`. Truncation only works inside a width-bounded container, but the field root `.o_field_many2one` is an inline-flex item with the default `min-width: auto`, so it grows to fit the longest address line instead of shrinking to the card. As a result, `text-truncate` never engages and the address spills past the card. Fix: - Add the `min-w-0` class to the partner field so the flex item shrinks to the available card width. task-6272209 Forward-Port-Of: odoo/enterprise#119248
This update resolves an issue where Purchase Orders remained flagged as 'Late Receipts' even after a backorder was cancelled. The fix now correctly excludes both 'done' and 'cancel' pickings when determining if a purchase order is overdue, ensuring accurate reporting and a cleaner user experience. This prevents unnecessary alerts and improves order management.
Original PR description
Steps to reproduce: ------------------- - Create a Purchase Order with an expected Arrival date in the past - Confirm the Purchase Order - Validate the receipt partially and create a backorder -…
Steps to reproduce: ------------------- - Create a Purchase Order with an expected Arrival date in the past - Confirm the Purchase Order - Validate the receipt partially and create a backorder - Cancel the generated backorder - Open the Purchase Orders list and check the 'Late Receipts' Issue: ------ The Purchase Order still appears in the 'Late Receipts' filter even though there is no remaining receipt to process. Cause: ------ The 'Late Receipts' filter relies on the computed search field `is_late`: https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/views/purchase_views.xml#L439 The search domain for this field is generated by `purchase.order._search_is_late()`: https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/models/purchase_order.py#L176 In `purchase_stock`, `_get_domain_is_late()` extends the base domain to identify Purchase Orders that still have receipts pending: https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase_stock/models/purchase_order.py#L264-L267 After a partial receipt: - the original receipt is in state `done`, - a backorder is created and linked to the Purchase Order, - the backorder is later cancelled and moves to state `cancel`, - the Purchase Order line still has `qty_received < product_qty`. The existing domain excludes only `done` pickings when determining whether a receipt is still pending. As a result, a cancelled backorder is still treated as an unfinished receipt, causing the Purchase Order to remain visible in the 'Late Receipts' filter. Fix: ---- Exclude both `done` and `cancel` pickings when determining whether a Purchase Order has pending receipts. A cancelled backorder indicates that the remaining quantity will not be received through that transfer. Therefore, once all related pickings are either completed or cancelled, the Purchase Order should no longer be considered late. --- opw-6266046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268488
This update resolves a technical issue impacting the processing of Mexican tax invoices (CFDI). The system was struggling to handle complex cancellation scenarios due to a limitation in the database index. Switching to a different index type allows for smoother and more efficient handling of these invoices, particularly those with multiple related documents.
Original PR description
The field `l10n_mx_edi_cfdi_origin` can contain a large number of associated UUIDs, especially in complex cancellation scenarios. The default B-tree index fails when this field exceeds 2704 bytes, which occurs after approximately 20 UUIDs. By switching to a trigram index, we avoid the entry size limit of PostgreSQL's B-tree nodes. This ensures that invoices with many related documents can be processed while maintaining efficient search performance for partial matches on this field. **Video before the fix:** https://youtu.be/24u0HbxwIH8 **Video after the fix:** https://youtu.be/sUelv1HZMvI Forward-Port-Of: odoo/enterprise#118868
This update fixes an issue where the sandwich rule incorrectly excluded public holidays from leave calculations. Now, when 'Include Public Holidays as Working Day' is selected, the system accurately determines the correct leave duration, including weekend days as part of the calculation. A new test case has been added to ensure this fix works as expected.
Original PR description
Problem: When a time off type is configured with "Include Public Holidays as Working Day", the sandwich rule was still treating public holidays as non-working days. This caused the sandwiched weekend days to not be included in the leave duration. Example: Employee applies leave from May 15 (Friday, Public Holiday) to May 18 (Monday). Expected duration is 4 days since May 15 is a working day and May 16-17 (weekend) should be sandwiched. Instead, only 1 day was calculated. Fix: Now when "Include Public Holidays as Working Day" is enabled, the correct number of days are calculated in the sandwich rule. Also added a test case to verify that public holidays are correctly treated as working days during sandwich rule evaluation. Task-4570118 Forward-Port-Of: odoo/odoo#271261 Forward-Port-Of: odoo/odoo#266624
The Time Off Balance report was incorrectly calculating remaining days when overlapping allocations existed. This fix ensures the report accurately reflects the remaining time off by correctly deducting leave days from allocations based on their overlap periods. This prevents overestimation of available time off.
Original PR description
The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one. ### **Steps to reproduce:** 1) Install time off app. 2) Create a…
The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one. ### **Steps to reproduce:** 1) Install time off app. 2) Create a simple time off type. - Create Allocation A (10 days, 01-01-2024 to 31-12-2025) - Create Allocation B (10 days, 01-01-2025 to 31-12-2026) 3) Create a leave of 1 day on 01-01-2026 4) Open the Balance report ### **Observed Behavior:** The report shows 20 remaining days. ### **Expected Behavior:** The report should show 19 remaining days (20 allocated - 1 taken). ### **Cause:** In the taken_per_allocation CTE at [1], each leave is joined to every allocation it overlaps. The [fifo_balances] CTE then uses the formula: ``` GREATEST(alloc_days - GREATEST(taken - prior_cumulative_alloc, 0), 0) ``` This subtracts the prior allocation capacity (A = 10 days) from the taken count (B = 1 day). Since 1 - 10 = -9, GREATEST(-9, 0) = 0, so zero days are deducted from B. The formula wrongly assumes that prior allocations can absorb leaves that do not overlap with them. [1]- https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L126-L142 [fifo_balances]: https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L145-L164 ### **Fix:** Ensure that leaves are only deducted from allocations they actually overlap by calculating the balance using the delta of cumulative leaves within an overlap group. This prevents earlier allocations from absorbing leaves that occur outside their validity period. **opw-6150161** Forward-Port-Of: odoo/odoo#271596 Forward-Port-Of: odoo/odoo#263029
This update ensures the Clickall tool, used for automated accounting dashboard testing, correctly handles the new version 2 (v2) of Odoo Fin's favorite institutions endpoint. By adding a mock, we prevent the tool from making direct requests to production servers, maintaining a safe and isolated testing environment.
Original PR description
This commit follows up on [1] by extending the Odoo Fin request mock to cover the new version 2 (v2) favorite institutions endpoint. Previously, a mock was introduced to prevent the Clickall tool from making real external HTTP requests to `production.odoofin.com` when displaying the accounting dashboard. This update ensures that the newly introduced v2 URL is also safely intercepted, keeping the automated tests fully isolated from production servers. runbot-234936 [1] : https://github.com/odoo/odoo/commit/c6451015f1b01c3e1defe4a576989fd4bfdf2cdb Forward-Port-Of: odoo/odoo#271804
This update fixes a previous issue where commission losses were incorrectly calculated for employees on long-term sickness or partial incapacity leave. The change ensures that these employees are not subject to commission deductions, aligning with standard payroll practices. This update improves accuracy and fairness in commission calculations for a specific employee group.
Original PR description
Partial incapacity and long term sickness are not elligible to loss on commissions. Forward-Port-Of: odoo/enterprise#121514
This update fixes an issue where changing the quantity of a Purchase Order Line (POL) in Multi-Step Routes incorrectly updated the associated receipt quantity. The fix ensures that quantity adjustments are accurately reflected, preventing discrepancies between the sale order and the purchase order receipt.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable product P with MTO buy and a set…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable product P with MTO buy and a set vendor - Create and confirm a sale order for 1 unit of P - Confirm the assocaited PO and change the pol quantity from 1 to 10 > the associated receipt is updated from 1 to 10 - Change the pol quantity from 10 to 7 #### > The quantity on the receipt is updated from 10 to 16. ### Cause of the issue: Changing the quantity of the POL will adapt the picking related quantity via these lines: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L115-L117 https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L342-L349 by creating new stock moves to be merged: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L220-L251 Now, the issue is that this flows relies both on a negative `qty_to_attach` of `1 - 10 = -9` and a positive `qty_to_push` of `7 - 1 = 6`. However, the `qty_to_attach` is only used if is positive: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L243-L251 The receipt is therefore updated by a `+6` move to push but not by the `-9` move to attach. Leading to a 10 -> 16 rather than 10 -> 7 result. opw-6218307 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270547 Forward-Port-Of: odoo/odoo#264994
This change optimizes the automated posting of invoices by preventing the cron job from repeatedly rescheduling entire batches when individual invoices fail to post. Previously, a batch failure triggered thousands of unnecessary retries. Now, failed invoices are simply marked as unpostable, reducing system load and improving performance.
Original PR description
Before this change, cron jobs triggering `_autopost_draft_entries` would gracefully handle batch-level failures by logging the error and retry one by one. As a result, `_process_job`, with success 0 done and remaining number, marked the cron run as partially completed and triggered `_reschedule_asap`. When a batch contained only problematic records, the cron job could be rescheduled thousands of times per day. With this change, if a move in the batch fails to post, we set its `auto_post` to `no`, together with the existing message-posting logic in the chatter, to prevent repeated retries for failed records. Related ticket: opw-6303194 opw-5364851 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271509
This update fixes a visual bug where outdated cluster bubbles remained visible on the company map after zooming or panning. The issue stemmed from a technical error in how the map library handled removing old cluster icons. This change ensures that clusters are properly updated and removed, providing a cleaner and more accurate map display for users.
Original PR description
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times…
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times => stale blue cluster bubbles remain on the map Cause: ====== On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level. `ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map, https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation. Solution: ========= Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon. opw-6128531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270733
This update resolves a problem where the Italian POS fiscal printer would intermittently stop printing orders due to unsupported characters in product or payment method names. The fix replaces these characters with spaces, ensuring complete and accurate printing of fiscal receipts, as outlined in official EPSON documentation.
Original PR description
Steps to reproduce: - Setup an Italian fiscal printer - Modify the name of a product to use the non-blocking space character "\ "; - In the POS, create an order with the product. Error: the fiscal device will stop midway in the printing process and return an incomplete response to the frontend. The issue can also be reproduce if the character is included in the payment method name or the POS config name. Solution: When formating the xml command, replace all non-supported character by a space character. The non-supported character list is provided by the official [EPSON fiscal printer documentation](https://support.epson.net/setupnavi/?PINF=bsmanual&OSC=WS&LG2=EN&MKN=FP-90III%20RT) in the document "ePOS Fiscal Print Solution Development Guide". Other: Rename the file "dispaly_text.xml" to "display_text.xml". [opw-6244089](https://www.odoo.com/odoo/project/49/tasks/6244089) Forward-Port-Of: odoo/enterprise#121538 Forward-Port-Of: odoo/enterprise#120169
This update resolves an issue where attendees received duplicate emails when rescheduling meetings. The fix prevents a nested calendar event write, which was causing the original and subsequent updates to trigger multiple notifications. This ensures attendees only receive one notification for meeting date changes.
Original PR description
Steps to reproduce: 1. Install CRM, Calendar, and Contacts. 2. Create a contact with an email address you can receive emails on. 3. Configure an outgoing email server. 4. Open a CRM lead and create a…
Steps to reproduce: 1. Install CRM, Calendar, and Contacts. 2. Create a contact with an email address you can receive emails on. 3. Configure an outgoing email server. 4. Open a CRM lead and create a meeting activity using the calendar. 5. Add the created contact as an attendee of the meeting. 6. Return to the lead and click the Reschedule button on the activity. 7. Select the same meeting and change its start date to a future date. Issue: - Attendees receive the meeting date-change email twice. Root cause: - When a calendar event linked to an activity is rescheduled, the event write syncs the new start date to the related activity through `_sync_activities`. That activity write was not marked as calendar-originated after commit https://github.com/odoo/odoo/commit/bc090486bd7810b1b0af1bae398255a2d6615f09, so `mail.activity.write` treated the updated deadline as an activity-originated change and wrote back to the same calendar event. https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/calendar_event.py#L779 https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/mail_activity.py#L24-L33 - This created a nested calendar event write. Both the nested write and the original write then triggered attendee date-change notifications, resulting in duplicate emails. Solution: - Pass the existing `calendar_event_meeting_update` context flag when syncing calendar event changes to linked activities. This prevents the activity sync from writing back to the event while preserving activity-to-event rescheduling. opw-6209956 Forward-Port-Of: odoo/odoo#269950 Forward-Port-Of: odoo/odoo#266675
This update fixes a display issue in the Helpdesk module where ticket labels in list and form views didn't match the labels shown in the Kanban view. The fix removes outdated label fields from the views, ensuring all ticket views show the correct, up-to-date state selections.
Original PR description
Steps to reproduce: ------------------------ 1. Install Helpdesk 2. Go to All Tickets and check the kanban state selection value 3. Go to Settings > Field Selection and search for kanban_state in…
Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views
Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").
Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.
Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.
Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999
opw-6238765
Forward-Port-Of: odoo/enterprise#119707This update resolves an issue where users without fleet access could not import UBL invoices referencing vehicles. Now, users with vendor bill import permissions can successfully import UBL invoices containing vehicle references, improving data import flexibility. This ensures accurate recording of transactions regardless of user access rights.
Original PR description
When a user has no rights to access the fleet models but is allowed to import vendor bills, he should be able to import a bill (UBL) with referenced vehicle(s) inside. task-6289956 Forward-Port-Of: odoo/odoo#269447
This update resolves a bug where JSON data couldn't be displayed when clicked in the l10n_in_edi module. The issue stemmed from a change in how binary fields handle data, requiring a conversion to the correct binary format. Now, JSON data is correctly displayed.
Original PR description
**Description of the issue this PR addresses:** This issue was introduced after the refactoring of binary fields [odoo/odoo#244421](https://github.com/odoo/odoo/pull/244421) ,where Binary fields now expect proper binary data and treat string values as base64. The JSON data was passed as a string to a binary field. After the BinaryValue change, this string was treated as base64, which caused a decoding error. **Before this Commit:** Clicking the JSON button resulted in an error: `binascii.Error: Only base64 data is allowed` Due to this, the JSON data could not be viewed. **After this Commit:** JSON data is now converted into the correct binary format using Odoo’s binary handling `(odoo.tools.Binary)` and it displays correctly. [Related Commit](https://github.com/odoo/odoo/commit/41fe2ebdb9cc37341362d7af829c087a5f72f9f1#diff-d3b35dffff8313ee07a08bceb336f03d6130bf001e3b0daa32b098cefcf95c3b) [Full Error Details ](https://pastebin.com/v12sD2vf)
This update resolves a technical issue that could cause errors in the planning module when start and end dates are not specified. By adding a check, the system now avoids attempting planning operations when this critical information is missing, ensuring smoother and more reliable planning processes. This improves the overall stability of the Enterprise version.
Original PR description
Add a guarding condition to the auto-plan or send behavior to avoid doing those operations when no start/end dates are defined --- Task-6312650
This update resolves a potential issue during Odoo upgrades where errors could occur when rules were being processed. The fix prevents errors when fields needed for rule evaluation aren't immediately available, ensuring smoother and more reliable upgrades. This improves the overall stability of the Odoo system.
Original PR description
In a [recent fix], the `_get_all_rules()` method was changed to skip the models that are not yet loaded (during upgrades). However, some rules can be added to an existing model by another module. In that case, the rule is processed even though the fields used in that rule are not yet loaded. This leads to a traceback during upgrades because `optimize()` is trying to access those fields. This commit adds the rule without pre-evaluating it if an `ValueError` is raised during the optimization step. [recent fix]: https://github.com/odoo/odoo/pull/267676
This update resolves a bug in the testing process for SEPA Direct Debit payments. The test was failing because the payment status was incorrectly identified as 'reconciled' instead of 'paid'. This change ensures the payment is validated only when it's in the correct 'paid' state, improving test reliability.
Original PR description
The `test_expiry` test creates a payment via the `pay_with_mandate` method. Depending on eg. the installed modules, the resulting payment ends up either `paid` or `reconciled`. Afterwards, the test tries to validate the payment, which requires that it not be in the `reconciled` state. This causes an error linked below. This PR adds a condition to ensure the payment is in the `paid` state before attempting to validate it. Error: https://runbot.odoo.com/odoo/error/240557 Forward-Port-Of: odoo/enterprise#112224
This update fixes a minor issue within the Odoo composer tool that prevented users from correctly placing the cursor at the end of lines when adding mentions. The fix adds a special character to ensure proper browser handling of text editing, improving the user experience. This ensures users can accurately format their messages.
Original PR description
### Purpose of this PR: - Inserting a mention in the composer results in a paragraph ending with a bare `<a>` element and no trailing text node. This causes the browser to mishandle the End key, moving the caret to the start of the next paragraph instead of the end of the current line. - Fix by appending a \uFEFF (zero-width no-break space) text node. task-6295924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271802 Forward-Port-Of: odoo/odoo#269699
This update fixes an issue where the VAT displayed in the product information popup was incorrect, leading to an inaccurate total price. The fix ensures that the product's tax rate is correctly calculated based on the pricelist and fiscal position settings, resulting in the correct total price being shown.
Original PR description
Steps to reproduce: ------------------- 1. Create a product with a tax (e.g. 15%). 2. Create a pricelist that changes the price (e.g. 100 to 200). 3. Create a fiscal position mapping the tax (e.g.…
Steps to reproduce: ------------------- 1. Create a product with a tax (e.g. 15%). 2. Create a pricelist that changes the price (e.g. 100 to 200). 3. Create a fiscal position mapping the tax (e.g. 15% to 30%). 4. Add the pricelist and the fiscal position in PoS. 5. Add the product to the cart, and select the tax and the pricelist created in the previous steps. 6. Long press on the product to see its info. The price should be 200 now after selecting the pricelist. Also the tax should be 30% bc of the FP mapping, i.e. total price should be 200 + 30% = 260. However, we observe that VAT shows 15 (15%) instead of 60 (30%), and Price incl. Tax shows 230 instead of 260. What's happening: ----------------- On the frontend, `getTaxDetails()` is called with no options, so it uses the product `list_price` (100) and `taxes_id` (15%), giving VAT = 15. Alos, on the backned, `self.taxes_id` is used directly to compute the taxes, even though the pricelist price is correct (200), fiscal position is ignored, hence 200 + 15% = 230 instead of 200 + 30% = 260. The fix: -------- On frontend, we pass the pricelist and fiscal position to `getTaxDetails`, and compute the tax name from the mapped taxes. On the backend, we read the `fiscal_position_id` from the context and apply the tax mapping, so the correct taxes are used. opw-6200632 Forward-Port-Of: odoo/odoo#271396 Forward-Port-Of: odoo/odoo#266012
This update fixes a potential issue where changes to knowledge articles (sharing, favorites, editing) weren't reliably applied. The update ensures the correct article is loaded before any modifications are made, enhancing the user experience and data consistency. This improves the reliability of the knowledge base.
Original PR description
With this commit, We ensure we're in the correct article before making any changes (share, add to favorites, edit) using `waitUntil`. We've added a `checkArticle` function to ensure the article is in the correct place in the menu. runbot-error-id~234645 Forward-Port-Of: odoo/enterprise#110642 Forward-Port-Of: odoo/enterprise#110123
This update fixes a temporary access error users experienced when switching between companies within a payroll payrun. The change ensures a smoother transition by verifying access permissions before loading the payrun data, preventing brief errors and redirecting users back to the payrun list.
Original PR description
Steps to reproduce: 1- Open a payrun 2- Switch companies Issue: You get an access error for a moment and then get redirected to payrun list view Cause: When switching companies, the payrun reloads but since it is in the context of a different company, you get an access error. Solution: First check in js before fetching that you have access to the payrun, if not, redirect to the list view instead. Task-6008140
This update ensures that all members of a tax unit, not just the main company, have read access to tax return checks. This allows for quicker identification and resolution of issues causing failures in tax reporting, improving overall data accuracy and efficiency.
Original PR description
Before this commit: Tax Unit Members other than main company have read access to tax returns but don't have read access to tax return checks. After this commit: Tax Unit members other than main company are given read access to tax return checks also, so they can fix checks failing because of them. task-5951364 Forward-Port-Of: odoo/enterprise#113118