Currently, an error occurs when user tries to undo a calendar event.

Steps to replicate:
- Install `appointment` with demo data.
- Navigate to `Appointments > Schedule > Resource Booking`.
- Drag to create a calendar event.
- Reschedule the event to a later time (drag and drop forward).
- Click Undo on the notification that appears.

Error:
`ValueError: Invalid field 'originId' in 'calendar.event'`
`KeyError: 'originId'`

Cause:
- The key `originId` was patched in the `getschedule()` [1] and later when user tried to undo the calendar event, the [fallbackschedule] included the key `originId` and made an [orm] call with it.
- The [line] tries to write the data into the database where `originId` field doesnt exist and causes the error to occur.

Solution:
- Remove the `originId` key from `fallbackdata` before the orm call.

[1]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/appointment/static/src/views/gantt/gantt_renderer.js#L110-L116

[fallbackschedule]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1425

[orm]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1473-L1477

[line]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/models/models.py#L248

sentry-7020359653

Forward-Port-Of: odoo/enterprise#112766
Forward-Port-Of: odoo/enterprise#100570

The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the calculation using sql and reduce memory usage.

Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version. 

```
Traceback (most recent call last):
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 657, in mock_view_tree
    self.mock_web_search_read(model, view, [domain], fields_list)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 691, in mock_web_search_read
    data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5074, in search_read
    result = records.read(fields, **read_kwargs)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
    return self._read_format(fnames=fields, load=load)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
    vals[name] = convert(record[name], record, use_name_get)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in _compute_value_residual
    posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in <lambda>
    posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
    self._read(fnames)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3351, in _read
    self.env.cache.insert_missing(fetched, field, values)
  File "/home/odoo/src/odoo/16.0/odoo/api.py", line 1123, in insert_missing
    field_cache.setdefault(id_, val)
MemoryError
```

opw-5921410
upg-3891767

Forward-Port-Of: odoo/enterprise#109008

__

## Short functional explanation of the error
When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48.

## Reproduction Steps
1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang.
2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time.
3. Open Attendances.

### Expected behavior
When we hover the name of our employee, we can see in white on green background 0/40h.

### Unexpected behavior
Instead, we see 0/48h.

## Origin of the issue
This line:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419
is used to retrieve the correct date. We assume that `end_datetime`
will be set at midnight, so subtracting one second gives us the day
before, allowing us to ignore the date of `end_dt`, for which we don't
need to compute the intervals.
However, this doesn't take into account different time zones. Indeed,
we compute `end_datetime_adjusted` from `end_datetime`, which has
the user timezone, and not UTC, as defined here:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402
As a result, if we set the user timezone to Pyongyang, `end_datetime`
will be set at 8am, and `end_datetime_adjusted` will lead to the same
date, instead of a day before. Hence, we would compute an additional
interval for an additional day, which would in the end give us 48
hours expected instead of the 40 hours indicated in the contract.
Therefore, we have to take into account the time zones, hours, minutes
and seconds when checking the start and end dates.

__
opw-5937298

Forward-Port-Of: odoo/enterprise#110011

Scenario:

- add the dynamic Products snippet on top of page and save
- go to the website with browser address bar that change height when
  going when going down in the page (hide or change size of it that is
  changing the viewport size)
- scroll all the way up and down in the page

Result: there is some jump that happen when the browser interface change
size when scrolling down or up.

Cause:

When going down the page, the viewport size changes (because the address
bar gets bigger / smaller). This causes the dynamic snippet to be
re-rendered.

Since February 2026 commit 2e5bd409581ddaab28084c42ab51b50b494f4876 to
optimize performance, product blocks are only rendered when the are in
the viewport (may depends on browser) with "content-visibility: auto".

The combination of those two things, causes that if you scroll down, the
widget is re-rendeded in owl, but it is only rendered in the page once
you scroll in the viewport so the scroll jump up or down with the
products snippet being rendered (going from 0 to eg. 300px when
scrolling into viewport) or not being rendered (going from eg 300px to
0 when scrolling and the widget not being in viewport).

Fix: remove the "content-visibility: auto" when we are in the dynamic
"Products" snippet, it was intended for the shop view and not for the
case where product block can be re-rendered outside of viewport.

opw-6005340

Note: this is mainly happening on mobile browser (eg. safari on iOS) because of the viewport resize when scrolling, but this can somehow be reproduced on chrome desktop:

- scroll below a "Products" snippet, change browser window size manually

=> the should be a jump of the content up

- scroll up to go back to the product snippet

=> the content of product snippet should appear all at once when the 0 pixel heigh get in the viewport

Forward-Port-Of: odoo/odoo#256815

Moving a section around in sale order lines when there is a line that can be abandoned throws an error

Steps to reproduce:
1. Install Sales app
2. Go to Sales and create a new quotation
3. Add any product, then add a section: enter any name for the section and then immediately press Enter (it should create an empty product line)
4. Without leaving edit mode, drag and drop the section at the top of the sale order lines (the empty product line should still be there)
5. An error is thrown

The same issue can be reproduced by moving a section down:
3b. Add any product, then add a section: move it to the top of the order lines then enter any name for the section and immediately press Enter (it should create an empty product line)
4b. Without leaving edit mode, drag and drop the section just between the product line and the empty product line

Issue:
`sortDrop` calls `leaveEditMode` at
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/views/list/list_renderer.js#L2242 which removes order lines that can be abandoned
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/model/relational_model/static_list.js#L379-L381 This can remove records from the recordMap generated before calling `super.sortDrop` in
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L175-L182 so we end up calling `_handleQuantityAdjustment` with a recordMap that contains record ids that have been deleted, throwing an error when we try to access the deleted record

Solution:
Call `leaveEditMode` before computing recordMap in order to remove the records that can be abandoned. This prevents `this.props.list.records` from being different when we generate recordMap and when we call
`_handleQuantityAdjustment`.
We also need to set the record being moved as dirty. This prevents the record from being abandoned when `leaveEditMode` is called.

opw-6022538

Forward-Port-Of: odoo/odoo#256662

