Odoo Changelog — 2026-05-22

Friday, May 22, 2026

15 changes · saas-19.1

Bug Fixes(15)

Resolved issues and error corrections

[FIX] sale_loyalty: prevent tax splitting on discount line

Coresaas-19.1sale_loyaltyaccountMedium

This update corrects a bug where tax calculations were incorrectly split on discount lines, particularly when orders were set to the Quebec fiscal position. The fix ensures that taxes are applied correctly, avoiding duplicate tax displays and maintaining accurate financial reporting. This improves order accuracy and reduces potential accounting errors.

Original PR description

Steps to produce:
---
- Install `website_sale`, `l10n_ca` & `accountant` modules with demo data.
- Switch to a `Canadian (CA) company.`
- Go to Settings and enable` Discounts, Loyalty & Gift Cards`.
- Go to` Website > eCommerce > Loyalty > Discount & Loyalty.`
- Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order.
- Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence).
- Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product.
- Open the website in an incognito window > Add the product to the cart > Apply the discount code.
- In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes.

Issue:
---
- The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST.

Root cause:
---
- When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST.
- After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST.
- In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur.
- In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line.

Fix:
---
- Avoid splitting taxes on the discount line in the sale order.
- Keep the original tax structure intact to prevent duplication after fiscal position changes.

