odoo/odoo#155588 was a workaround to the lack of location permissions in the iOS app, skipping geolocation entirely for check in/out. Since odoo/mobile#118 added support for them, we can now revert that fix so iOS users get prompted for their location again. task-6279460 Forward-Port-Of: odoo/odoo#278685 Forward-Port-Of: odoo/odoo#276934

odoo/odoo#155588 was a workaround to the lack of location permissions in the iOS app, skipping geolocation entirely for check in/out. Since odoo/mobile#118 added support for them, we can now revert that fix so iOS users get prompted for their location again.

task-6279460

Forward-Port-Of: odoo/odoo#278685
Forward-Port-Of: odoo/odoo#276934

When displaying lots or serial numbers on invoices, the quantity and UoM were rendered without any separator in the SN/LN table, e.g. `1.00Units`. - Add a non-breaking space between the quantity and UoM so the table renders as `1.00 Units`. - Also align the SN/LN value cell consistently with its right-aligned column header. - Update the `sale_stock` and `sale_mrp` report tests to expect whitespace between the quantity and UoM in the rendered invoice output. Task [link](https://www.odoo.

When displaying lots or serial numbers on invoices, the quantity and UoM were rendered without any separator in the SN/LN table, e.g. `1.00Units`.

- Add a non-breaking space between the quantity and UoM so the table renders as `1.00 Units`. 
- Also align the SN/LN value cell consistently with its right-aligned column header.
- Update the `sale_stock` and `sale_mrp` report tests to expect whitespace between the quantity and UoM in the rendered invoice output.

Task [link](https://www.odoo.com/odoo/project/967/tasks/6365178)
task-6365178

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

Forward-Port-Of: odoo/odoo#279214
Forward-Port-Of: odoo/odoo#274660

No description available.

Reading the `display_name` of a working schedule line of a 2 weeks calendar crashes: the compute reads `record.weektype` while the field is named `week_type`. ### Steps to reproduce - Switch a working schedule to a 2 weeks calendar. - Open one of its lines in a form view, e.g. with the `View Button` optional column in developer mode. opw-6427314

Reading the `display_name` of a working schedule line of a 2 weeks calendar crashes: the compute reads `record.weektype` while the field is named `week_type`.

### Steps to reproduce

- Switch a working schedule to a 2 weeks calendar.
- Open one of its lines in a form view, e.g. with the `View Button` optional column in developer mode.

opw-6427314

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7914fd5173 [REL] 19.2.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/71271b3bf4 [FIX] ui_sheet: `getCellWidth` getter for non-active sheet [Task: 6409426](https://www.odoo.com/odoo/2328/tasks/6409426) https://github.com/odoo/o-spreadsheet/commit/4db1721557 [FIX] pivot: prevent drag & drop in pivot side panel [Task: 6268403](https://www.odoo.com/odoo/2328/tasks/6268

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/7914fd5173 [REL] 19.2.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/71271b3bf4 [FIX] ui_sheet: `getCellWidth` getter for non-active sheet [Task: 6409426](https://www.odoo.com/odoo/2328/tasks/6409426)
https://github.com/odoo/o-spreadsheet/commit/4db1721557 [FIX] pivot: prevent drag & drop in pivot side panel [Task: 6268403](https://www.odoo.com/odoo/2328/tasks/6268403)
https://github.com/odoo/o-spreadsheet/commit/8ec91c94d4 [FIX] dashboard: clickable cell is not triggered by a right click [Task: 6365823](https://www.odoo.com/odoo/2328/tasks/6365823)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Current behavior before PR ----- The "unit cost" footer line was showing up on each page of the bom overview, overlapping with other lines. Desired behavior after PR is merged ----- The "unit cost" footer line should only appear at the bottom of the overview.

Current behavior before PR
-----
The "unit cost" footer line was showing up on each page of the bom overview, overlapping with other lines.


Desired behavior after PR is merged
-----
The "unit cost" footer line should only appear at the bottom of the overview.

**Steps to reproduce:** * Install the **Accounting** module. * Open a **Bank Journal** and go to the **Inbound Payment Methods** tab. * Add the **Manual** payment method multiple times and give each payment method line a different name. * Go to **Customers → Payments** and create a payment using any of these payment method lines. * Print the **Payment Receipt** from the gear menu. **Observed behavior:** * The receipt always displays the **Manual** payment method name. * The custom name

**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Bank Journal** and go to the **Inbound Payment Methods** tab.
* Add the **Manual** payment method multiple times and give each payment method line a different name.
* Go to **Customers → Payments** and create a payment using any of these payment method lines.
* Print the **Payment Receipt** from the gear menu.

**Observed behavior:**
* The receipt always displays the **Manual** payment method name.
* The custom name configured on the selected payment method line is ignored.

**Cause:**
* The report retrieves the payment method name from `account.payment.method`.
* However, the displayed name is configured on `account.payment.method.line`, so the report always shows the generic payment method name.

**Fix:**
* Read the payment method name from the selected `account.payment.method.line`.
* The payment receipt now displays the configured payment method line name.

opw-6395829

Forward-Port-Of: odoo/odoo#277104

odoo/odoo#155588 was a workaround to the lack of location permissions in the iOS app, skipping geolocation entirely for check in/out. Since odoo/mobile#118 added support for them, we can now revert that fix so iOS users get prompted for their location again. task-6279460 Forward-Port-Of: odoo/odoo#278685 Forward-Port-Of: odoo/odoo#276934

odoo/odoo#155588 was a workaround to the lack of location permissions in the iOS app, skipping geolocation entirely for check in/out. Since odoo/mobile#118 added support for them, we can now revert that fix so iOS users get prompted for their location again.

task-6279460

Forward-Port-Of: odoo/odoo#278685
Forward-Port-Of: odoo/odoo#276934

Follow-up to #247929, which limited `forever` recurrences to a 15-year horizon (`calendar.max_recurrence_years`) for *yearly* and *monthly* frequencies but left *weekly* and *daily* on the hard cap `MAX_RECURRENT_EVENT` (720), ignoring the parameter. A weekly `forever` event therefore always materializes 720 occurrences (~14 years) regardless of `calendar.max_recurrence_years`, and a daily one ignores the parameter too. This applies the year limit to weekly and daily as well, accounting for th

Follow-up to #247929, which limited `forever` recurrences to a 15-year
horizon (`calendar.max_recurrence_years`) for *yearly* and *monthly*
frequencies but left *weekly* and *daily* on the hard cap
`MAX_RECURRENT_EVENT` (720), ignoring the parameter.

A weekly `forever` event therefore always materializes 720 occurrences
(~14 years) regardless of `calendar.max_recurrence_years`, and a daily one
ignores the parameter too.

This applies the year limit to weekly and daily as well, accounting for the
number of selected weekdays and the interval, while still capping at
`MAX_RECURRENT_EVENT`.

Steps to reproduce:
1. Set `calendar.max_recurrence_years` to e.g. 2.
2. Create a weekly event repeating "forever".
3. Before: 720 occurrences (~14 years). After: ~106 (2 years).

task / context: extends #247929.

Forward-Port-Of: odoo/odoo#272615
Forward-Port-Of: odoo/odoo#270348

The discuss action's breadcrumb name is set asynchronously: a useEffect on the current thread's displayName calls setDisplayName after the OWL render. The tour clicked "Starred messages" then immediately clicked "View or join channels" (a sidebar category action that is always present, so there was no implicit wait). Under runbot load the starred render and its effect lagged, so the action was restored with the stale "Inbox" breadcrumb name and the ".breadcrumb-item:contains('Starred messages')"

The discuss action's breadcrumb name is set asynchronously: a useEffect on the current thread's displayName calls setDisplayName after the OWL render. The tour clicked "Starred messages" then immediately clicked "View or join channels" (a sidebar category action that is always present, so there was no implicit wait). Under runbot load the starred render and its effect lagged, so the action was restored with the stale "Inbox" breadcrumb name and the ".breadcrumb-item:contains('Starred messages')" step timed out.

This is a test-timing artifact: a real user always sees the starred view render before navigating away, so the breadcrumb is correct for them.

Wait for the starred thread to be displayed before opening the channels list, and assert the channels view opened via its "Public Channels" breadcrumb. Also use :text instead of :contains for the text selectors.

https://runbot.odoo.com/odoo/error/242893

Forward-Port-Of: odoo/odoo#278909

**Steps to reproduce:** 1. Enable debug mode and add a snippet. 2. Add a YouTube video with options like autoplay enabled. 3. Double click the video or use "Replace Media". 4. A traceback occurs while reopening the video options. **Root Cause:** When the media dialog is reopened on an existing video, `syncOptionsWithUrl()` derives each switch option's value from the URL: `value = this.state.urlInput.includes(urlParameter)`, which stores Boolean `true` when e.g. autoplay is enabled.

**Steps to reproduce:**

1. Enable debug mode and add a snippet.
2. Add a YouTube video with options like autoplay enabled.
3. Double click the video or use "Replace Media".
4. A traceback occurs while reopening the video options.

**Root Cause:**
When the media dialog is reopened on an existing video,
`syncOptionsWithUrl()` derives each switch option's value from the URL:
`value = this.state.urlInput.includes(urlParameter)`, which stores
Boolean `true` when e.g. autoplay is enabled. Similarly, toggling an
enabled option off stores Boolean `false`

The `value` prop was already `Boolean` but after commit https://github.com/odoo/odoo/commit/ae894892e048b
 we declared the prop as `value: { type: String, optional: true }` on
`VideoOption`. In debug mode, OWL validates props and throws
"Invalid props for component 'VideoOption': 'value' is not a string"
when it receives those booleans. The declaration does not match the
values the component actually receives.

**Fix:**
Normalizing the state to strings at the source would require rewriting
the option-state logic for no behavioral gain. Since booleans are
produced deliberately by two code paths, the honest prop type for value
is `[String, Boolean]`.

task-6233423

Forward-Port-Of: odoo/odoo#266304