[FIX] web: fix dropdown closing logic when clicking outside active UI
    
    Before this commit, the dropdown were closed when clicking outside...
    but only if the element that was clicked belongs to the same "UI
    active element" as the one that was the current one when the dropdown
    was opened.
    
    That is not perfect:
    - Open some popover that becomes the "UI active element"
    - Open the user menu dropdown (which is thus outside the current "UI
      active element")
    - Click just below that user menu dropdown
    => It does not close.
    
    It will only close when clicking in the registered "UI active element",
    which is not logical.
    
    This commit improves the logic: the close also occurs if the click
    occurs in *an ancestor* of the old registered "UI active element". That
    still keep the idea of checking "UI active elements" at all, for example
    in the case "dropdown -> dialog -> dropdown -> click outside", which
    should not close the first dropdown, as in that case it is the opposite
    situation: the click occurs  in a *child* "UI active element" of the old
    registered one.
    
    This fix is needed to fix a VoIP issue, where the "popover" mentioned
    in the example above is the VoIP softphone. See enterprise counter-part
    for more precisions.

[FIX] web: fix dropdown closing logic after closing active UI elements
    
    The parent commit fixes the dropdown closing logic when clicking outside
    "UI active elements". But it was not enough:
    - Open some popover that becomes the "UI active element"
    - Open the user menu dropdown (which is thus outside the current "UI
      active element")
    - Close the popover with some keyboard shortcut
    - Click just below that user menu dropdown
    => It still does not close, although we are in a situation without any
       "UI active element".
    
    This commit improves the logic again: the close also occurs if the click
    occurs while the old registered "UI active element" is gone.
    
    This fix is needed to fix a VoIP issue, where the "popover" mentioned
    in the example above is the VoIP softphone. See enterprise counter-part
    for more precisions.
    
task-6055692

Currently, an error occurs when a user pays for their order through the website.

**Steps to Reproduce:**

 - Install the `website_sale` and `pos_loyalty` modules.
 - Create a `product`.
 - Go to `Gift Cards & eWallets` and create a program with the type set to `Gift Card`.
 - Generate at least `one gift card`.
 - In `Gift Card Products`, add the recently created `product`.
 - Ensure that the SMTP server is configured and the `Demo` payment provider is `enabled`.
 - Make sure that in the `Gift Card: Gift Card Information` email template, the `Send From` field is set.
 - Now, go to the `shop`, add the product to the cart, and proceed to `Checkout` > `Pay`.
 -  And the error appears in the `logs`.

**Error:**

`odoo.exceptions.MissingError: Record does not exist or has been deleted.`
`(Record: mail.mail(5,), User: 1)`

After this [recent commit], when user pays for their order, the Payment: Post-process transactions 
step confirms the order and attempts to send reward coupon email [1] if any coupon is applied to 
the product. 
The system sends the email with force_send=True [2] and retrieves the sent mail_ids [3].  because 
force_send=True, the email is sent immediately [4] instead of being queued.
Once the email is successfully sent [5], _postprocess_sent_message [6] is triggered. Since there
 is no failure in sending the email, the corresponding mail record is deleted [7], because the email 
template has auto_delete=True. 
Later, when the system tries to access the deleted mail.mail record using the previously returned 
mail_ids, it raises error [8].

This commit ensures that only existing mail records are used when processing mail_ids, preventing 
access to deleted records.

[recent commit]: https://github.com/odoo/odoo/commit/80d80a007131827ddd231bed320708068d0086b6

[1]: https://github.com/odoo/odoo/blob/0f395269e9815977263f27fa85855096166e15a2/addons/sale_loyalty/models/sale_order.py#L188

[2]- https://github.com/odoo/odoo/blob/0f395269e9815977263f27fa85855096166e15a2/addons/sale_loyalty/models/sale_order.py#L245

[3]: https://github.com/odoo/odoo/blob/0f395269e9815977263f27fa85855096166e15a2/addons/pos_loyalty/models/loyalty_card.py#L73

[4]- https://github.com/odoo/odoo/blob/0f395269e9815977263f27fa85855096166e15a2/addons/mail/models/mail_template.py#L815-L816

[5]: https://github.com/odoo/odoo/blob/0f395269e9815977263f27fa85855096166e15a2/addons/mail/models/mail_mail.py#L871-L872

[6]: https://github.com/odoo/odoo/blob/0f395269e9815977263f27fa85855096166e15a2/addons/mail/models/mail_mail.py#L919

[7]- https://github.com/odoo/odoo/blob/0f395269e9815977263f27fa85855096166e15a2/addons/mail/models/mail_mail.py#L288-L289

[8]: https://github.com/odoo/odoo/blob/0f395269e9815977263f27fa85855096166e15a2/addons/pos_loyalty/models/loyalty_card.py#L73-L76

sentry-7367887795

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

__

## Short functional explanation of the error
When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48.

## Reproduction Steps
1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang.
2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time.
3. Open Attendances.

### Expected behavior
When we hover the name of our employee, we can see in white on green background 0/40h.

### Unexpected behavior
Instead, we see 0/48h.

## Origin of the issue
This line:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419
is used to retrieve the correct date. We assume that `end_datetime`
will be set at midnight, so subtracting one second gives us the day
before, allowing us to ignore the date of `end_dt`, for which we don't
need to compute the intervals.
However, this doesn't take into account different time zones. Indeed,
we compute `end_datetime_adjusted` from `end_datetime`, which has
the user timezone, and not UTC, as defined here:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402
As a result, if we set the user timezone to Pyongyang, `end_datetime`
will be set at 8am, and `end_datetime_adjusted` will lead to the same
date, instead of a day before. Hence, we would compute an additional
interval for an additional day, which would in the end give us 48
hours expected instead of the 40 hours indicated in the contract.
Therefore, we have to take into account the time zones, hours, minutes
and seconds when checking the start and end dates.
__
opw-5937298

Forward-Port-Of: odoo/odoo#252847

Currently on creating a time off that falls under a past contract still generates timesheet hours based on the employee's current contract.

### **Steps to Reproduce:**
1) Install `project_timesheet_holidays` module with demo data. 
2) Create an employee with two contracts/versions:
-  Past contract: 1 Jan 2025 to 31 Dec 2025 with standard 40h/week (8h/day).
-  Current contract: 1 Jan 2026 to indefinite with standard 35h/week (7h/day). 
3) Create and validate Time off for this employee in the past (e.g, 29 Dec 2025) 
4) Navigate to `Timesheets>All Timesheets`, search for this employee and switch
   list view for clear view.

### **Observed Behavior:**
7:00 hours are displayed on the timesheet, pulling from the employee's current active contract calendar.

### **Expected Behavior:**
8:00 hours should be displayed, as the leave date falls under the 40h/week past contract.

### **Root Cause:**
In the `_generate_timesheets`, the caledar values is fetched using `employee_id.resource_calendar_id` see[1], which always points to the employee's currently active calendar. Furthermore, this calendar is not explicitly passed to `_list_work_time_per_day` see[1], causing the method to fall back on the current default.

[1]- https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/project_timesheet_holidays/models/hr_leave.py#L36-L55

