Steps to produce:
---
- Install `website_sale` module.
- Go to website > open editor.
- Add an image snippet to the homepage.
- Click on the image and enable `Pop-up on Click`, then save.
- Click on the image.

Traceback:
---
`TypeError: Cannot read properties of undefined (reading 'length')`

Root cause:
---
- In the `setup` method, when the image is not part of a carousel,
  the element `.carousel-indicators` does not exist. As a result,
  `indicatorEl` is null, and the guarded block(at [1]) is skipped.
  Because of this, `this.liEls` is never initialized.
- Later, when the `onSlidCarousel` method is executed,
  its internal condition evaluates and find `liEls` as null and
  then `hide` method is called(see [2]).
- Inside the `hide` method, the code attempts to iterate
  over `this.liEls`(see [3]).

Solution:
---
- Initialized `liEls` in `setup()` to ensure it is always defined.
- Added a length check in `onSlidCarousel()` to execute the logic
  only when `liEls.length > 0`.
- This prevents this.page from being computed using invalid
  values and avoids it being set to `NaN`.
- Additionally, as requested by the boje(po), hide the popup
  on click setting on product images.
  
**Alternative approaches:**

1. We can also call the `onSlideCarousel` method from `setup`
    when multiple images are present.
2. Also, we can add a simple check inside the `onSlideCarousel`
    method to ensure that `liEls` is defined before proceeding.

[1]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L31-L57
[2]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L144-L152
[3]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L119-L120

opw-5921123
---

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

Forward-Port-Of: odoo/odoo#247936

Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure

According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:
CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value)
CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE

Steps to reproduce:

Install l10n_ec_edi module
Go to Settings > Invoicing > Ecuadorian Localization
In Electronic Invoicing > Regime, select rimpe_emprendedor
In Electronic Invoicing > Regime, configure a SRI Connection
Post an customer invoice

**Validation error occurring during the electronic signing process (using .p12 certificates):**
`35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR `

Forward-Port-Of: odoo/enterprise#109147

**Steps to reproduce:
1. Create DE company (EUR currency)
2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month)
3. Install l10n_de_reports
4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank]
5. Create USD invoice for XX/02/26 and confirm it
6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment)
7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data

**Description of issue:
The currency exchange rate difference entries in the exported file are shown as 0

**Expected behavior:
The actual currency exchange difference values should be displayed

**Why this happens?
The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export.

**The fix:
Updated the logic to use the line balance when the entry is identified as a currency exchange difference.

opw-5358954

Forward-Port-Of: odoo/enterprise#109655
Forward-Port-Of: odoo/enterprise#107268

**Issue**
Computing the price from BOM can be incorrect when the BOM is defined on a multi-variant product.

**Steps to reproduce**
- Create a product with several variants
- Create a BOM for that product without specifying the product variant
- Define an operation restricted to a specific variant V
- Associate the operation with a workcenter with:
    - Non-null cost per hour (e.g. 100)
    - Time efficiency lower than 100% (e.g. 50%)
- Go to the product page > Variants > variant V
- Click on "Compute price from BOM"
-> The result will be 100 instead of 200 in this example.

Please notice that the price is correctly computed in the BOM overview

**Cause**
Accessing the BOM triggers a `web_read` including `operation_ids`,
which requires computing `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L77

During this computation, the associated product is retrieved:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L106

But since no product is given in the context and the BOM has been created without specifying the product variant
(`bom_id.product_id` is empty), then it retrieves all the product variant associated to the BOM, which leads to
arbitrary default value that ignores work center efficiency:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L107-L111
While clicking on "Compute price from BOM":
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L33
it will ultimately needs to compute the cost:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L74
which relies on `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L131
and since no context is provided, `time_total` is already in the cache, so the default value is used.
Please notice that in BOM overview, the problem does not occur because the provided context retriggers the compute method:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L806
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L835

opw-5909570

Forward-Port-Of: odoo/odoo#248758

[FIX] hr_payroll: adjust proper version in payslip

Bug reproduction: Select an employee that has at least 1 payslip already, go to employee tab -> smart button payslip -> then you are in list view of payslips -> off cycle -> then your version is the first version of the employee, even though you are trying to create a payslip with the latest version of you. 

Bug cause:
    1 - Before version saas-19.2, date_from in hr_payslip is used to determine the version_id (in compute_version_id)
    2 - When version>=19.2, date_to is used for version_id calculation, also employee_id is passed in context when we are coming from smart payslip button.
    3 - Both compute_version_id (due to employee context) and compute_date_to triggers in hr_payslip and there is kind of race condition in here.
        3.1 - Even though sometimes date_to is started to calculate before, when version_id is calculating the date_to is always False, the computation is not done yet.
        3.2 - Since date_to is false, _get_version in hr_employee returns the first version of the employee, that's why in UI it is always the first version.

