Odoo Changelog — 2026-09-08

Tuesday, September 8, 2026

3 changes · saas-18.3

Bug Fixes(3)

Resolved issues and error corrections

[FIX] point_of_sale, pos_loyalty: exclude tips from discount

Coresaas-18.3point_of_salepos_discountpos_loyaltyMedium

This fixes an issue where loyalty or coupon discounts in the Point of Sale could incorrectly reduce customer tips added during restaurant payments. Tips are now excluded from discount calculations, helping ensure staff gratuities remain accurate and unaffected by promotions.

Original PR description

Currently, when a discount reward is applied onto an order and a tip is added later, the discount gets also applied on the tip. Steps to reproduce: ------------------- * Make sure all demo data…

Currently, when a discount reward is applied onto an order and a tip is added later, the discount gets also applied on the tip.

Steps to reproduce:
-------------------
* Make sure all demo data loyalty programs can also apply to the restaurant
* Make sure tipping is enabled in the restaurant
* Open restaurant
* Open a table, add items to the order
* Activate coupon code "10pc"
* Select payment
* On payment page, add a tip (10$)
* Go back to product page
> Observation: 10% discount is also applied on the tip

Why the fix:
------------
A tipping should never have a discount applied on it.

During the computation of the discountable amount we have 3 distinct flow (discount applies on the order, on the cheapest line, on some specific products)

- On the order: We always exclude tipping lines
- Cheapest line: When fetching the cheapest line amongst all lines we don't consider the tipping lines
- On specific: With the fix, tipping lines will always be excluded from the discountable lines. Even if the tip product was specified on the loyalty program. Should we still allow discounting tips if it was set in the program specifically?

We're using `is_discountable` instead for `is_tip` in case we want to extend the definition later on.

opw-6445364

Forward-Port-Of: odoo/odoo#281400

#point-of-sale#loyalty#discounts#tips#restaurant

[FIX] account_edi_proxy_client: Check unique user before contacting IAP

PR #286984

Coresaas-18.3account_edi_proxy_clientMedium

This fix checks for an existing proxy user before requesting new credentials from Odoo's IAP service. It prevents rare concurrent registrations from leaving a database with stale credentials that break later electronic invoicing proxy communication.

Original PR description

In the current flow, _register_proxy_user first calls IAP create_user, then inserts the returned credentials in account_edi_proxy_client.user. At the same time, IAP create_user_2 may replace an existing user with a new one with different credentials before local persistence settles.

So

Tx A calls IAP and gets credentials for remote user U1. Tx B calls IAP and gets credentials for remote user U2 and unlinks U1. Tx A persists U1 locally.
Tx B fails local insert due to a unique constraint.

Client DB keeps U1 credentials, but IAP now expects U2. Subsequent proxy calls from the client fail. The DB is left with stale, unusable credentials and cannot recover without re-registration.

IAP: https://github.com/odoo/iap-apps/pull/1816

task-6520501

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#285648

#e-invoicing#iap#registration#credentials

[FIX] project_enterprise: conflict shouldn't hit siblings

PR #130748

Enterprisesaas-18.3project_enterpriseMedium

Fixed an issue where one task that could not be scheduled correctly caused other tasks assigned to the same person to be pushed far into the future. This keeps dependent project work scheduled in the next available slot, improving planning accuracy in Gantt rescheduling.

Original PR description

Steps to reproduce:
1. create three tasks A,B & C with the same assignee
2. make tasks B and C depend on A and start on the `date_deadline`
of task A
3. set the duration of task B (processed before C) to be longer than
the 53-week search window
4. reschedule task A to end after task C starts

Problem:
A candidate that couldn't be scheduled was putting its
assignee in conflict, subtracting the inspected availability
while failing from the shared pool. Consequently, every later
candidate sharing that assignee got force-placed into the
same forward reschedule fallback that lands near the tail of
the 53-week search window instead of the next available slot.

Solution:
Each candidate should be evaluated on its own ability to
fit, and the time it occupies should count against the
shared pool.

opw-6380163
---

Forward-Port-Of: odoo/enterprise#129326

#project#scheduling#gantt#rescheduling

Currently, when a discount reward is applied onto an order and a tip is added later, the discount gets also applied on the tip. Steps to reproduce: ------------------- * Make sure all demo data loyalty programs can also apply to the restaurant * Make sure tipping is enabled in the restaurant * Open restaurant * Open a table, add items to the order * Activate coupon code "10pc" * Select payment * On payment page, add a tip (10$) * Go back to product page > Observation: 10% discount is also applied on the tip Why the fix: ------------ A tipping should never have a discount applied on it. During the computation of the discountable amount we have 3 distinct flow (discount applies on the order, on the cheapest line, on some specific products) - On the order: We always exclude tipping lines - Cheapest line: When fetching the cheapest line amongst all lines we don't consider the tipping lines - On specific: With the fix, tipping lines will always be excluded from the discountable lines. Even if the tip product was specified on the loyalty program. Should we still allow discounting tips if it was set in the program specifically? We're using `is_discountable` instead for `is_tip` in case we want to extend the definition later on. opw-6445364 Forward-Port-Of: odoo/odoo#281400

In the current flow, _register_proxy_user first calls IAP create_user, then inserts the returned credentials in account_edi_proxy_client.user. At the same time, IAP create_user_2 may replace an existing user with a new one with different credentials before local persistence settles. So Tx A calls IAP and gets credentials for remote user U1. Tx B calls IAP and gets credentials for remote user U2 and unlinks U1. Tx A persists U1 locally. Tx B fails local insert due to a unique constraint. Client DB keeps U1 credentials, but IAP now expects U2. Subsequent proxy calls from the client fail. The DB is left with stale, unusable credentials and cannot recover without re-registration. IAP: https://github.com/odoo/iap-apps/pull/1816 task-6520501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285648

Steps to reproduce: 1. create three tasks A,B & C with the same assignee 2. make tasks B and C depend on A and start on the `date_deadline` of task A 3. set the duration of task B (processed before C) to be longer than the 53-week search window 4. reschedule task A to end after task C starts Problem: A candidate that couldn't be scheduled was putting its assignee in conflict, subtracting the inspected availability while failing from the shared pool. Consequently, every later candidate sharing that assignee got force-placed into the same forward reschedule fallback that lands near the tail of the 53-week search window instead of the next available slot. Solution: Each candidate should be evaluated on its own ability to fit, and the time it occupies should count against the shared pool. opw-6380163 --- Forward-Port-Of: odoo/enterprise#129326