### **Fix:**
Resolve the applicable contract version based on the leave period instead of relying on `employee.resource_calendar_id`, which always points to the current calendar after the `resource_calendar` [refactor](https://github.com/odoo/odoo/commit/47f20c293787710e9501b7fd378239813875864a).

This fix fetches the version overlapping the leave dates and use its `resource_calendar_id` to compute work hours. Pass this calendar explicitly to `_list_work_time_per_day` to avoid fallback to the current employee calendar.

This ensures that leaves created in past contract periods generate timesheets using the correct historical working schedule.

**opw-5922695**

Forward-Port-Of: odoo/odoo#254296
Forward-Port-Of: odoo/odoo#248207

Steps to reproduce:
1. Enable "Display Extra Hours" in Attendance settings.
2. Assign an overtime ruleset to an employee.
3. Ensure the employee does not have the "Officer: Manage attendances" group.
4. Create an attendance that generates extra hours for this employee.
5. Log in as the employee and open the Employees app to view Extra Hours.

Issue:
An Access Error is raised because `get_overtime_data_by_employee` in
`hr_holidays_attendance/models/hr_employee.py` performs a `_read_group`
on `hr.attendance.overtime.line`. In 19.0, the only ACL for this model
grants access to `group_hr_attendance_officer`:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/hr_attendance/security/ir.model.access.csv#L1-L11

Users with `group_hr_attendance_own_reader` (implied by `base.group_user`,
i.e. all internal users) have no read access to `hr.attendance.overtime.line`.

In later versions, this was already fixed by adding a read-only ACL for
`group_hr_attendance_own_reader` on this model:
https://github.com/odoo/odoo/blob/ad4a2ec11fea2058445e4003099af3a5caa1ef22/addons/hr_attendance/security/ir.model.access.csv#L13

This is why forward-ports are not needed.

Solution:
Add the missing `access_hr_attendance_overtime_line_own_reader` ACL to
grant read-only access to `group_hr_attendance_own_reader` on
`hr.attendance.overtime.line`, matching the approach used in later versions.
This is preferred over using `.sudo()` as it properly grants the intended
access right rather than bypassing security checks entirely.

opw-6055081

Forward-Port-Of: odoo/odoo#257301
Forward-Port-Of: odoo/odoo#255576

Currently, an error occurs when a user submits the Create a Task form.

**Steps to Reproduce:**

 - Install the `website_project` module.
 - Go to `website` > `Click on Edit` > `Drag and drop` form.
 - Click on the form and, set the action to `Create a Task`, then save.
 - Fill in the required data in the form.
 - In the `Email Address` field, enter an email that does not correspond to any 
   existing partner.
 - `Submit` the form, and the `error appears in the logs`.

`ValueError: Invalid field 'email_cc' in 'project.task'`

With this [recent commit], the email_cc field has been removed from project.task, along 
with the mail.thread.cc inheritance, because threads are now able to find CC recipients. 
so, when user submits the form with an email address that does not correspond to any 
existing partner, the system adds email_cc to the record [1], and when it attempts to 
create the record [2], it raises an error.

This commit ensures that email_cc is no longer added to the record.

[recent commit]: https://github.com/odoo/odoo/commit/3c26c0553754a75d9440097ad473be3cc8bcb320#diff-93ba226020add6481cfeab916e69980a59163e2925a5c2c9a3bc0aaceb484cdf

[1]- https://github.com/odoo/odoo/blob/21aa7e7eca0bf78978e0667cee43129985833166/addons/website_project/controllers/main.py#L61

[2]: https://github.com/odoo/odoo/blob/21aa7e7eca0bf78978e0667cee43129985833166/addons/project/models/project_task.py#L1167

sentry-7374084515

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

Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service.

<h2>Steps to produce:</h2>

* Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings.
* Create a pricelist with a price rule of type discount that applies 10 percent discount to every product.
* Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist.
* Go to Field Service > Create a Task, and set `Customer` to Acme Corporation.
* Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order

<h2>Observed behavior:</h2>

The discount is applied twice to the product on SO:

**Product**: Service on Timesheets
**Unit Price**: `$40` (excluding tax)

**First discount:**
The 10 percent discount on the unit price of the product.
Product unit price is set from  `$40 -> $36
`

**Second discount:**
The 10 percent discount on the SO line itself.
`$36 -> $32.4
`

The untaxed amount is: `$32.40` which should be `$36.00`

<h2>Root cause:</h2>
This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice.

<h2>Solution:</h2>

When creating the sales order:
* **Discount setting is on:** use list price so the discount is applied from the sales order.
* **Discount setting is off:** set the product unit price to the discounted price.

[1]-
https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 
[2]-
https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788

opw-5432088

Forward-Port-Of: odoo/enterprise#112761
Forward-Port-Of: odoo/enterprise#103950

Scenario:

- add the dynamic Products snippet on top of page and save
- go to the website with browser address bar that change height when
  going when going down in the page (hide or change size of it that is
  changing the viewport size)
- scroll all the way up and down in the page

Result: there is some jump that happen when the browser interface change
size when scrolling down or up.

Cause:

When going down the page, the viewport size changes (because the address
bar gets bigger / smaller). This causes the dynamic snippet to be
re-rendered.

Since February 2026 commit 2e5bd409581ddaab28084c42ab51b50b494f4876 to
optimize performance, product blocks are only rendered when the are in
the viewport (may depends on browser) with "content-visibility: auto".

The combination of those two things, causes that if you scroll down, the
widget is re-rendeded in owl, but it is only rendered in the page once
you scroll in the viewport so the scroll jump up or down with the
products snippet being rendered (going from 0 to eg. 300px when
scrolling into viewport) or not being rendered (going from eg 300px to
0 when scrolling and the widget not being in viewport).

Fix: remove the "content-visibility: auto" when we are in the dynamic
"Products" snippet, it was intended for the shop view and not for the
case where product block can be re-rendered outside of viewport.

opw-6005340

Note: this is mainly happening on mobile browser (eg. safari on iOS) because of the viewport resize when scrolling, but this can somehow be reproduced on chrome desktop:

- scroll below a "Products" snippet, change browser window size manually

=> the should be a jump of the content up

- scroll up to go back to the product snippet

=> the content of product snippet should appear all at once when the 0 pixel heigh get in the viewport

Forward-Port-Of: odoo/odoo#256815

Moving a section around in sale order lines when there is a line that can be abandoned throws an error

Steps to reproduce:
1. Install Sales app
2. Go to Sales and create a new quotation
3. Add any product, then add a section: enter any name for the section and then immediately press Enter (it should create an empty product line)
4. Without leaving edit mode, drag and drop the section at the top of the sale order lines (the empty product line should still be there)
5. An error is thrown

The same issue can be reproduced by moving a section down:
3b. Add any product, then add a section: move it to the top of the order lines then enter any name for the section and immediately press Enter (it should create an empty product line)
4b. Without leaving edit mode, drag and drop the section just between the product line and the empty product line

Issue:
`sortDrop` calls `leaveEditMode` at
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/views/list/list_renderer.js#L2242 which removes order lines that can be abandoned
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/model/relational_model/static_list.js#L379-L381 This can remove records from the recordMap generated before calling `super.sortDrop` in
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L175-L182 so we end up calling `_handleQuantityAdjustment` with a recordMap that contains record ids that have been deleted, throwing an error when we try to access the deleted record

Solution:
Call `leaveEditMode` before computing recordMap in order to remove the records that can be abandoned. This prevents `this.props.list.records` from being different when we generate recordMap and when we call
`_handleQuantityAdjustment`.
We also need to set the record being moved as dirty. This prevents the record from being abandoned when `leaveEditMode` is called.

opw-6022538

Forward-Port-Of: odoo/odoo#256662

Problem:
The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS.

Cause:
On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar relies on `keyup` for Arrow keys to re-enable `onSelectionChangeActive` and trigger the toolbar update, so it never opens.

See section ("Issue 3 - keyup event put on hold for other keys"): https://web.archive.org/web/20160304022453/http://bitspushedaround.com/on-a-few-things-you-may-not-know-about-the-hellish-command-key-and-javascript-events/

Solution:
Track when an Arrow key is pressed while Cmd is held (`pendingArrowKey`) and use a `selectionchange` listener as a fallback to re-enable the toolbar. The `selectionchange` event fires reliably on macOS even when `keyup` is suppressed. A `isMouseDown` guard ensures the listener does not interfere with the existing mousedown/mouseup flow.

Steps to reproduce:
1- Type some text
2- Use Cmd+Shift+Arrow (left or right) to select text 3- Observe the toolbar does not appear

task-6013408

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

Forward-Port-Of: odoo/odoo#257166
Forward-Port-Of: odoo/odoo#253293

**Steps to reproduce**
- Install `pos_hr` with demo data
- Open Settings > Manage Users
- Validation Error: A user cannot be linked to multiple employees in the same company

**Cause**
`employee_id` for the current user was computed as False here: https://github.com/odoo/odoo/blob/361aa8505506f9686b1cdb244ba1723ee3f06f7b/addons/pos_hr/models/pos_config.py#L27 Despite an employee already existing, which led to the error here: https://github.com/odoo/odoo/blob/361aa8505506f9686b1cdb244ba1723ee3f06f7b/addons/pos_hr/models/pos_config.py#L30

This exposes an issue with `_compute_company_employee`:
- the compute is called a first time on multiple users, including the current user, in a non-sudo environment
- the `employee_id` field for the current user is accessed in a sudo environment

The problem comes from the search in non-sudo, which uses an `ir.rule` that evaluates `user.employee_id` in sudo while we are computing `user.employee_id`.

**Fix**
We avoid the cache issue by always performing the search in sudo.

opw-6046297

Issue Before This Commit:
=======================
When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them as not sent even though they were already emailed and have to send them again using the `Send RFQ` button from the form view to mark rfq as sent, which is inconsistent with the form view behavior and confusing for users.

Steps to Reproduce:
=======================
- Install the `Purchase` app.
- Go to Purchase and select multiple RFQs in the list view.
- Click `Send by mail` from the actions menu.
- Select the RFQ email template and send the email.
- Observe that the RFQs remain in state RFQ instead of being set to RFQ Sent, unlike when using the `Send RFQ` button in the form view.

Cause of the issue:
=======================
The `Send by mail` action in the list view does not apply the same state update logic as the `Send RFQ` button from the form view, where the RFQ state is updated when the email is posted on the purchase order. As a result, when emails are sent from the list view (mass mailing flow), the RFQ state is not updated

After This Commit:
=======================
When emails are sent using Send by mail, purchase orders in state draft are updated to sent in `_message_mail_after_hook` after the email is sent. This keeps the list view flow consistent with the form view behavior and prevents users from having to resend RFQs just to update the state.

TaskID-5443248

Steps to reproduce:
-------------------
* Enable "Master Production Schedule" in Inventory settings
* Create tracked Product "Child" and set up a vendor
* Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days
* Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days
* Open MPS and add your three products:
  - Child, Parent: activate indirect demand
  - Parent: Safety Stock Target of 10
* Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second

Observation:
-------------
Usefull comment form the function :
https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447

When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars)
When calculating the production schedule. we wil we calculate each product for each date_range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509