[1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156
[2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296

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

Forward-Port-Of: odoo/odoo#265233
Forward-Port-Of: odoo/odoo#262147

#tax#discount#loyalty#order

[FIX] point_of_sale: only use AvaTax FP if activated in POS

PR #265723

Coresaas-19.1point_of_saleMedium

This update fixes an issue where the Point of Sale system incorrectly applied AvaTax fiscal positions even when AvaTax wasn't activated in the POS. The system now correctly ignores AvaTax fiscal positions when a customer doesn't have a configured fiscal position, ensuring accurate tax calculations. This prevents unintended tax application and improves POS functionality.

Original PR description

**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…

**Steps to reproduce:**
- Install Accounting and Point of Sale

- In Accounting settings, activate "AvaTax"
- Configure the AvaTax fiscal position and activate "Detect Automatically" option
- Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one

- Go to the settings of a point of Sale
- Activate "Flexible Taxes" and configure "Default" and "Allowed"
- Make sure that AvaTax fiscal position is not allowed
- Do not activate "AvaTax PoS Integration"

- Open a POS session
- Select a customer with an address in the US and without fiscal position
- Check the fiscal position

**Issue:**
The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS.

**Cause:**
We force the use of a fiscal position if it is configured on a customer.
In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected.

**Solution:**
When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax.

opw-6154089




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

Forward-Port-Of: odoo/odoo#263342

[FIX] pos_avatax: only use AvaTax FP if activated in POS

PR #117987

Enterprisesaas-19.1pos_avataxMedium

This update fixes an issue where the POS system incorrectly applied AvaTax fiscal positions even when AvaTax wasn't activated in the POS settings. The system now correctly ignores AvaTax fiscal positions when a customer doesn't have a defined fiscal position, ensuring accurate tax calculations for Point of Sale transactions. This improves the reliability of the POS tax functionality.

Original PR description

**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…

**Steps to reproduce:**
- Install Accounting and Point of Sale

- In Accounting settings, activate "AvaTax"
- Configure the AvaTax fiscal position and activate "Detect Automatically" option
- Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one

- Go to the settings of a point of Sale
- Activate "Flexible Taxes" and configure "Default" and "Allowed"
- Make sure that AvaTax fiscal position is not allowed
- Do not activate "AvaTax PoS Integration"

- Open a POS session
- Select a customer with an address in the US and without fiscal position
- Check the fiscal position

**Issue:**
The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS.

**Cause:**
We force the use of a fiscal position if it is configured on a customer.
In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected.

**Solution:**
When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax.

opw-6154089

Forward-Port-Of: odoo/enterprise#116626

[FIX] pos_event: keep offline event registrations until order is synced

PR #265724

Coresaas-19.1pos_eventMedium

This update ensures that event tickets are automatically created when an offline POS sale is later synced to the system. Previously, a page reload would cause the ticket creation to fail. The fix corrects a logic error in how the system manages offline order data, guaranteeing accurate ticket generation.

Original PR description

When selling event tickets in POS while offline, the order could be synced later but without creating event registrations (tickets) after a page reload.

Steps to reproduce:
-------------------
* Open a POS session with `pos_event`
* Sell an event ticket
* Switch to offline mode
* Validate payment while offline (order becomes paid but unsynced)
* Reload/close and reopen POS, then reconnect
* Let the order sync

> Observation:
The `pos.order` is created on the backend, but `event.registration` and `event.registration.answer` are missing so tickets are not generated.

Why the fix:
------------
`pos_event` used `order.finalized` as IndexedDB cleanup condition for `event.registration` and `event.registration.answer`. For paid-but-unsynced orders, `finalized` is already true, so those records can be removed from IndexedDB too early. After reload, the order is restored/synced but without its event registration payload.

Implementation:
---------------
Use `order.canBeRemovedFromIndexedDB` instead of `order.finalized` for `event.registration` and `event.registration.answer` retention rules, so records are kept locally until the order is truly synced (server id assigned) or canceled.

Test Note:
---------------
Use case is hard to simulate exactly.
Add a basic unit test to assert both registration models are kept for paid unsynced orders and only removable once synced.

opw-6056079

Forward-Port-Of: odoo/odoo#265201
Forward-Port-Of: odoo/odoo#256615

[FIX] sign: preserve bookmarks and links

PR #118026

Enterprisesaas-19.1signMedium

This update resolves an issue where signed PDFs lost their original bookmarks and links, disrupting navigation and document integrity. The fix ensures that signed documents retain their original structure and functionality, allowing users to easily navigate and access information within the signed PDF.

Original PR description

Version
- 18.0

Steps to reproduce:
1. Upload a PDF document containing bookmarks and internal/external links.
2. Sign the document and download the signed PDF.
3. Open the downloaded file and check the bookmarks and links.

Issue:
When a signed document was downloaded, the original PDF bookmarks And the links were not working.
This broke structured navigation and affected document integrity.

Fix:
The PDF signing process has been updated to preserve the original bookmarks and ensure internal and external links remain functional after signing.

Impact:
- Signed documents remain navigable and consistent with the original PDF.
- Preserves document structure and integrity.

Task- 4915124

Forward-Port-Of: odoo/enterprise#117881
Forward-Port-Of: odoo/enterprise#108684

#pdf#security#bookmarks#links

[FIX] point_of_sale: refresh after applying combo

PR #261294

Coresaas-19.1point_of_saleMedium

This update fixes an issue where applying a combo to an order already sent to the backend would cause the original order items to reappear after a page refresh. The fix ensures that the order is synchronized with the backend after a combo is applied, providing a consistent and accurate view for the user.

Original PR description

Steps to reproduce:
- Make an order that could be a combo
- Send the order to preparation
- Apply the combo
- Refresh page

=> A new combo appears and the original orderlines are still there.

Issue:
When applying a combo to an order that has already been sent to the backend it is not synched with the backend so when you refresh the original orderlines are fetched from the backend.

Fix:
If the orderlines have been sent to the backend sync the order after applying the combo.

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

#point_of_sale#combo#order#synchronization

[FIX] point_of_sale: balance order payment and invoice

PR #265942

Coresaas-19.1point_of_saleMedium

This update fixes a problem where Point of Sale orders weren't correctly calculating payments and invoices, leading to errors. The fix ensures that order details are properly updated during the validation process, resolving the 'No cash statement found' error and preventing 'entry not balanced' issues when generating invoices. This improves the reliability of the POS system.

Original PR description

### Steps to reproduce:
- Download 'Point of Sale' and 'Contacts' app
- Create a customer with a pricelist that includes a percentage discount
- Create a shop with the following properties:
    - Default preset = 'Takeout' with a standard 40hr/week schedule
    - Payments = 'Card' and 'Customer Account'
    - Pricelists = a 'Default' and the discounted pricelist
- Create a POS order (without choosing a customer)
- Add products to the order, and select 'Customer Account' payment method
- Select the created customer
    * Pricelist applies → Order total decreases.
    * Payment now exceeds total → Negative change shown.
- Disable 'Invoice' checkbox.
- Click 'Validate' → Show popup 'No cash statement found for this session.'
- Again click 'Customer Account' → Add another payment line (negative).
- Process the order payment
- Close Session
- Try to create an invoice for the order
> Error: Entry not balanced

### Cause of Issue:
When 'Validate' is clicked for the first time and `syncAllOrders()` is called, `serializeForORM()`
clears the `_dirty` state tracking after the serialization. https://github.com/odoo/odoo/blob/418b103dab782d81a33d2a7afd8ec3767d7a82df/addons/point_of_sale/static/src/app/services/pos_store.js#L1501-L1534

When the 'No cash statement found' error occurs, the backend rolls back the changes made to the
order lines.

Then, since the `order.lines` weren't marked as dirty (no changes occured to them) and `payment.ids`
were marked as dirty, when 'Validate' is clicked for the second time, the js side doesn't send the
`order.lines` again, so the backend uses the existing, undiscounted lines.

The mismatch happens because while the product lines are undiscounted, the `payment.ids` are
correct (because a new 'Customer Account' line was added, so `payment.ids` were sent again).
Hence, `amount_total` and `amount_paid` were calculated with discounts applied, while individual
`line.price_unit` values remained at list price, resulting in invoice line amounts not matching
the amount paid and causing "entry not balanced" errors during invoice generation.

### Fix:
Preserved the `_ dirty` state commands, ensuring that when the order is reserialized on retry,
the line data are included in the second `sync_from_ui` payload.

opw-6080597

Forward-Port-Of: odoo/odoo#259636

[FIX] industry_fsm_{stock,sale}: compute dropship delivered quantity for extra products

PR #118075

Enterprisesaas-19.1salestockfsmMedium

This update resolves an issue where the delivered quantity for dropship products was incorrectly set to 1 before order confirmation. The fix ensures the quantity accurately reflects stock availability and triggers the necessary calculations when a purchase order is created, improving dropship order accuracy.

Original PR description

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#117727
Forward-Port-Of: odoo/enterprise#115760

[FIX] l10n_ro: correct end balance field in trial balance report

PR #118057

Enterprisesaas-19.1l10n_ro_reportsMedium

This update fixes an issue where the End Balance figures in the Romanian Trial Balance reports were inaccurate when the report hierarchy was enabled. The fix prevents double-counting of account groups, ensuring the trial balance totals align correctly and provide accurate financial reporting for Romanian businesses.

Original PR description

### Issue before this commit:
The total row for the End Balance columns in the Romanian 4-column and 5-column Trial Balance reports displayed incorrect values when the report hierarchy was enabled.

### Steps to reproduce the issue:
1. Downaload Accounting and l10n_ro
2. Switch to RO company
3. Go to Trial Balance report and be sure that Posted Entries, Accrual Basis are setted on Hierarchy and Subtotals
4. See that the End Blance both debit and credit is not correct

### Cause of the issue:
The _custom_line_postprocessor method iterated over all report lines indiscriminately, adding account group subtotals to the running accumulator and causing duplicate counting.

### Reason to introduce the fix:
To eliminate group double-counting and providing consistency with the totals in all the trial balances reports.

opw-6146200

Forward-Port-Of: odoo/enterprise#117855

#reporting#financials#ro#trial balance

[FIX] hr_attendance: prevent incorrect overtime for flexible schedules

PR #265933

Coresaas-19.1hr_attendanceMedium

This update resolves an issue where employees on flexible work schedules were incorrectly flagged for overtime. The fix adjusts how the system calculates expected work hours, now accurately considering the employee's flexible calendar hours instead of relying on outdated synthetic schedules. This ensures accurate overtime calculations for employees with varied work arrangements.

Original PR description

**Steps to reproduce:** - Create a flexible 32h/week calendar (8h/day, 4 days) - Assign it to an employee with the Default Ruleset - Create attendances: 8h on Monday, Tuesday, Friday, and Saturday…

**Steps to reproduce:**
- Create a flexible 32h/week calendar (8h/day, 4 days)
- Assign it to an employee with the Default Ruleset
- Create attendances: 8h on Monday, Tuesday, Friday, and Saturday (32h total, matching the weekly budget)
- Select the list view and go to the month of the attendances
- Employee shows 16:00 Worked Extra Hours (8h on Fri + 8h on Sat)

**Cause:**
`resource.calendar._attendance_intervals_batch` generates work intervals for flexible calendars by front loading the weekly hour budget onto the first days of the week (Mon 8h, Tue 8h, Wed 8h, Thu 8h for a 32h calendar), But days beyond the budget (Fri, Sat, Sun) get zero hours.

The two overtime rule paths relies on these synthetic intervals:

1) The quantity rule: `_get_daterange_overtime_undertime_intervals_for_quantity_rule()` computed `expected_duration` by intersecting the synthetic schedule with each day. For Fri/Sat the intersection was empty (expected = 0) -> all worked hours counted as overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L302-L304

**update** solved by: https://github.com/odoo/odoo/pull/265120/changes/94d4bfffa053cd78ce07ff07ab14b53e8d931053

2) The timing rule: `_get_rules_intervals_by_timing_type()` derived "work_days" from the synthetic schedule and inverted them to get "non_work_days". (Fri, Sat, Sun) were classified as non-working days, therefore, any attendance on those days triggered full overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L421-L433