Bug solution:
    1 - I passed the version_id from smart button to the payslip directly to prevent unwanted behavior.

task - 6014170

## Steps to reproduce:

- Configure event registration with only free-text fields (no selection field).
- Open the POS, add an event ticket product, and fill in the registration form.
- Click Payment and validate the order.

## Issue:

- Registration answers were only sent to the backend when at least one selection-type question was filled.
- When no selection field was present, free-text answers were not synced at all.

## Reason:

- The `registration_answer_ids` and `registration_answer_choice_ids` One2many fields on EventRegistration both point to the same `registration_id` Many2one field on EventRegistrationAnswer.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/event/models/event_registration.py#L83-L85

- This caused data loss during the POS model synchronization, as entries were overwritten in the `inverseMap`.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/point_of_sale/static/src/app/models/related_models/model_defs.js#L59-L75

## Fix:

- Send all registration answers (free-text and selection-based) exclusively via `registration_answer_choice_ids`.


task-5438565

Forward-Port-Of: odoo/odoo#252932
Forward-Port-Of: odoo/odoo#242465

Currently, an error occurs when a user tries to generate lots while providing a lot number.

**Steps to replicate:**
- Install purchase (without demo).
- Create a product `test`.
- Install stock and turn on `Lots and Serial Numbers`
- Open the product `test` and turn on `Track Inventory` `by Lots`.
- Open Receipts > add the product `test`> give demand as 3 > and go to its form view using view button.
- Click `Generate Lots` > type `lot1` in `First lot Number` > Generate > Error-1
- Click `Generate Lots` > type 0 in Quantity received > Generate > Error-2.

**Error-1:**
```
  File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1026, in action_generate_lot_line_vals
    if (first_lot and first_lot == product.lot_sequence_id.get_next_char(first_number)):
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 237, in get_next_char
    interpolated_prefix, interpolated_suffix = self._get_prefix_suffix()
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 227, in _get_prefix_suffix
    self.ensure_one()
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5640, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: ir.sequence()
```

**Error-2:**
```
  File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1025, in action_generate_lot_line_vals
    first_number = product.lot_sequence_id.number_next_actual - product.lot_sequence_id.number_increment
                   ^^^^^^^
UnboundLocalError: cannot access local variable 'product' where it is not associated with a value
```
---
**Cause:**
- Both errors originated through a recent [PR].

**Error-1 (Expected singleton: ir.sequence()):**
- As the product was already created before Inventory was installed, the `lot_sequence_id` was empty. (Note:`lot_sequence_id` field has a default value , but default value
       assignment triggers only during the record creation,  any records created
       before stock is installed will not be assigned any value for
      `lot_sequence_id`.)

- As no `lot_sequence_id` is assigned to `test` product the line [1] calls `get_next_char()` on an empty recordset which further calls `_get_prefix_suffix()` [2] and raises singletonerror from [here].

**Error-2 (UnboundLocalError: cannot access local variable 'product'):**
- As the `Received Quantity` was given 0, the `count` argument is received as 0 and as a result the `lot_qties` [3] and `lot_names` [4] are received as empty lists.
- This causes their [zip] to be empty list too and the loop never runs, so assignment to [product] variable never happens and causes the error to occur from here [5].
---
**Solution:**

**Error-1:**
- Now we perform write on `product.lot_sequence_id` only if it exists, otherwise we skip it.

**Error-2:**
- Moved the static assignment of variable `product` and `location_dest_id` outside the loop, this will also prevent the browse being called multiple times for browsing the same record.

[PR]: https://github.com/odoo/odoo/pull/240368

[1]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1026

[2]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L237

[here]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L227

[3]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L989

[4]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L994

[zip]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1000

[product]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1004

[5]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1025

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

Forward-Port-Of: odoo/odoo#248846

**Issue**:
The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled.

**Steps to reproduce**:
- Create a rental product tracked in stock with a quantity of 5
- Enable "continue selling" and "show available quantity below 10"
- Go to the ecommerce page of this product
- Rent 3 units for a given period, confirm and pay
- Return to the ecommerce product page
-> Whatever the selected renting period, the displayed quantity is always 2

**Cause**:
The website displays `free_qty`:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15

`free_qty` is computed in:
https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36

which leads to:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10

and ultimately relies on:
https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213

This computation does not take the selected renting period into account.

There is a period-aware computation here:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1

but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled).

opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#105159
Forward-Port-Of: odoo/enterprise#103333

## Description

The `Tracking` interaction's `setup()` method reads order tracking info from the HTML `data-order-tracking-info` attribute and passes it directly to `_trackGa()` → `gtag()`. Since the DOM `dataset` API always returns strings, `gtag()` receives a JSON string instead of an object, causing GA4 to silently drop all purchase event parameters (`transaction_id`, `value`, `items`, etc.).

Compare with `onAddToCart()` in the same file, which receives its data via `CustomEvent.detail` (already a JS object) and works correctly.