When calculating the values for a product, we will set the indirect demand qty for it component

The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time):
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555

If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560

In our case this will create the issue, since it will try to compensate each time on the previous week.

opw-5413838

Forward-Port-Of: odoo/enterprise#112811
Forward-Port-Of: odoo/enterprise#107671

Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service.

<h2>Steps to produce:</h2>

* Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings.
* Create a pricelist with a price rule of type discount that applies 10 percent discount to every product.
* Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist.
* Go to Field Service > Create a Task, and set `Customer` to Acme Corporation.
* Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order

<h2>Observed behavior:</h2>

The discount is applied twice to the product on SO:

**Product**: Service on Timesheets
**Unit Price**: `$40` (excluding tax)

**First discount:**
The 10 percent discount on the unit price of the product.
Product unit price is set from  `$40 -> $36
`

**Second discount:**
The 10 percent discount on the SO line itself.
`$36 -> $32.4
`

The untaxed amount is: `$32.40` which should be `$36.00`

<h2>Root cause:</h2>
This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice.

<h2>Solution:</h2>

When creating the sales order:
* **Discount setting is on:** use list price so the discount is applied from the sales order.
* **Discount setting is off:** set the product unit price to the discounted price.

[1]-
https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 
[2]-
https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788

opw-5432088

Forward-Port-Of: odoo/enterprise#112761
Forward-Port-Of: odoo/enterprise#103950

Peppol offers a response system to the document received through it.
These are called Business Level Responses, and their documentation can be found here:
https://docs.peppol.eu/poacc/upgrade-3/profiles/63-invoiceresponse/#introduction-to-openpeppol-and-bis

The specific BLR implemented in this commit is targeted to invoices and credit notes.

3 types of responses are mandatory for a Peppol participant to correctly adhere to the BLR service: acknowledgement (different to the transport ack), confirmation and rejection. More response's types are available but were not implemented as they're not mandatory/needed (for now).
For rejection, a list of at least one reason must be given, and actions can be suggested to the sender of the document for the eventual next invoice shipment.

