Saturday, September 26, 2026
3 changes · saas-19.1
Resolved issues and error corrections
Fixed an issue where Point of Sale promotions could apply too small a discount when an order included both taxed products and negative-price lines, causing customers to be overcharged. Discounts are now distributed proportionally across tax groups so the final reward lines match the intended promotion amount.
Original PR description
Steps to reproduce: - Product A with a price-included tax, product B with a negative price and another tax (or none) - Promotion with a fixed amount discount on specific products (or on the order),…
Steps to reproduce: - Product A with a price-included tax, product B with a negative price and another tax (or none) - Promotion with a fixed amount discount on specific products (or on the order), both products eligible - Add both products to a PoS order Issue: The discount is split per tax group with a common factor, so the negative line gets a positive reward line, which is expected. But the reward lines add up to less than the discount and the customer pays too much. Cause: Since 7280f3597ece each tax group is capped with `Math.min(get_total_with_tax(), amount)`. A single tax group is compared with the total of the whole order: here the total includes the negative line, so the positive group is lowered while the negative one is kept as is. Fix: Apply the cap proportionally: every tax group is scaled by the ratio between the order total and the discountable amount when the total is lower. The scenario of 7280f3597ece gives the same result, and the reward lines add up to the discount whatever the number of tax groups. opw-6567973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288985 Forward-Port-Of: odoo/odoo#288853
Messages received while a Discuss channel is loading are no longer lost from view. This ensures users see new conversations immediately without waiting for another refresh or fetch.
Original PR description
Before this commit, a message received while a channel opens in Discuss does not appear, and stays out of the thread until the next fetch. This happens because the channel opens on its last read message through `loadAround`, which replaces the message list with the fetched messages. The bus handler of a new message adds it to that list as long as the thread displays the present, so the replacement drops what arrived during the fetch. This commit fixes the issue by putting those messages back: in the list when it displays the present, in `pendingNewMessages` when it does not, where `fetchMoreMessages` already picks them up. https://runbot.odoo.com/odoo/error/947188 Forward-Port-Of: odoo/odoo#290388 Forward-Port-Of: odoo/odoo#289976
Swiss payroll employee records now include the work permit expiration date on the Personal Information page. This keeps the information visible and available for contract status checks, helping avoid missed updates tied to expiring work permits.
Original PR description
…_date in employee form Add work_permit_expiration_date in Personnal Information page field is added in the standard view here: https://github.com/odoo/odoo/blob/18.0/addons/hr/views/hr_employee_views.xml#L184 this module override standard employee form view by making the entire Personal Information page invisible if CH and rewriting it: https://github.com/odoo/enterprise/blob/18.0/l10n_ch_hr_payroll_elm_transmission/views/l10n_ch_hr_payroll_employee_views.xml#L23 standard module hr_contract use this field in method [update_state](https://github.com/odoo/odoo/blob/18.0/addons/hr_contract/models/hr_contract.py#L184) called by cron [ir_cron_data_contract_update_state](https://github.com/odoo/odoo/blob/18.0/addons/hr_contract/data/hr_contract_data.xml#L53) Forward-Port-Of: odoo/enterprise#129875