**Impacted versions:**

- 19.0

**Steps to reproduce:**

1. Configure a Google Analytics key in Website > Settings
2. Add a product to cart and complete checkout
3. On `/shop/confirmation`, inspect the dataLayer or GA4 debug view

**Current behavior:**

- `add_to_cart` event fires with correct ecommerce parameters (object)
- `purchase` event fires with a JSON **string** instead of an object — GA4 silently drops the parameters

**Expected behavior:**

- `purchase` event fires with a parsed object containing `transaction_id`, `value`, `currency`, `tax`, `items`

**Fix:**

Add `JSON.parse()` to convert the data attribute string back to an object before passing it to `gtag()`.

---

I hereby confirm I have signed the Odoo CLA (included in this PR as `doc/cla/corporate/comma.md`).

Forward-Port-Of: odoo/odoo#253074

__

## Short functional explanation of the error
When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month.
In the wizard, we set the timesheet period from the first to the last day of last month.
Then, we set the `Invoicing Switch Threshold` to the day of last month. We record another hour for the timesheet, for this product, for today. When we select last month as timesheet period when creating a new invoice, the 2 hours that have already been invoiced are reinvoiced. Moreover, once we confirm this second invoice, it is possible to create again and again invoices for these already invoiced timesheets, without changing the Invoicing Switch Threshold parameter.

## Reproduction Steps
1. Create a quotation. Add as a line a timesheet product. Set the quantity to 2. Validate and click on the smart button Recorded.
2. Record 2 hours with a random date for last month.
3. Create an invoice. In the wizard, set the timesheet period to the first -> the last day of last month. Confirm, and on the invoice form,
 set the invoice date to last month  (after the day on which you
 recorded the timesheet hours) and confirm.
4. Click on configuration > settings. Search for Invoicing Switch Threshold, and set the date to the last day of last month.
5. Go back to the invoice you created. It should have the ribbon `Ìnvoicing App Legacy`.
6. Go back to the sales order. Click on the smart button Recorded and add one more hour to the timesheets, but this time in February.
7. Create an invoice. On the wizard, set the timesheet period to the first -> last day of last month. Click confirm.

### Expected behavior
The system shouldn't let us create an invoice, as we have nothing to invoice, as all the timesheets have already been invoiced.

### Unexpected behavior
An invoice is created with 2 hours. It doesn't take into account the hours added in February (normal) but reinvoices the timesheets that have already been invoiced (not normal).

## Origin of the issue
When retrieving the quantities to invoice for the timesheets, we don't take into account the quantities already invoiced for the same timesheet.

__
opw-5426434

Forward-Port-Of: odoo/odoo#250946

This commit continues to review the new Field Service to make sure the
features migrated from the old Field Service are still available and
also improve a bit the flow to facilate the day to day of planning users
using Field Service feature.

In detail, this commit will:
- fix traceback and access rights on creation of worksheet
- use generated timesheets of the intervention for the report. To do
  that a new one2many field called `intervention_timesheet_ids` is added
  in `planning.slot` model. And so instead of relying on 'timesheet_ids'
  of the slot, which are not necessarily linked to the intervention,
  we compute the effective hours based on the timesheets generated by the
  intervention, and use that field in the report and stat button.
- change color of trash button in form view in gantt
- make sure no planned shifts are not displayed
- simplify kanban card when shift is not planned
- some relabeling and change worksheet visibility condition in the report
- hide resource_ids in calendar popover when empty
- hide Field Service report if no customer report
- compute is_absent field if shift is not completed
- raises a user error when the user tries to reset the state
  of an intervention in draft if the state was in progress or completed
- hides `Hide price on customer report` in settings of planning app if
  `Customer Report` feature is disabled
- add space between worksheet and photos in the portal view and in
  Field Service report
- compute quotations_count field in planning.slot only if the user has
  sales access
- makes sure the context is reset before taking the display name of the
  customer set to set it to display name of the shift. Because before
  this commit, when the user creates a new shift and set a customer
  to the intervention, the display_name of the shift will contain the
  customer name but also his address which is not really expected.
- reorder worksheets data/demo to have the one created in demo data
  first once the demo data are loaded
- relabel email template in field service
- order the tracking in planning.slot
- reset SO when customer changes
- show field service stat button in SO when SO is generated/linked to an
  intervention.
- text white for conflicts tag in kanban otherwise the text is not
  correctly lisible in light mode.
- fix worksheet visibility in portal/report
- fix action_complete() and sale_line_id computation when no SO
- review card_top of kanban card of planning slot
- hide effective_hours and related fields from views/reports
- remove group to prevent access errors in SO
- hide partner_phone if no partner set on the shift
- add photos in field service report
- don't allow to add material on draft or published, we should only be
  able to add material when the intervention is in progress or
  completed

task-5994280