Same principle goes for Nemhandel, with some differences: only 2 responses, BusinessAccept and BusinessReject (no Acknowledgement, and no reasons are needed in case of rejection. Instead, the user can send a string message.

iap PR: https://github.com/odoo/iap-apps/pull/1364

task-5237698

Forward-Port-Of: odoo/odoo#243191

Before this commit:

- Product retrieval during import relied on exact name match and substring (ilike) search.
- Exact name search was case sensitive, so values like `Network Cable` would not match `Network cable`.
- Substring matching could return unrelated products (e.g. `Wireless bluetooth speaker` gets matched with
  `Wireless bluetooth speaker battery`), leading to unrelated matches.

After this commit:

- Exact name search is now case insensitive, allowing matches such as `Network Cable` and `network cable`.
- Substring based matching has been replaced with a similarity ratio (90%) to reduce false positives and improve matching reliability against customer database product names.

Technical:

- Replaced `=` with `=ilike` in the exact name search domain to make the lookup case insensitive.
- Similarity ratio is computed using Python's `difflib.SequenceMatcher` on product names, with a minimum threshold of 90% to qualify as a match.
- Added system parameter for configurable product name similarity threshold.

task-5951469

Forward-Port-Of: odoo/odoo#257175
Forward-Port-Of: odoo/odoo#252147

Steps to reproduce:
-------------------
* Enable "Master Production Schedule" in Inventory settings
* Create tracked Product "Child" and set up a vendor
* Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days
* Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days
* Open MPS and add your three products:
  - Child, Parent: activate indirect demand
  - Parent: Safety Stock Target of 10
* Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second

Observation:
-------------
Usefull comment form the function :
https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447

When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars)
When calculating the production schedule. we wil we calculate each product for each date_range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509

When calculating the values for a product, we will set the indirect demand qty for it component

The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time):
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555

If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560

In our case this will create the issue, since it will try to compensate each time on the previous week.

opw-5413838

Forward-Port-Of: odoo/enterprise#112393
Forward-Port-Of: odoo/enterprise#107671

**Steps to reproduce:**
* Install  `point_of_sale` module.
* Go to Settings:
     * Enable Lots & Serial Numbers.
     * Enable Variants.
     * Set Barcode Nomenclature to Default GS1 Nomenclature.
* Create a product:
     * Enable Track Inventory set to By Lots.
     * Under Attributes & Variants:
     * Add an attribute with two values and save.
* Generate product variants:
     * Open one variant and set barcode to 5123648695416.
* Update inventory:
     * Go to the main product (template).
     * Update On Hand Quantity:
             * Update On Hand Quantity with a lot/serial number:
               010512364869541610784512.
             * Select the variant with the defined barcode.
* Under Point of Sale tab:
    * Set a POS Category.
* Open a POS session and scan:
010512364869541610784512.

**Observed behavior:**
* Scanning the GS1 barcode in POS raises a traceback:
  *TypeError: Cannot read properties of undefined (reading
  'product_template_attribute_value_ids')*.

**Cause:**

[Scans GS1 barcode: 010512364869541610784512]
│
├─ ProductScreen._barcodeGS1Action(parsed_results)
│    • product = await _getProductByBarcode(productBarcode)  ✅ found
│    • calls `addLineToCurrentOrder(vals, { code: lotBarcode })`
│                                                              ⚠️ only `lotBarcode` passed, `productBarcode` discarded
│
├─ PosStore.addLineToCurrentOrder() → addLineToOrder()
│    • product has variants → isConfigurable() = true
│
├─ PosStore.handleConfigurableProduct()
│    • calls openConfigurator(productTemplate, { ...opts })
│      opts = { code: lotBarcode }
│
└─ PosStore.openConfigurator()
     • opts.code = lotBarcode  → truthy → enters if(opts.code) branch
     • getBy("barcode", opts.code.base_code)
     •  getBy("barcode", "784512")   ← "784512" is a LOT number, not a product barcode!
       → returns undefined ❌
     • product packaging lookup also fails → undefined ❌
     • product = undefined
     │
     └─ attributeLinesValues.map(values =>
            values.filter(value =>
                product.product_template_attribute_value_ids.includes(value)
                ^^^^^^^ undefined  → 💥 TypeError

**Fix:**
* Pass the product from `handleConfigurableProduct` to the configurator.
* If no product is found using `opts.code`, use the passed product
  instead.

---

opw-6031909

Forward-Port-Of: odoo/odoo#254572

**Problem:**
When creating a new stock.move.line in the moves view (accessed via smart button from a picking), the newly created line disappears after any refresh action (manual refresh or triggering "Put in Pack").

**Steps to reproduce:**
1. Open a receipt/picking operation
2. Click on the "Moves" smart button to open the detailed operations view
3. Create a new stock.move.line record
4. Click "Put in Pack" or manually refresh the page
5. Observe that the newly created line disappears

**Current behavior:**
The newly created stock.move.line disappears from the view after refresh, and only reappears if you navigate back to the picking and then return to the moves view.

**Expected behavior:**
The newly created stock.move.line should remain visible in the view after refresh or any action that triggers a view reload.

**Cause of the issue:**
  The action_detailed_operations method uses a static domain [('id', 'in', self.move_line_ids.ids)] that captures a snapshot of move line IDs at the moment the action is opened.
  https://github.com/odoo/odoo/blob/22ac818970f104a732cc7d24afc440cf0e6d74bd/addons/stock/models/stock_picking.py#L1204-L1212 When a new stock.move.line is created in this view, its ID is not included in the original static list. Any refresh (manual or triggered by operations like "Put in Pack") re-applies this static domain, filtering out the newly created lines because their IDs weren't captured in the initial list.

**Fix:**
Using a dynamic domain based on picking_id ensures all move lines belonging to the picking are always visible, regardless of when they were created. This aligns with the expected behavior of showing "all move lines for this picking" rather than "only the move lines that existed when the view was opened". The relational lookup [('picking_id', '=', self.id)] is re-evaluated on each refresh, automatically including any newly created lines that have the correct picking_id set.

opw-5398620

Forward-Port-Of: odoo/odoo#247170

Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service.

<h2>Steps to produce:</h2>

* Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings.
* Create a pricelist with a price rule of type discount that applies 10 percent discount to every product.
* Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist.
* Go to Field Service > Create a Task, and set `Customer` to Acme Corporation.
* Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order

<h2>Observed behavior:</h2>

The discount is applied twice to the product on SO:

**Product**: Service on Timesheets
**Unit Price**: `$40` (excluding tax)

**First discount:**
The 10 percent discount on the unit price of the product.
Product unit price is set from  `$40 -> $36
`

**Second discount:**
The 10 percent discount on the SO line itself.
`$36 -> $32.4
`

The untaxed amount is: `$32.40` which should be `$36.00`

<h2>Root cause:</h2>
This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice.

<h2>Solution:</h2>

When creating the sales order:
* **Discount setting is on:** use list price so the discount is applied from the sales order.
* **Discount setting is off:** set the product unit price to the discounted price.

[1]-
https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 
[2]-
https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788

opw-5432088

Forward-Port-Of: odoo/enterprise#112761
Forward-Port-Of: odoo/enterprise#103950

Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service.

<h2>Steps to produce:</h2>

* Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings.
* Create a pricelist with a price rule of type discount that applies 10 percent discount to every product.
* Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist.
* Go to Field Service > Create a Task, and set `Customer` to Acme Corporation.
* Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order

<h2>Observed behavior:</h2>

The discount is applied twice to the product on SO:

**Product**: Service on Timesheets
**Unit Price**: `$40` (excluding tax)

**First discount:**
The 10 percent discount on the unit price of the product.
Product unit price is set from  `$40 -> $36
`

**Second discount:**
The 10 percent discount on the SO line itself.
`$36 -> $32.4
`

The untaxed amount is: `$32.40` which should be `$36.00`

<h2>Root cause:</h2>
This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice.

<h2>Solution:</h2>

When creating the sales order:
* **Discount setting is on:** use list price so the discount is applied from the sales order.
* **Discount setting is off:** set the product unit price to the discounted price.

[1]-
https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 
[2]-
https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788

opw-5432088

Forward-Port-Of: odoo/enterprise#103950

*: stock_barcode_mrp, stock_barcode_picking_batch

## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.

## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
     - Delivery Orders.
     - Manufacturing Orders
     - Batch Pickings
     - Inventory Count
- From any of these open a record
  (e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.

## Cause of the Issue:
- When switching views inside the Barcode client action,
  the FormController calls `setDisplayName(this.displayName())`.
  In some cases, this returns an empty string, overwriting the
  previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
  preventing the controller from retrieving a proper name.

## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.

TaskID: 4978997

Currently, an error occurs on clicking on the graph or the pivot cell if the data is grouped by Employee/Manager/Department.

### **Steps to reproduce**
1) Install helpdesk_timesheet with demo data
2) Go to Timesheet > Reporting > Ticket Analysis
3) Set group by to Employee
4) Click on any graph bar or pivot cell

