Friday, February 27, 2026
21 changes · saas-18.3
Enhancements to existing features
This update makes the Gantt chart's date selection more responsive. Previously, date changes required clicking 'Apply' to update the display. Now, date selections update immediately in the UI, providing a smoother and more intuitive user experience. This change enhances usability and efficiency when working with project timelines.
Original PR description
- Previously, the Gantt scale selector only updated the displayed date range after the "Apply" button was clicked. This was because the template was bound to the component props rather than the local state. - This commit binds the date picker display to the local pickerValues state. Now, when a user selects a date in the picker, the UI updates immediately, while the actual data fetch remains deferred until "Apply" is clicked. Task: 5932671
Resolved issues and error corrections
This update corrects the XML templates used for Dutch SBR and ICP tax reports to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with local regulations and improving the reliability of financial data.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update fixes an issue where a POS order could incorrectly apply a pricelist even if it wasn't the customer's standard pricelist. This occurred when the order was linked to a previously paid order. The change ensures that only valid, available pricelists are applied to POS orders, improving order accuracy and preventing potential pricing errors.
Original PR description
When changing the customer on a POS order, if the customer's pricelist is not in the list of available pricelists for the POS, but the pricelist was loaded due to loading a paid order, the POS would still set that pricelist on the order. opw-5461556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248365 Forward-Port-Of: odoo/odoo#247029
This update fixes an issue where Odoo incorrectly displayed records after a user switched companies. Previously, the system didn't immediately update the URL needed for the correct record view, leading to incorrect displays. Now, the system reliably directs users to the correct record after a company change, ensuring a smoother user experience.
Original PR description
Have a flow where an action act_window is executed and wants to open a record in the form view, but that record is not in one of the companies that the current user is logged in. The ORM will crash with an access denied, that the JS catches cleverly (see odoo/odoo@6213c40932236101b529b82f0ea9fce1829c8c24) and tries to reload on that failed action after altering the allowed companies. Before this commit, this flow was imperfect because the url (that allows to reload at the right place) was not written immediately. So, more often than not, we ended up on the wrong view after reload. After this commit, we end up in the right action after reload. 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#250401
This update corrects a bug that caused time off reports to incorrectly open as allocation records. The issue stemmed from a misalignment in the database query used to generate the reports, leading to incorrect record identification. This fix ensures that time off requests are now correctly displayed and opened within the intended time off reporting interface.
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#249015
This update fixes an issue where the VAT Book download was only generating for the primary company, even when related branches (with the same CUIT) were selected. Now, when multiple companies with the same CUIT are chosen, the VAT Book download will include data for all of them, ensuring accurate reporting for businesses with multiple branches.
Original PR description
#### Issues: VAT Book should download for all selected companies with same CUIT as the current one. #### Step to reproduce: - In a company in Argentina ("Parent Company") - Create a branch "Child…
#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.
#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
- i. Select both "Parent Company" and "Child Company A" but not "Child Company B"
- ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")
#### Current behavior:
i. Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only
#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"
A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.
opw-5385585
Forward-Port-Of: odoo/enterprise#101898This update fixes an issue where table menu buttons were not visible or positioned correctly within the HTML editor. The change ensures the table menu functions as expected, providing a better user experience for creating and editing tables. It addresses a technical configuration problem within the HTML editor's internal workings.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. ENT PR: https://github.com/odoo/enterprise/pull/108874 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Forward-Port-Of: odoo/odoo#250645
This update fixes a bug where multiple physical gift cards added to a single Point of Sale (PoS) order were not being created in the backend. The issue stemmed from a misinterpretation of data keys, leading to incorrect gift card counts. This ensures all gift cards are properly recorded, improving order accuracy and preventing revenue loss.
Original PR description
When selling mutliple physical gift cards in the same PoS order, no gift cards were created. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on the gift card line and set a physical gift card with a value of 100€ * Add another gift card to the order * Click on the gift card line and set a physical gift card with a value of 50€ * Validate the order > Observation: No gift card is created in the backend Why the fix: ------------ When looking for the `oldChanges` we tried to retrieve the gift card code as `gift_code` but the key name is `code`. Because of this the `pointsCount` was wrong. opw-5928320 Forward-Port-Of: odoo/odoo#249951 Forward-Port-Of: odoo/odoo#249066
This update fixes an issue where QR code payment links on invoices were incorrectly showing the full outstanding amount, particularly for installment-based invoices. By using the default values for the payment link wizard, the links now accurately reflect the next payable installment, ensuring accurate payments.
Original PR description
The link from QR code in invoice pdf was explicitly passing `amount`, `res_model`, `res_id` to create `payment.link.wizard` using create method which overrides default_get() of wizard. As a result, installment-based invoices were generating payment links for the full residual amount. Also the `active_id` and `active_model` is passed in context which writes to `res_model` and `res_id` so no need to add it in create again. By letting default_get() populate the wizard values, the payment link now correctly reflects the next payable installment. task-5401335
This update corrects a problem with how VAT tax schemes are calculated for Romanian customers. Previously, an empty company registry caused errors. The fix re-introduces specific logic for Romanian CIUSRO invoices to ensure accurate VAT calculations, addressing a critical issue for Romanian businesses using Odoo.
Original PR description
Problem --------- If the customer has not VAT set up on it record, we use the DEFAULT_VAT value. However, the scheme to be used is computed using the partner company_registry (which might be empty), which fails. Secondly, the piece of logic that compute the VAT/NON_EU_VAT for the Tax Scheme node was removed during the refactor. However, this is needed in Romania. Solution --------- Compute the scheme using the DEFAULT_VAT and add back the VAT/NON_EU_VAT logic for the Romanian CIUSRO only. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250110
This update fixes a bug where employees with scheduled future attendances couldn't check out. The fix ensures that only past attendance records are considered when determining the employee's checkout status, preventing errors and restoring normal kiosk functionality. This resolves a critical issue impacting employee workflow.
Original PR description
### Issue: When having an attendance in the future, the employee cannot checkout anymore. ### Steps to reproduce: - In Attendances, create an attendance in the future for an employee - Go in the kiosk mode - Manually select the employee to check in - Do the same to check out - An error pops up ### Cause: The field `last_attendance_id` of the employee contains his future attendance. The field `attendance_state` use `last_attendance_id` in its computation, so it's always "checked_out", even if an attendance is curently open for the employee. So when trying to check out an exception is raised in [`_check_validity()`](https://github.com/odoo/odoo/blob/fee6b32a8a57577bd8229c80dff6f93964f9f556/addons/hr_attendance/models/hr_attendance.py#L224-L234). ### Solution: Add a condition in the domain of `_compute_last_attendance_id()` to only consider the last **past** attendance. opw-5491867 Forward-Port-Of: odoo/odoo#248875
This update fixes a potential issue with after departure payments to work. Now, if a previous payslip isn't linked, a clear error message is displayed to the user instead of a technical error. This ensures accurate payment processing and avoids confusion.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#107386
This update fixes an issue where the number of available time off allocations wasn't accurately reflecting allocations started in the previous year. The fix ensures that all valid allocations, regardless of their start date, are correctly counted on the time off type page, improving reporting accuracy. This resolves a discrepancy between the smart button and the allocation details.
Original PR description
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee…
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page. ## Reproduction Steps 1. Go to Time off > Configuration > Time off Types and click on any time off type. 2. A smart button Allocations should appear with a number in it. Note the number and click on the button. 3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation. 4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now. 5. Go back to the Time off type page and look at the number on the Allocations smart button. ### Expected behavior As the allocation we set is still valid, the number shouldn't have changed. ### Unexpected behavior The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity. ## Origin of the issue The domain of the allocations to take into account when computing the count of valid allocations is defined here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year. The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above. __ opw-5504272 Forward-Port-Of: odoo/odoo#250378 Forward-Port-Of: odoo/odoo#248482
This update ensures taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't initially provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, now it defaults to using standard product tax rules. This ensures accurate tax reporting for all UrbanPiper transactions.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#108405 Forward-Port-Of: odoo/enterprise#106686
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being added to the transfer. The fix ensures that multiple 'Back' clicks don't trigger redundant saving operations, preventing incorrect quantity calculations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#108881 Forward-Port-Of: odoo/enterprise#103130
This update fixes an issue where archived accounts could be incorrectly assigned as default journal accounts. Previously, the system allowed assigning accounts regardless of their active status. Now, the system strictly uses only active accounts for journal defaults, maintaining data consistency and preventing potential errors in financial reporting.
Original PR description
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account…
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account is assigned by the onchange method. ### Issue: - Prior to saas-18.3, no onchange logic existed for assigning default accounts. With the introduction of the [onchange] (https://github.com/odoo/odoo/commit/334a8161cd2feb092cafedc35d94645900b40518) , archived income/expense or default cash diff. accounts can be assigned to journals. - This creates an inconsistency, as the domain [defined] (https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L70-#L82) for `default_account_id` only returns active accounts. ### Solution: - Since the domain for `default_account_id` returns only active accounts, this commit aims to update the onchange [logic](https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L540-#L551) in order to follow the same restriction, ensuring that only active accounts are assigned thereby preventing inconsistent behavior. OPW-5501539 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
This pull request addresses several issues within the Hoot testing framework, focusing on improving test reliability and execution speed. Specifically, it fixes errors in test logging, ensures proper test failure reporting, and cleans up test environment setup to prevent issues between tests.
Original PR description
Fixes for tests and testing framework. See commit messages for details. Enterprise: https://github.com/odoo/enterprise/pull/107286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250382 Forward-Port-Of: odoo/odoo#247137
This update resolves an issue where loyalty reward products were sometimes hidden within the Point of Sale (PoS) system. This change ensures that reward products are always visible and selectable during transactions, improving the customer experience and preventing lost sales. The fix was part of a larger effort to maintain the stability and reliability of the Odoo POS module.
Original PR description
Before this commit, a product used as a loyalty reward could be hidden in the PoS. opw-5918550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248925 Forward-Port-Of: odoo/odoo#248481
A slow process for adding attribute values to products was identified and resolved. The update replaces inefficient database queries with faster methods, significantly reducing loading times from 8 minutes to 2-3 minutes. This improves the user experience for customers managing many product attributes.
Original PR description
opw-4876370 Issue: A customer who uses many attribute values complained that the "add to products" button on product attribute values in their database was really slow (8 minutes or so). Upon investigation I found parts of the involved functions used iteration over a set of records, which proved notably slower to psql searches. Fix: Replacing the code with what I believe is equivalent operations making use of the `search` method to filter through the sets much quicker. Behaviour after fix: The process takes 2-3 minutes when running this commit on the aforementioned database, but it's still a major improvement compared to the previous time. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232149
This update resolves a problem where archived employees incorrectly retained their appraisal dates, causing scheduling conflicts. The fix ensures that archived employee appraisal dates are cleared, preventing future issues when managing appraisal plans for companies.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#108702 Forward-Port-Of: odoo/enterprise#100437
This update resolves a problem where updating a Bill of Materials (BoM) in a draft manufacturing order would incorrectly delete and then attempt to recreate related work orders, leading to errors. The fix ensures that work orders are only removed when they are no longer needed due to BoM changes, improving stability and preventing data inconsistencies.
Original PR description
Steps to reproduce: - Create a storable product P1 with the following BoM: - Component: C1 - Operation: OP1 - Create a draft MO for P1 - Update the BoM by adding a new component - Go back to the MO…
Steps to reproduce:
- Create a storable product P1 with the following BoM:
- Component: C1
- Operation: OP1
- Create a draft MO for P1
- Update the BoM by adding a new component
- Go back to the MO and click "Update from BoM"
Problem:
Missing Record
Record does not exist or has been deleted.
(Record: mrp.workorder(8,), User: 2)
Clicking on `update bom` will launch a call of the `action_update_bom`
which will itself call the `_link_bom` to update the record:
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418
The function will sets `bom_id` to False, which triggers
`_compute_workorder_ids` and `_compute_move_finished_ids`
(depends on bom_id). As the MO is in draft, related moves and
workorders are deleted.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L849
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L659
After that, it will try to delete the work orders again, and
since the operation no longer exists, an error will be triggered.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2586-L2587
opw-5947687
Forward-Port-Of: odoo/odoo#249336