**Solution:**
For flexible calendars in the overtime rule consumer:
- Quantity rules: read expected hours directly from the calendar's `hours_per_day` / `hours_per_week` instead of the synthetic schedule intervals, subtracting any leaves in the period
- Timing rules: treat the entire attendance date range (minus leaves) as potential work days, so that `non_work_days` is empty for flexible employees (they can work any day of the week)

opw-6067063

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

Forward-Port-Of: odoo/odoo#263840

[FIX] pos_restaurant_preparation_display: fix orderline general note cancellation

PR #118094

Enterprisesaas-19.1pos_restaurant_preparation_displayMedium

This update resolves an issue where removing a general note from a restaurant orderline caused the preparation display to incorrectly mark the line as cancelled and create a new one. The fix ensures that note history is recorded regardless of whether the note is confirmed, allowing the system to accurately update existing orderlines instead of creating duplicates.

Original PR description

Steps to reproduce:
---------
1. Create an order with an orderline general note.
2. Send the order to the preparation display.
3. Remove the note from orderline.
4. Resend the order 

Issue:
---------------
Removing the note changes the preparation line key, so the preparation
display marks the old line as cancelled and creates a new one instead of
updating the existing line.

Cause:
-----------
The note history was only recorded when the note was confirmed.
If the user simply removes/clears the note, no note history entry is generated, 
so the backend cannot match the previous key with the updated key.