### **Error:**
`ValueError: Invalid field helpdesk.ticket.employee_id in condition ('employee_id', '=', 1)`

Root Cause:
The `helpdesk.ticket.report.analysis` model includes specific fields such as `employee_id`, `department_id`, and `employee_parent_id` (see [1]) that are defined for reporting purposes but do not exist on the `helpdesk.ticket` model. When a user clicks a data point to view related tickets, the reporting view passes the current domain directly to the ticket list view. Because `helpdesk.ticket` lacks these fields, the ORM fails to validate the domain, resulting in a server error.

[1]- https://github.com/odoo/enterprise/blob/8d16b647431985dd7c216ae39eea6ca050e04b46/helpdesk_timesheet/report/helpdesk_ticket_report_analysis.py#L15-L17

### **Fix:**
This commit introduces a mixin to intercept the openView call. The mixin maps reporting-specific fields to valid relational paths on the ticket model `(for example, employee_id is transformed into user_id.employee_id)`. This ensures that the domain generated from the report model is compatible with the target ticket model.

**opw-5931273**

*: crm_enterprise, planning_field_service, project_enterprise, sale_enterprise, stock_fleet_enterprise, web_studio

First commit enhances the visual hierarchy and clarity of the "unlocated records" toggler in the map view pin list.

Key design changes include:
* Adding a compass icon to the left of the text for better visual context.
* Upgrading the text to an `h5` element to increase its size and prominence.
* Moving the collapse/expand caret to the far right of the container for a cleaner alignment.

Second commit enhances the map view by replacing the basic routing toggle with a selection, offering three distinct routing modes:

* **Disabled:** No routing is calculated nor displayed.
* **Optimized:** Computes the route for minimal travel time between records (the current default behavior).
* **Ordered:** Routes strictly follow the default order set on the view (restoring the previous default behavior).

Additionally, to prevent configuration confusion in Studio, the "default order" option is now dynamically hidden unless the routing mode is set to "Ordered".

task-6044531

This pull request introduces an automated process to periodically update the DGI (Dirección General Impositiva) state for Uruguayan electronic stock pickings, along with improvements to error handling and logging when a picking is rejected. The main changes are the addition of a scheduled cron job, enhanced logging, and user notifications for rejected pickings.

**Automated DGI State Updates:**

