Friday, February 27, 2026
11 changes · saas-18.4
Resolved issues and error corrections
This fixes an attendance issue where a future-dated attendance record could incorrectly block an employee from checking out. The system now looks only at past attendance records when deciding an employee's current attendance status, preventing kiosk checkout errors.
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 keeps website page creation and snippet preview dialogs working correctly in Firefox 148 and newer. It adjusts how empty preview frames are loaded so users can continue building pages without browser-specific loading issues.
Original PR description
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing…
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing context goes to about:blank, it completes > synchronously and is no longer replaced by a second parser-generated > document. Commit [e0796020] added the new page dialog in website, and used empty iframes to load each page template. Commit [edf81c13] added the add snippets dialog in website, and used an empty iframe to load the snippets previews. In both cases, before Firefox' fix, it meant we had to wait the recreation of the 2nd document before proceeding. This is no longer the case in Firefox >= 148. [release notes]: https://www.firefox.com/en-US/firefox/148.0/releasenotes/ [e0796020]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7 [edf81c13]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a Forward-Port-Of: odoo/odoo#250592
Changing the customer on a Point of Sale order will no longer apply a customer pricelist that is not available for that POS. This prevents incorrect pricing when older paid orders caused extra pricelists to be loaded in the session.
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#248904 Forward-Port-Of: odoo/odoo#247029
This fixes an issue in Email Marketing where repeatedly saving and reusing favorite templates could add unnecessary hidden layers to the email design. Over time, this could make template rendering fail, so the change keeps favorite-based templates clean and reliable.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a new mailing - Click on empty mail body and add only a Heading block - Set a subject, save it and click `Add to Templates` (favorites) - Create another mailing which use the first one as its template - Repeat the operation multiple times - Error will be raised at some point due to the depth of the template html **Issue:** Unnecessarily nested `div` are created when using favorites to create new `mailing.mailing` records, if those favorites are themselves based on other favorites etc., it later can lead to a recursion error when rendering the template. **Fix:** Check if the template comes from the favorites to avoid reapplying the wrappers on it. This seems to be solved in 19.0 with the refactoring (https://github.com/odoo/odoo/commit/354b8f60dbabcfac690d90bf657592e1347e4f86) opw-5275187 Forward-Port-Of: odoo/odoo#249476 Forward-Port-Of: odoo/odoo#238489
This fixes an issue where manually changing a product lot removal date during receipt processing could be overwritten after saving. Businesses can now trust that adjusted expiry-related stock dates remain as entered, improving inventory handling for products with expiration tracking.
Original PR description
version : saas-18.4+e Steps to reproduce ------------------ Create a product tracked by lots and enable the expiration date use (use_expiration_date = True). Create a receipt with this product and mark it as to do. Open the stock.move.line list view using the "Details" button on the receipt form and try to modify expiration date, it should modify the removal date due to the compute method. Then, try to modify the removal date and save the modifications. If you reopen the list view, the removal date has been computed again and its value changed. The fix ------------------ We explicitly set the readonly field to False for the removal_date field from the stock.move.line model in product_expiry. opw-5368007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes Romanian electronic invoices when a customer has no VAT number by correctly using the default VAT information. It also restores Romania-specific tax scheme handling so invoices classify VAT correctly for local compliance.
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 fixes a Point of Sale issue where selling multiple physical gift cards in one order could result in no gift cards being created. Businesses can now process several physical gift cards in a single sale reliably, preventing missed card issuance and follow-up corrections.
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#250898 Forward-Port-Of: odoo/odoo#249066
This fixes leave balance calculations for Indian sandwich leave rules when related leave requests are refused, reset, or approved again. Employees and HR teams will now see the correct number of leave days, including weekends and public holidays, after changes to neighboring leave requests.
Original PR description
## Steps to reproduce:- 1. Apply Friday to Monday leave and Tuesday is Public holiday and again apply single leave on Wednesday. - According to the sandwich leave rule, the leave should be counted as 6 days (Friday to Wednesday, including weekend and holiday). 2. Now refuse the Friday to Monday leave and re-approve again. 3. Now the leave count is updated to 5 days as it should be 6 days! ## Root cause:- On approve and reset actions the neighbor leaves where not recomputed. ## Fix:- - Override `_l10n_in_update_neighbors_duration_after_change` on approve and reset actions. - Updated `_l10n_in_update_neighbors_duration_after_change` so that current and neighbors both leaves are recomputed. task-[5446346](https://www.odoo.com/odoo/action-4043/5446346) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251111 Forward-Port-Of: odoo/odoo#244235
This update fixes an issue where the correct currency wasn't being applied when transferring CODA payments to multiple journals with the same IBAN but different currencies. The change ensures payments are routed to the correct journal based on its currency, improving financial accuracy and reducing the risk of errors.
Original PR description
When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect. This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen. [^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98 opw-5723017 Forward-Port-Of: odoo/enterprise#108677
This update fixes an issue where manually invoicing subscription upsells didn't correctly update their invoice status. The fix ensures that upsells are marked as 'Fully Invoiced' after invoicing, resolving a discrepancy in the system's tracking of payment status. This improves the accuracy of subscription billing reports.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585
Forward-Port-Of: odoo/enterprise#108614
Forward-Port-Of: odoo/enterprise#107967This update resolves an issue where Avatax taxes weren't correctly calculated during Stripe Express Checkout, leading to inaccurate order totals. The fix ensures that Avatax is now accurately applied when using Google Pay, aligning payment amounts with the final sales price including taxes. This improves payment accuracy and customer satisfaction.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793
Forward-Port-Of: odoo/enterprise#108957
Forward-Port-Of: odoo/enterprise#101579