Fix:
----------
Record note history even when the note is discarded (not only when
confirmed. This allows the backend to match the old and new keys and
update the line instead of cancelling it.

Task-6101501
Related PR - https://github.com/odoo/odoo/pull/258632

Forward-Port-Of: odoo/enterprise#117943
Forward-Port-Of: odoo/enterprise#113514

#pos

[FIX] web: Allow users to take photo on image input type

PR #265944

Coresaas-19.1webMedium

This update resolves an issue where users on Android 14 couldn't access their device's camera when selecting files through the image input field. The fix ensures users can now take photos directly through the image input, improving usability on this platform. This change addresses a compatibility problem with recent Android versions.

Original PR description

Since Android 14 we don't have option to take a photo on clicking on file input in Chrome.

This for example will allow only images but no option "Camera"
```html
    <input type="file" accept="image/*/>
```
A workaround is to use a dummy mimetype (`*/*`), example `dummy/allowAndroidCamera` The fix will be applied on image widget in addition to the original `acceptedFileExtensions` to not override the existing `accept` attribute

You can test the different behaviour here: https://jsfiddle.net/n0vs6h3b/

Linked url
https://blog.addpipe.com/html-file-input-accept-video-camera-option-is-missing-android-14-15/ https://stackoverflow.com/questions/77876374/html-input-type-file-not-working-to-pull-up-camera-for-pixel-android-14-comb/79163998#79163998 https://issues.chromium.org/issues/40937303


opw-6040375

Forward-Port-Of: odoo/odoo#265750

#mobile#android#image upload

[FIX] website_sale_renting_planning: limit number of product available

PR #113525

Enterprisesaas-19.1website_sale_renting_planningMedium

This update fixes a bug that allowed users to order unlimited quantities of rental products. The system now limits the available quantity based on the product's rental availability, ensuring accurate resource allocation and preventing overbooking. This change improves the reliability and efficiency of our rental service.

Original PR description

It is possible to order as many products as we want of a rental product
that synchronizes shifts depending on a specific service

Steps to reproduce:
1. Install website_sale_renting_planning module
2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period
3. In the General Information tab, click on the internal link to "Developer"
4. Enable Sync Shifts and Rental Orders
5. Go to the eCommerce website and search for product "test"
6. You can add as many quantity of the product to your cart

Issue:
We don't limit the maximum quantity of the product

Solution:
Look through the renting availabilities of the product and set the
maximum quantity to the minimum of the availabilities relevant to the
renting dates selected

opw-6009928

Forward-Port-Of: odoo/enterprise#111793

#rental#availability

[FIX] pos_self_order: fix custom attr behivour in kiosk mode

PR #265763

Coresaas-19.1pos_self_orderMedium

This update resolves a problem where custom product attributes weren't correctly displayed in the POS kiosk mode. Specifically, when a product had a single custom attribute, options weren't shown, and the 'Add to Cart' button was disabled. The fix ensures that custom attributes are displayed and functional within the kiosk experience, improving usability.

Original PR description

this pr fixes 3 bug, as all are closely related.

  Step to reproduce (hide is_custom attr in kiosk mode):
  - have two attributes A and B
  - A has only 1 attribute value with is_custom = True
  - B can have any two value ( ex. gender: male/female)
  - use it on a product  and make it available in POS for kiosk
  - start kiosk and open that product

  Observation:
  - we do not get option to select option from A but the heading is visible
  - when we select from B, Add to cart is disabled.

  Cause:
  - we do not allow attribute values with is_custom = True in kiosk
  - but we display the attribute regardless
  - the Add to cart btn depends on `selectedValues`, which requires
  value from each attribute, in this case, we are not seletion anything from A
  - so it is disabled

  Fix:
  - we introduced  `attributesToDisplay` which will hide heading in case of single
  custom value for any attribute
  - for Add to cart, wenow do not expect value from `is_custom`  attribute values.

   Allow product with 1 attr which is `is_custom` to be
   configurable in configs other than kiosk) correct fix for commit

   Step to reproduce
  - have attributes A
  - A has only 1 attribute value with is_custom = True
  - use it on a product and make it available in POS
  - start pos and open that product

  Observation:
  - we do not get option to select add text for A

  Cause:
  - in pos, we consider product to be configurable only it has more than 1
  attributes, which misses is_custom attr

  Fix:
  - we backport commit[1] and also considers its side effect by introducing
  `isProductConfigurable` for pos_self_order, which will still avoid
  `is_custom` attrs for kiosk

  [1] https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7

  Empty page is displayed if product has only `is_custom` attribute value
  and other attribute with type other then 'no_variant' for combo item

   Step to reproduce
  - have attributes A and B
  - A has only 1 attribute value with is_custom = True
  - B has two values with type "always"
  - use it on a product and add that product in combo item and make it available
    in Kisok
  - start kiosk and open that combo and select that product

  Observation:
  - we do not get option to select

  Cause:
  - `availableAttributeValue` only show `no_variant` and non `is_custom` attribute
     values in attributeSelection component.

  Fix:
  - before mounting Attributeselection component, we check if product has required
    attribute or not.

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