* Added a new scheduled cron job (`ir_cron_update_dgi_state_pickings`) that runs every 10 minutes to update the DGI state of stock pickings with electronic documents in the "received" state. (`l10n_uy_edi_stock/data/ir_cron.xml`, `l10n_uy_edi_stock/__manifest__.py`) [[1]](diffhunk://#diff-36f19bab7c2edeb0f43a1db1639b72e8508deed19652e0b1142ebfce688b9d3eR1-R11) [[2]](diffhunk://#diff-370a6cfd5890d6504958deb4a225d69ec84e84fa59deeeb52c96a849f3fdfc22R14)
* Implemented the `_l10n_uy_edi_stock_cron_update_dgi_state` method in `stock_picking.py` to process batches of pickings and trigger itself again if more records remain. (`l10n_uy_edi_stock/models/stock_picking.py`)

**Error Handling and Notifications:**

* Enhanced the `l10n_uy_edi_action_update_dgi_state` method to log rejected pickings and post a message in the chatter to notify users when a picking has been rejected by DGI, prompting manual review and correction. (`l10n_uy_edi_stock/models/stock_picking.py`)
* Introduced logging setup for the module to support the new logging functionality. (`l10n_uy_edi_stock/models/stock_picking.py`) [[1]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R2) [[2]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R14)

Forward-Port-Of: odoo/enterprise#109518

Currently, the BOE export for `Mod 347` uses incorrect indicators for 
`Substitutive` and `Complementary declarations`.

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`
- Navigate to Accounting > Reporting > Tax Report
- From the smart button, select `Report: Tax Report (Mod 347) (ES)`
- Download the BOE file using the dropdown.
- In the wizard:
  - Enable `Substitutive Declaration` or `Complementary Declaration`
  - Set `Previous Report Number` (e.g., 123456789)
  - Click `Generate BOE`
- Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required)

**Observation:**
AEAT does not recognize 'X' as a valid indicator for substitutive or 
complementary declarations and interprets the file as a standard return.

**Root Cause:**
At [1], the BOE Mod 347 generation writes 'X' for both substitute 
and complementary declarations.

**Fix:**
This commit ensures the file contains correct indicators:
- 'C' for `complementary declarations`
- 'S' for `substitute declarations` 

This aligns Modelo 347 with AEAT specifications and ensures 
consistency with the implementation of Modelo 349 at [2].

Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html

[1]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062

[2]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491

opw-6048711

Forward-Port-Of: odoo/enterprise#112860
Forward-Port-Of: odoo/enterprise#112566

Currently, an error occurs when user tries to undo a calendar event.

Steps to replicate:
- Install `appointment` with demo data.
- Navigate to `Appointments > Schedule > Resource Booking`.
- Drag to create a calendar event.
- Reschedule the event to a later time (drag and drop forward).
- Click Undo on the notification that appears.

Error:
`ValueError: Invalid field 'originId' in 'calendar.event'`
`KeyError: 'originId'`

Cause:
- The key `originId` was patched in the `getschedule()` [1] and later when user tried to undo the calendar event, the [fallbackschedule] included the key `originId` and made an [orm] call with it.
- The [line] tries to write the data into the database where `originId` field doesnt exist and causes the error to occur.

Solution:
- Remove the `originId` key from `fallbackdata` before the orm call.

[1]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/appointment/static/src/views/gantt/gantt_renderer.js#L110-L116

[fallbackschedule]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1425

[orm]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1473-L1477

[line]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/models/models.py#L248

sentry-7020359653

Forward-Port-Of: odoo/enterprise#112851
Forward-Port-Of: odoo/enterprise#100570

The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the calculation using sql and reduce memory usage.

Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version. 

```
Traceback (most recent call last):
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 657, in mock_view_tree
    self.mock_web_search_read(model, view, [domain], fields_list)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 691, in mock_web_search_read
    data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5074, in search_read
    result = records.read(fields, **read_kwargs)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
    return self._read_format(fnames=fields, load=load)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
    vals[name] = convert(record[name], record, use_name_get)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in _compute_value_residual
    posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in <lambda>
    posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
    self._read(fnames)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3351, in _read
    self.env.cache.insert_missing(fetched, field, values)
  File "/home/odoo/src/odoo/16.0/odoo/api.py", line 1123, in insert_missing
    field_cache.setdefault(id_, val)
MemoryError
```

opw-5921410
upg-3891767

Forward-Port-Of: odoo/enterprise#110407
Forward-Port-Of: odoo/enterprise#109008

A subscription product that has a price of zero on the product form and the price is set on the pricelist instead cannot be added to the cart when the `Prevent Sale of Zero Priced Product` setting is enabled

Steps to reproduce:
1. Install eCommerce and Subscriptions
2. Go to Settings and enable `Prevent Sale of Zero Priced Product`
3. Go to Subscriptions > Products and create a new product "subscription" with Sales Price $0.00 and publish it to the website
4. Go to Subscriptions > Pricelists and edit pricelist "Benelux"
5. In the Recurring Prices tab, create a new entry for product "subscription"  with a Fixed Price of $20.00 and a monthly Recurring Plan
6. Log in as portal user, go to the shop and look for "subscription" (pricelist "Benelux" should be selected)
7. Try to add it to the cart
8. Nothing happens and an error is displayed in the log

Issue:
When we check if a product can be added to the cart https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/controllers/cart.py#L116-L120 we do not use the plan_id specified in kwargs
We reach this code
https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/models/product_product.py#L146-L147 which will prevent the addition of a product in the cart if the option `prevent_zero_price_sale` is enabled and if `_get_contextual_price` returns zero
Calling `_get_contextual_price` tries to find a `product.pricelist.item` by building a domain in `_get_applicable_rules_domain` but calling this method without a plan_id eventually reaches
https://github.com/odoo/enterprise/blob/252c5ab78b51d0d2f06178cf92f0489b4a46958f/sale_subscription/models/product_pricelist.py#L69-L72 which restricts the domain to pricelists that are not subscription plans
Therefore, we cannot find any pricelist that applies to the product and we consider that the product cannot be added to the cart

Solution:
We need to use the plan_id selected by the customer in order to correctly check if a product can be added to the cart.

Use the plan_id in kwargs to update the request context so we can check if a product can be added to the cart according to the plan_id the user has selected. Use this plan_id in `_get_applicable_rules` in order to correctly select the applicable `product.pricelist.item`.

opw-5993614

Forward-Port-Of: odoo/enterprise#112699
Forward-Port-Of: odoo/enterprise#111624

Add three new configurable options to the DHL Express REST integration:

1. Request Pickup (new Boolean field, default True for backward compat): Controls the pickup.isRequested flag in shipment requests. When disabled, DHL will not schedule a pickup — useful when managing pickups externally or dropping off at a DHL location. Previously hardcoded to True.

2. Enhanced References (new Boolean field): When enabled, uses the Customer Reference from the SO (client_order_ref) as the shipment reference (customerReferences with typeCode CU) instead of the SO number. Useful when customers provide their own PO/reference numbers that should appear on the shipping label.

3. Upload Odoo Invoice (new Boolean field): When enabled and the shipment is an export (commercial invoice required), uploads the Odoo-generated invoice PDF inline in the shipment request as a DHL Paperless Trade document (documentImages with typeCode INV, base64 encoded). Requires a posted invoice on the SO before shipping. This ensures export documents match the actual accounting records.

All features are opt-in via carrier configuration fields in the Options section, preserving full backward compatibility.

In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost.

Steps to reproduce:
-------------------
* Enable intercompany transaction
* Enable variant grid entry
* Enable multistep routes
* Unarchive MTO
* Settings>Users & Companies>Companies
* Enable Generate Sales Orders in company A
* Create a product:
    -  Never variant with at least two values
    -  MTO and manufacture
* Create a bom,
    - Company : company B
    - Add a component with apply on variant: choose one of the variants
* Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B
* Confirm the sales order in company B
-> The manufacture order does not include the components that are applied on variant

Observation:
-------------
When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order.
That function will create the sale order from the data of the purchase order:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
When preparing the value for each order line, the attribute value for the never variant will not be retrieved:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO.

opw-5438723

When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to incorrect amounts being interpreted in reconciliation models.
  
Added a new function `split_amount_str`in utils which will give
integer and decimal part for different number formats.
    
This is a heuristic approach, meaning it aims to provide the best
possible result for valid inputs. Invalid or ambiguous formats are
not guaranteed to be parsed correctly and may result in ('0', '0').
    
For the two capturing groups case, the first group is treated as the
integer part and the second as the decimal part, allowing users to
Explicitly split amounts like 9065 into 90.65 by using two groups
in their regex.
    
Examples:
    
EU format: 1.334,15 → 1334.15
US format: 1,334.15 → 1334.15
Implicit decimals: uid 01870912 0000009065 → 90.65 (using two groups)
    
Additional tests were added to ensure amounts with thousand separators
are correctly parsed.

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

task-6026748

Steps to reproduce:
-------------------
* Enable "Master Production Schedule" in Inventory settings
* Create tracked Product "Child" and set up a vendor
* Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days
* Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days
* Open MPS and add your three products:
  - Child, Parent: activate indirect demand
  - Parent: Safety Stock Target of 10
* Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second

Observation:
-------------
Usefull comment form the function :
https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447

When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars)
When calculating the production schedule. we wil we calculate each product for each date_range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509

When calculating the values for a product, we will set the indirect demand qty for it component

The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time):
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555

If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560

In our case this will create the issue, since it will try to compensate each time on the previous week.

opw-5413838

Forward-Port-Of: odoo/enterprise#112811
Forward-Port-Of: odoo/enterprise#107671

Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service.

<h2>Steps to produce:</h2>

* Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings.
* Create a pricelist with a price rule of type discount that applies 10 percent discount to every product.
* Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist.
* Go to Field Service > Create a Task, and set `Customer` to Acme Corporation.
* Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order

<h2>Observed behavior:</h2>

The discount is applied twice to the product on SO:

**Product**: Service on Timesheets
**Unit Price**: `$40` (excluding tax)

**First discount:**
The 10 percent discount on the unit price of the product.
Product unit price is set from  `$40 -> $36
`

**Second discount:**
The 10 percent discount on the SO line itself.
`$36 -> $32.4
`

The untaxed amount is: `$32.40` which should be `$36.00`

<h2>Root cause:</h2>
This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice.

<h2>Solution:</h2>

When creating the sales order:
* **Discount setting is on:** use list price so the discount is applied from the sales order.
* **Discount setting is off:** set the product unit price to the discounted price.

[1]-
https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 
[2]-
https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788

opw-5432088

Forward-Port-Of: odoo/enterprise#112761
Forward-Port-Of: odoo/enterprise#103950

## Versions
18.0+

## Issue
When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been reverted to its previous state.

## Steps to reproduce
- Create a new SO for any customer:
  - Add a standard (non-combo/non-variant) product (e.g. "Apple Pie");
  - Save manually;
  - Change the product for a combo or variant one (e.g. "Customizable Desk");
  - With the opened dialog, change from browser tab then come back;
  - The SOL has been reset to the standard product ("Apple Pie") and confirming the dialog has no effect).

## Cause
The `beforeVisibilityChange` hook is triggered by the tab change and saves the form without updated values. This is because the hook checks for two conditions to be true: https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/web/static/src/views/form/form_controller.js#L479-L483 The tab change indeed changes the document's visibility to "hidden" but the controller has never been updated with the form's display in the dialog and, therefore, `this.formInDialog` is indeed equal to zero.

## Test
No test as we cannot simulate a browser tab change then come back to the first tab.


opw-5494089

**Steps to reproduce:**
- Set up an event, go put it's state to Annonced
- Set up any online payment method (Demo also triggers the bug)
- Go to a PoS that sells the event tickets
- Purchase one and pay with the online payment method
- Once on the ticket screen, the button to download the event tickets is not displayed

**Why the fix:**
The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration.

The problem is that with an online payment method, once we enter the **read_pos_data** method that sets
the values for the frontend, the order is still in draft, so we just return without doing anything.

We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment.
In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed.

A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed.

opw-5438432

This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a sligthly modified version) seemed adequate.

Summary:

When a QWeb template fails to render, the current logic logs the entire template source and raises a generic UserError. This leads to significant log bloat and makes it difficult for developers and support staff to identify the specific failing template or the root cause of the error.

This commit improves the error handling in `mail.render.mixin` and `mail.template` by:

- mail.render.mixin: Added logic to identify the failing template's name and ID if it belongs to a `mail.template` or `mail.compose.message` (mass mailing).
- Log Truncation: Implemented truncation for identified templates, showing only a snippet (first and last 500 chars) in logs and UserErrors to prevent log/UI bloat while keeping full source logging as a fallback for unidentified templates.

OPW-5980295


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

Forward-Port-Of: odoo/odoo#257104

[FIX] html_editor: undo link autoconvert before space insertion

When adding a space after an URL, the URL text is converted to an URL.
When pressing undo, first the space is undone, then the link is undone.
This is wrong because if the user did not want a link, after undoing the
link, inserting a new space will again convert to a link.

This commit splits `handleAutomaticLinkInsertion` into two parts:
determining if a link must be created, and actually inserting the link.
This makes it possible to execute code within the condition before and
after the insertion.
To fix the similar behavior for enter and shift-enter, another before
input handler is also added in order to let the default before input be
executed before creating the link.

Steps to reproduce:
- Go to a "To do" note
- Type "odoo.com"
- Press space/enter/shift-enter
- Undo a single time

=> The insertion was undone instead of the link transform.

task-5936310


[FIX] html_editor: not include surrounding backtick in pasted URL

When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF.

This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`).