Forward-Port-Of: odoo/odoo#265238
Forward-Port-Of: odoo/odoo#257880

[FIX] esg: fix import of emissions

PR #118004

Enterprisesaas-19.1esgesg_hr_fleetMedium

This update fixes an issue where the 'import emissions' action wasn't appearing in the ESG module's menu. The fix allows the import action to be displayed, even with a restricted 'create' setting in the list view, ensuring users can easily access and utilize the ESG carbon emission reporting feature.

Original PR description

Before this commit, the "import" action of emissions in the ESG module was not visible in the COG menu. It is because the "create" attribute of the list view is disabled, which prevents the menu item from being displayed. With this commit, we override the standard behavior in this particular action, by allowing the import action to show up in the COG menu, even if the "create" attribute is disabled.

version-19.1

#esg#reporting#carbon emissions

Steps to produce: --- - Install `website_sale`, `l10n_ca` & `accountant` modules with demo data. - Switch to a `Canadian (CA) company.` - Go to Settings and enable` Discounts, Loyalty & Gift Cards`. - Go to` Website > eCommerce > Loyalty > Discount & Loyalty.` - Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order. - Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence). - Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product. - Open the website in an incognito window > Add the product to the cart > Apply the discount code. - In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes. Issue: --- - The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST. Root cause: --- - When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST. - After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST. - In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur. - In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line. Fix: --- - Avoid splitting taxes on the discount line in the sale order. - Keep the original tax structure intact to prevent duplication after fiscal position changes. [1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156 [2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296 opw-6145674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265233 Forward-Port-Of: odoo/odoo#262147

**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263342

When selling event tickets in POS while offline, the order could be synced later but without creating event registrations (tickets) after a page reload. Steps to reproduce: ------------------- * Open a POS session with `pos_event` * Sell an event ticket * Switch to offline mode * Validate payment while offline (order becomes paid but unsynced) * Reload/close and reopen POS, then reconnect * Let the order sync > Observation: The `pos.order` is created on the backend, but `event.registration` and `event.registration.answer` are missing so tickets are not generated. Why the fix: ------------ `pos_event` used `order.finalized` as IndexedDB cleanup condition for `event.registration` and `event.registration.answer`. For paid-but-unsynced orders, `finalized` is already true, so those records can be removed from IndexedDB too early. After reload, the order is restored/synced but without its event registration payload. Implementation: --------------- Use `order.canBeRemovedFromIndexedDB` instead of `order.finalized` for `event.registration` and `event.registration.answer` retention rules, so records are kept locally until the order is truly synced (server id assigned) or canceled. Test Note: --------------- Use case is hard to simulate exactly. Add a basic unit test to assert both registration models are kept for paid unsynced orders and only removable once synced. opw-6056079 Forward-Port-Of: odoo/odoo#265201 Forward-Port-Of: odoo/odoo#256615

Version - 18.0 Steps to reproduce: 1. Upload a PDF document containing bookmarks and internal/external links. 2. Sign the document and download the signed PDF. 3. Open the downloaded file and check the bookmarks and links. Issue: When a signed document was downloaded, the original PDF bookmarks And the links were not working. This broke structured navigation and affected document integrity. Fix: The PDF signing process has been updated to preserve the original bookmarks and ensure internal and external links remain functional after signing. Impact: - Signed documents remain navigable and consistent with the original PDF. - Preserves document structure and integrity. Task- 4915124 Forward-Port-Of: odoo/enterprise#117881 Forward-Port-Of: odoo/enterprise#108684

Steps to reproduce: - Make an order that could be a combo - Send the order to preparation - Apply the combo - Refresh page => A new combo appears and the original orderlines are still there. Issue: When applying a combo to an order that has already been sent to the backend it is not synched with the backend so when you refresh the original orderlines are fetched from the backend. Fix: If the orderlines have been sent to the backend sync the order after applying the combo. 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

### Steps to reproduce: - Download 'Point of Sale' and 'Contacts' app - Create a customer with a pricelist that includes a percentage discount - Create a shop with the following properties: - Default preset = 'Takeout' with a standard 40hr/week schedule - Payments = 'Card' and 'Customer Account' - Pricelists = a 'Default' and the discounted pricelist - Create a POS order (without choosing a customer) - Add products to the order, and select 'Customer Account' payment method - Select the created customer * Pricelist applies → Order total decreases. * Payment now exceeds total → Negative change shown. - Disable 'Invoice' checkbox. - Click 'Validate' → Show popup 'No cash statement found for this session.' - Again click 'Customer Account' → Add another payment line (negative). - Process the order payment - Close Session - Try to create an invoice for the order > Error: Entry not balanced ### Cause of Issue: When 'Validate' is clicked for the first time and `syncAllOrders()` is called, `serializeForORM()` clears the `_dirty` state tracking after the serialization. https://github.com/odoo/odoo/blob/418b103dab782d81a33d2a7afd8ec3767d7a82df/addons/point_of_sale/static/src/app/services/pos_store.js#L1501-L1534 When the 'No cash statement found' error occurs, the backend rolls back the changes made to the order lines. Then, since the `order.lines` weren't marked as dirty (no changes occured to them) and `payment.ids` were marked as dirty, when 'Validate' is clicked for the second time, the js side doesn't send the `order.lines` again, so the backend uses the existing, undiscounted lines. The mismatch happens because while the product lines are undiscounted, the `payment.ids` are correct (because a new 'Customer Account' line was added, so `payment.ids` were sent again). Hence, `amount_total` and `amount_paid` were calculated with discounts applied, while individual `line.price_unit` values remained at list price, resulting in invoice line amounts not matching the amount paid and causing "entry not balanced" errors during invoice generation. ### Fix: Preserved the `_ dirty` state commands, ensuring that when the order is reserialized on retry, the line data are included in the second `sync_from_ui` payload. opw-6080597 Forward-Port-Of: odoo/odoo#259636

### Steps to reproduce: - In the settings enable dropshipping - Create a storable product P, enable the dropshipping and set a vendor - Create and confirm a sale order for a field service - Open the related task > Products > Add 1 unit of P - Go back to the sale order > an RFQ has been created #### > The delivered quantity of P is set to 1 ### Cause of the issue: Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83 provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237 The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198 Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute). Fix: The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167 opw-6104326 Forward-Port-Of: odoo/enterprise#117727 Forward-Port-Of: odoo/enterprise#115760

### Issue before this commit: The total row for the End Balance columns in the Romanian 4-column and 5-column Trial Balance reports displayed incorrect values when the report hierarchy was enabled. ### Steps to reproduce the issue: 1. Downaload Accounting and l10n_ro 2. Switch to RO company 3. Go to Trial Balance report and be sure that Posted Entries, Accrual Basis are setted on Hierarchy and Subtotals 4. See that the End Blance both debit and credit is not correct ### Cause of the issue: The _custom_line_postprocessor method iterated over all report lines indiscriminately, adding account group subtotals to the running accumulator and causing duplicate counting. ### Reason to introduce the fix: To eliminate group double-counting and providing consistency with the totals in all the trial balances reports. opw-6146200 Forward-Port-Of: odoo/enterprise#117855

**Steps to reproduce:** - Create a flexible 32h/week calendar (8h/day, 4 days) - Assign it to an employee with the Default Ruleset - Create attendances: 8h on Monday, Tuesday, Friday, and Saturday (32h total, matching the weekly budget) - Select the list view and go to the month of the attendances - Employee shows 16:00 Worked Extra Hours (8h on Fri + 8h on Sat) **Cause:** `resource.calendar._attendance_intervals_batch` generates work intervals for flexible calendars by front loading the weekly hour budget onto the first days of the week (Mon 8h, Tue 8h, Wed 8h, Thu 8h for a 32h calendar), But days beyond the budget (Fri, Sat, Sun) get zero hours. The two overtime rule paths relies on these synthetic intervals: 1) The quantity rule: `_get_daterange_overtime_undertime_intervals_for_quantity_rule()` computed `expected_duration` by intersecting the synthetic schedule with each day. For Fri/Sat the intersection was empty (expected = 0) -> all worked hours counted as overtime. https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L302-L304 **update** solved by: https://github.com/odoo/odoo/pull/265120/changes/94d4bfffa053cd78ce07ff07ab14b53e8d931053 2) The timing rule: `_get_rules_intervals_by_timing_type()` derived "work_days" from the synthetic schedule and inverted them to get "non_work_days". (Fri, Sat, Sun) were classified as non-working days, therefore, any attendance on those days triggered full overtime. https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L421-L433 **Solution:** For flexible calendars in the overtime rule consumer: - Quantity rules: read expected hours directly from the calendar's `hours_per_day` / `hours_per_week` instead of the synthetic schedule intervals, subtracting any leaves in the period - Timing rules: treat the entire attendance date range (minus leaves) as potential work days, so that `non_work_days` is empty for flexible employees (they can work any day of the week) opw-6067063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263840

Steps to reproduce: --------- 1. Create an order with an orderline general note. 2. Send the order to the preparation display. 3. Remove the note from orderline. 4. Resend the order Issue: --------------- Removing the note changes the preparation line key, so the preparation display marks the old line as cancelled and creates a new one instead of updating the existing line. Cause: ----------- The note history was only recorded when the note was confirmed. If the user simply removes/clears the note, no note history entry is generated, so the backend cannot match the previous key with the updated key. Fix: ---------- Record note history even when the note is discarded (not only when confirmed. This allows the backend to match the old and new keys and update the line instead of cancelling it. Task-6101501 Related PR - https://github.com/odoo/odoo/pull/258632 Forward-Port-Of: odoo/enterprise#117943 Forward-Port-Of: odoo/enterprise#113514

Since Android 14 we don't have option to take a photo on clicking on file input in Chrome. This for example will allow only images but no option "Camera" ```html <input type="file" accept="image/*/> ``` A workaround is to use a dummy mimetype (`*/*`), example `dummy/allowAndroidCamera` The fix will be applied on image widget in addition to the original `acceptedFileExtensions` to not override the existing `accept` attribute You can test the different behaviour here: https://jsfiddle.net/n0vs6h3b/ Linked url https://blog.addpipe.com/html-file-input-accept-video-camera-option-is-missing-android-14-15/ https://stackoverflow.com/questions/77876374/html-input-type-file-not-working-to-pull-up-camera-for-pixel-android-14-comb/79163998#79163998 https://issues.chromium.org/issues/40937303 opw-6040375 Forward-Port-Of: odoo/odoo#265750

It is possible to order as many products as we want of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. You can add as many quantity of the product to your cart Issue: We don't limit the maximum quantity of the product Solution: Look through the renting availabilities of the product and set the maximum quantity to the minimum of the availabilities relevant to the renting dates selected opw-6009928 Forward-Port-Of: odoo/enterprise#111793

this pr fixes 3 bug, as all are closely related. Step to reproduce (hide is_custom attr in kiosk mode): - have two attributes A and B - A has only 1 attribute value with is_custom = True - B can have any two value ( ex. gender: male/female) - use it on a product and make it available in POS for kiosk - start kiosk and open that product Observation: - we do not get option to select option from A but the heading is visible - when we select from B, Add to cart is disabled. Cause: - we do not allow attribute values with is_custom = True in kiosk - but we display the attribute regardless - the Add to cart btn depends on `selectedValues`, which requires value from each attribute, in this case, we are not seletion anything from A - so it is disabled Fix: - we introduced `attributesToDisplay` which will hide heading in case of single custom value for any attribute - for Add to cart, wenow do not expect value from `is_custom` attribute values. Allow product with 1 attr which is `is_custom` to be configurable in configs other than kiosk) correct fix for commit Step to reproduce - have attributes A - A has only 1 attribute value with is_custom = True - use it on a product and make it available in POS - start pos and open that product Observation: - we do not get option to select add text for A Cause: - in pos, we consider product to be configurable only it has more than 1 attributes, which misses is_custom attr Fix: - we backport commit[1] and also considers its side effect by introducing `isProductConfigurable` for pos_self_order, which will still avoid `is_custom` attrs for kiosk [1] https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7 Empty page is displayed if product has only `is_custom` attribute value and other attribute with type other then 'no_variant' for combo item Step to reproduce - have attributes A and B - A has only 1 attribute value with is_custom = True - B has two values with type "always" - use it on a product and add that product in combo item and make it available in Kisok - start kiosk and open that combo and select that product Observation: - we do not get option to select Cause: - `availableAttributeValue` only show `no_variant` and non `is_custom` attribute values in attributeSelection component. Fix: - before mounting Attributeselection component, we check if product has required attribute or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265238 Forward-Port-Of: odoo/odoo#257880

Before this commit, the "import" action of emissions in the ESG module was not visible in the COG menu. It is because the "create" attribute of the list view is disabled, which prevents the menu item from being displayed. With this commit, we override the standard behavior in this particular action, by allowing the import action to show up in the COG menu, even if the "create" attribute is disabled. version-19.1