Steps to reproduce:
- Copy the following text in the clipboard:
```
`odoo.com`
```
- Go to a "To do" note
- Paste

=> The link's URL was
```
odoo.com`
```

task-5936310

Steps to reproduce:
- Create a storable product "P1"
- Update on-hand quantity to 2 units
- Create a delivery with 2 units of P1 and keep it in draft state

Problem:
The forecast availability is displayed in red (not available), even though the stock is sufficient to fulfill the move.

Explication:
For draft consuming moves, the forecast availability is computed as: `virtual_available - move.product_qty`

In the case where stock exactly matches the demand, this results in 0. However, on the JS side, availability is evaluated with: `forecast_availability >= product_qty`

So with forecast_availability = 0 and product_qty = 2, the condition evaluates to False, incorrectly marking the move as not available.

https://github.com/odoo/odoo/blob/c7fede7f44c668ccc0a094d8341c3cae8879a7f1/addons/stock/static/src/widgets/forecast_widget.js#L31

Solution:
When the available quantity is sufficient to cover the move (using float_compare), set forecast_availability to the full available quantity instead of subtracting the move quantity. This ensures the JS condition correctly evaluates to True and the move is marked as available.

opw-5159142

Steps to reproduce the bug:
- Create a service product "P1":
  - In the Purchase tab:
    - Vendor: Azure Interior
    - Subcontract Service: True
  - UoM: dozen
  - Purchase UoM: unit

- Create a sales order with 1 dozen of P1
  - Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
  - Update the quantity from 1 to 2 dozen

Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186

Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.

https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178

opw-6049106