**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166219 Forward-Port-Of: odoo/odoo#159461

**Current behavior before PR:**

In mobile view, whatsapp tab had no search button.

**Desired behavior after PR is merged:**

In mobile view, added a search button to find whatsapp channel.

task-id:3525542





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

Forward-Port-Of: odoo/odoo#166219
Forward-Port-Of: odoo/odoo#159461

With tens of millions of messages, it would take 2.5 seconds to return before this commit, and only 10ms after this commit. Other benchmarks: lateral order: https://explain.dalibo.com/plan/f85dfd1h8b16c8h1 lateral max: https://explain.dalibo.com/plan/c55cd13106ce5dde Before PR for reference: https://explain.dalibo.com/plan/29e460261b6g17d7 Forward-Port-Of: odoo/odoo#167207

With tens of millions of messages, it would take 2.5 seconds to return before this commit, and only 10ms after this commit.

Other benchmarks:
lateral order: https://explain.dalibo.com/plan/f85dfd1h8b16c8h1
lateral max: https://explain.dalibo.com/plan/c55cd13106ce5dde

Before PR for reference: https://explain.dalibo.com/plan/29e460261b6g17d7

Forward-Port-Of: odoo/odoo#167207

## Description On firefox, when posting a message from the full composer with a template with some modifs, the browser falls into an infinite loop of processing events `selectionchange` in a loop ad-infinitum. When processing the `_onSelectionChange` handle, `_fixSelectionOnEditableRoot` has an assertion that the cursor would be placed on another place than the editable root. But after inlining, the cursor is collapsed in the beginning of the composer, and when normalizing the selection via `g

## Description
On firefox, when posting a message from the full composer with a template with some modifs, the browser falls into an infinite loop of processing events `selectionchange` in a loop ad-infinitum.
When processing the `_onSelectionChange` handle, `_fixSelectionOnEditableRoot` has an assertion that the cursor would be placed on another place than the editable root. But after inlining, the cursor is collapsed in the beginning of the composer, and when normalizing the selection via `getNormalizedCursorPosition` in `setSelection`, the cursor is back in the editable root because it is not editable anymore, which violate the previous assertion.
Instead of fixing `setSelection`, as it's too risky for a stable patch, we enforce the assertion of `_fixSelectionOnEditableRoot` to return early if we are not on the editable root.

## Reference
opw-3950957

PS: special thanks to (nby) and (dmo) for the help :) 

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

Forward-Port-Of: odoo/odoo#167226

__Description of the issue:__ The way that accrual works now is that future leaves are not taken into account for the balance both for the dashboard display and upon taking leaves. It is then possible to create situation that would lead to issues by taking leaves in a certain order; those issue are avoided with a cron that automatically cancels those issuing leaves. However, if leaves are causing issues and might be cancelled by the cron, a warning should appear on the dashboard of the employe

__Description of the issue:__
The way that accrual works now is that future leaves are not taken into account for the balance both for the dashboard display and upon taking leaves.
It is then possible to create situation that would lead to issues by taking leaves in a certain order; those issue are avoided with a cron that automatically cancels those issuing leaves. However, if leaves are causing issues and might be cancelled by the cron, a warning should appear on the dashboard of the employee to indicate that issue.

To reproduce the issue:
- Have any kind of accrual plan; the demo seniority for example
- Have a time off type that requires allocation
- Create an allocation for any employee for that accrual plan starting now and manually grant 1 day
- Go on that employee's dashboard
- Create a leave in a few days: it should be possible because one day is available for the employee
- Create another one the day before: the system allows it but it  is a discrepancy in the balance
- Look on the balance for the time off type: no warning is displayed

__Expected behaviour:__
There should be a warning after the creation of the second

__Description of the bugfix:__
This commit fixes the way the excess is detected to make it accurate. Additionally, the different warning messages were previously made incompatible with one another though they're not linked; this commit allows multiple warning messages if multiple are to be displayed.

task-3859558

Forward-Port-Of: odoo/odoo#161107

Description of the issue/feature this PR addresses: This PR addresses an issue in the attendance module. When an employee's job position is not set, the kiosk mode displays `false` in the employee kanban view when manually identified. Cause The issue arises when the job position is not set in the employee profile. Fix: This PR resolves the issue by modifying the kanban view template of employees in kiosk mode.if condition is added to ensure that the job position is displayed only if it

Description of the issue/feature this PR addresses:
This PR addresses an issue in the attendance module. When an employee's job position is not set, the kiosk mode displays `false` in the employee kanban view when manually identified.

Cause
The issue arises when the job position is not set in the employee profile.

Fix:
This PR resolves the issue by modifying the kanban view template of employees in kiosk mode.if condition is added to ensure that the job position is displayed only if it is set for the employee.

task-3892580

Forward-Port-Of: odoo/odoo#165342

-Sinve the removal of 'address_home_id' in https://github.com/odoo/odoo/commit/e8c48f824e078d643a3385fb910707d5525e927d we should adapt the scaffold code for payroll too. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166651

-Sinve the removal of 'address_home_id' in https://github.com/odoo/odoo/commit/e8c48f824e078d643a3385fb910707d5525e927d we should adapt the scaffold code for payroll too.


Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#166651

Removed odoo domain from blacklist, so that emails from odoo.com can be used for enrichment for demo/testing purposes. Task-3939876 Forward-Port-Of: odoo/odoo#166239

Removed odoo domain from blacklist, so that emails from odoo.com can be used for enrichment for demo/testing purposes.

Task-3939876

Forward-Port-Of: odoo/odoo#166239

Steps to reproduce: - Have two companies selected (i.e. San Francisco & Chicago) - Have 'Storage Locations' option enabled - Create a product then 'Update Quantity' - Create a quant and try to select the stock of the other company Issue: Only the locations in the first company will be shown. Moreover, in the case of tracked products, if the last quant created was one to a 'transit' location without company (e.g. 'Inter-company transit'), then only internal/transit location without compan

Steps to reproduce:
- Have two companies selected (i.e. San Francisco & Chicago)
- Have 'Storage Locations' option enabled
- Create a product then 'Update Quantity'
- Create a quant and try to select the stock of the other company

Issue:
Only the locations in the first company will be shown. Moreover, in the case of tracked products, if the last quant created was one to a 'transit' location without company (e.g. 'Inter-company transit'), then only internal/transit location without companies will be shown.

The issue comes from the `check_company` clause on the `location_id` field. This will make a check against the `company_id` of the record, which itself is a related field from the location

This doesn't make much sense, as for checking if the company of a location is correct, we check if the company of the location is within the company of the location.

This also introduces the issue mentionned above, as `check_company` will enforce to have ONLY that company & no-company, or just no-company depending on the company of the default location found.

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

Forward-Port-Of: odoo/odoo#167233

Make the pricelist dropdown for events tickets visible on smaller screens, if not, users will be stuck with the default pricelist and won't be able to change to the one they need to use. ## Steps to reproduce: 1. Create an event with selling tickets. 2. Make sure you have more than 1 pricelist available. 3. Go to order a ticket, and in the dialog, make sure our screen size is below 992px. 4. The dropdown to select pricelist is no longer visible. opw-3889376 Forward-Port-Of: odoo/odo

Make the pricelist dropdown for events tickets visible on smaller screens, if not, users will be stuck with the default pricelist and won't be able to change to the one they need to use.

## Steps to reproduce:

1. Create an event with selling tickets.
2. Make sure you have more than 1 pricelist available.
3. Go to order a ticket, and in the dialog, make sure our screen size is below 992px.
4. The dropdown to select pricelist is no longer visible.

opw-3889376

Forward-Port-Of: odoo/odoo#164605

To handle some advanced taxes setups, we changed the behavior of the 'Update taxes' so that it would recompute the prices before recomputing the taxes, but some business do not expect that recomputation, despite modifying the taxes. The businesses needing the prices recomputation will have to trigger it manually, and shouldn't rely on the Update Taxes button for that. Introduced by 537df32897494f94962637bd2b45d2618ff83e7c opw-3953806 --- I confirm I have signed the CLA and read th

To handle some advanced taxes setups, we changed the behavior of the 'Update taxes' so that it would recompute the prices before recomputing the taxes, but some business do not expect that recomputation, despite modifying the taxes.

The businesses needing the prices recomputation will have to trigger it manually, and shouldn't rely on the Update Taxes button for that.

Introduced by 537df32897494f94962637bd2b45d2618ff83e7c

opw-3953806


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

Forward-Port-Of: odoo/odoo#167321

When a "we-list" button, like the "add item" button, is clicked while a list input is focused, the click event doesn't trigger. Steps to reproduce the bug: - Drag and drop a "Form" snippet onto the page. - Click on the "+ Field" in the options. - Select "Multiple Checkboxes" for the "Type" option of the field. - Rename "Option 1" to "ABC" in the Checkbox list. - Click directly on the "Add new Checkbox" button. - Bug: nothing happens. The new checkbox is not added to the list. This

When a "we-list" button, like the "add item" button, is clicked while a list input is focused, the click event doesn't trigger.

Steps to reproduce the bug:

- Drag and drop a "Form" snippet onto the page.
- Click on the "+ Field" in the options.
- Select "Multiple Checkboxes" for the "Type" option of the field.
- Rename "Option 1" to "ABC" in the Checkbox list.
- Click directly on the "Add new Checkbox" button.
- Bug: nothing happens. The new checkbox is not added to the list.

This bug arises because when clicking the button, the "change" event of the input is triggered first before the "click" event of the button. Since the "change" event refreshes the widget, the "click" event is lost.

This commit adds a "setTimeout" in the "change" event handler to
prioritize "click" events within the "we-list".

task-3859207

Forward-Port-Of: odoo/odoo#163952
Forward-Port-Of: odoo/odoo#161506

Before this commit: ========== - Tax layout of order receipt was making a bad User experience. After this commit: ========= - Improved Tax layout of order receipt. task-3933459 Forward-Port-Of: odoo/odoo#166317

Before this commit:
==========
- Tax layout of order receipt was making a bad User experience.

After this commit:
=========
- Improved Tax layout of order receipt.

task-3933459

Forward-Port-Of: odoo/odoo#166317

For version 17.0 only Problem: In restaurant, in the product page, we don't have anything to remind which table is selected Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" module - Open a restaurant session - Click on a table, the product page is loaded and we don't see the table number in the navbar Note: Solution copied from version 17.1 opw-3929069 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po

For version 17.0 only

Problem:
In restaurant, in the product page, we don't have anything to remind which table is selected

Steps to reproduce:
- Install "Point of Sale" app and "pos_restaurant" module
- Open a restaurant session
- Click on a table, the product page is loaded and we don't see the table number in the navbar

Note:
Solution copied from version 17.1

opw-3929069


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

Forward-Port-Of: odoo/odoo#165578

Since lxml 5.2 (https://github.com/lxml/lxml/commit/73778681f14359fe6d16644e69aaca276eba525a) lxml_html_clean is in another package We can adapt the requirements after python 3.12 (based on ubuntu 24.04) We can use | operator in debian/control We may need to adapt documentation since the current sed script will fail This pr proposes an alternative script to avoid to use a sed Current sed: `sed -n -e '/^Depends:/,/^Pre/ s/ python3-\(.*\),/python3-\1/p' debian/control` This sed wi

Since lxml 5.2 (https://github.com/lxml/lxml/commit/73778681f14359fe6d16644e69aaca276eba525a) lxml_html_clean is in another package

We can adapt the requirements after python 3.12 (based on ubuntu 24.04)
We can use | operator in debian/control

We may need to adapt documentation since the current sed script will fail

This pr proposes an alternative script to avoid to use a sed

Current sed:
`sed -n -e '/^Depends:/,/^Pre/ s/ python3-\(.*\),/python3-\1/p' debian/control`

This sed will fail and give the result `python3-lxml-html-clean | python3-lxml` for the lxml line, we need to remove the spaces

Forward-Port-Of: odoo/odoo#167350
Forward-Port-Of: odoo/odoo#163788

Issue: ====== Currently you can delete content inside contenteditable=false elements Steps to reproduce the issue: ============================= - Go to website, edit mode, drag a text block - Add `contenteditable="false"` to a `p` element - Select a word in that `p` element and press on any character, it will be deleted Origin of the issue: ==================== Theres is no check if the element is inside a contenteditable=false or not. Solution: ========= We need to check

Issue:
======
Currently you can delete content inside contenteditable=false elements

Steps to reproduce the issue:
=============================
- Go to website, edit mode, drag a text block
- Add `contenteditable="false"` to a `p` element
- Select a word in that `p` element and press on any character, it will
  be deleted

Origin of the issue:
====================
Theres is no check if the element is inside a contenteditable=false or
not.

Solution:
=========
We need to check if the selection is in editable or not to be able to
apply commands.

task-3605829

Forward-Port-Of: odoo/odoo#167016
Forward-Port-Of: odoo/odoo#155758

If user claimed ewallet in confirm order stage, it would redirect them back to review order stage with wrong calculation if shipping had cost. opw-3825880 Forward-Port-Of: odoo/odoo#166324 Forward-Port-Of: odoo/odoo#161620

If user claimed ewallet in confirm order stage, it would redirect them back to review order stage with wrong calculation if shipping had cost.
opw-3825880

Forward-Port-Of: odoo/odoo#166324
Forward-Port-Of: odoo/odoo#161620

The test web:TestImage.test_04_web_content_filename_secure is failing on the runbot for the version 16 (16.0, saas-16.3 and saas-16.4). The error is 'str' object has no attribute 'removeprefix' and this method has been introduced in python 3.9 while version 16 only support python 3.7. To solve the problem we replace that method call with a supported equivalent in python 3.7. Task-3944583 Forward-Port-Of: odoo/odoo#167303

The test web:TestImage.test_04_web_content_filename_secure is failing on the runbot for the version 16 (16.0, saas-16.3 and saas-16.4). The error is 'str' object has no attribute 'removeprefix' and this method has been introduced in python 3.9 while version 16 only support python 3.7.

To solve the problem we replace that method call with a supported equivalent in python 3.7.

Task-3944583

Forward-Port-Of: odoo/odoo#167303

Since python 3.11, the patch.dict method changed [0] to use pkgutil to resolve names. This new method is not able to patch our `odoo.tools.config.options`. Fixed by using the object instead of a string literal. [0]: python/cpython@ab7fcc8fbdc11091370deeb000a787fb02f9b13d Forward-Port-Of: odoo/odoo#167306

Since python 3.11, the patch.dict method changed [0] to use pkgutil to resolve names. This new method is not able to patch our `odoo.tools.config.options`.

Fixed by using the object instead of a string literal.

[0]: python/cpython@ab7fcc8fbdc11091370deeb000a787fb02f9b13d

Forward-Port-Of: odoo/odoo#167306

Before this fix, when a spreadsheet contained any odoo link (to an action, a menu or a XML Id), when a public user opened the spreadsheet and clicked on the link, he had a nonsensical page because the parser and resolver of the link is never loaded for the public user (he would not have access to the menu data anyway). After this fix, we replace the odoo links by their label, so the link itself is removed. Task: 3925333 --- I confirm I have signed the CLA and read the PR guid

Before this fix, when a spreadsheet contained any odoo link (to an action, a menu or a XML Id), when a public user opened the spreadsheet and clicked on the link, he had a nonsensical page because the parser and resolver of the link is never loaded for the public user (he would not have access to the menu data anyway).

After this fix, we replace the odoo links by their label, so the link itself is removed.

Task: 3925333






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

Forward-Port-Of: odoo/odoo#167352
Forward-Port-Of: odoo/odoo#166843

Backport of https://github.com/odoo/odoo/commit/225d52559e693728f72ca1f00302f69c7901361e \+ add Test. Previously, when following those steps: - create SO with one line with a tax - create a down payment for 30% - remove tax on invoice line - post invoice - create new down payment for 30% A line with 0 amount and no tax was created in addition of other lines. This because, during the calculation of the down payment lines, and the ventilation between all taxes, it would take the line w

Backport of https://github.com/odoo/odoo/commit/225d52559e693728f72ca1f00302f69c7901361e
\+ add Test.

Previously, when following those steps:
- create SO with one line with a tax
- create a down payment for 30%
- remove tax on invoice line
- post invoice
- create new down payment for 30%

A line with 0 amount and no tax was created in addition of other lines. This because, during the calculation of the down payment lines, and the ventilation between all taxes, it would take the line with no tax into account. Note in this example we remove the tax from the invoice, but it would be the same if we changed the tax for another one.
This is done by excluding the down payment lines. This should already have been the case before, but had no real effect because their quantity & price_subtotal = 0.

Forward-Port-Of: odoo/odoo#166688
Forward-Port-Of: odoo/odoo#166520

Mailing Trace are available to every base.group_user but it is too wide. No current use case justify it. task-3906727 Forward-Port-Of: odoo/odoo#165803

Mailing Trace are available to every base.group_user but it is too wide. No current use case justify it.

task-3906727

Forward-Port-Of: odoo/odoo#165803

Due to change in 17.0 qty_done become picked on the stock.move Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167295

Due to change in 17.0 qty_done become picked on the stock.move

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#167295

Shut down the server to simulate a connection lost when being in a multi record view. Click on a record to open it in form view. As the server is down, the web_read rpc will fail. The error will be caught by the onError in the action service, which will try to restore the previous controller (the multi record view). The server being down, requests for that controller will fail as well, and we'll end up again in the same onError callback. Since [1], we'll indefinitely try to reload the multi r

Shut down the server to simulate a connection lost when being in a multi record view. Click on a record to open it in form view. As the server is down, the web_read rpc will fail. The error will be caught by the onError in the action service, which will try to restore the previous controller (the multi record view). The server being down, requests for that controller will fail as well, and we'll end up again in the same onError callback.

Since [1], we'll indefinitely try to reload the multi record view, because we removed the check detecting that the error occurs in the controller that is already in the DOM. If that controller fails, there's no point trying to restore it again, instead, we just show the error.

This commit simply restores that part of the code as it was before [1].

[1] odoo/odoo@9c954de94148ab6f3b8d02e6a4713a87fe233a28

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#166295

To reproduce: ============= - enable creating ticket in helpdesk with mail alias - having to stages in helpdesk **New** and **In Progress** - create an automated action that is triggered with `on_message_sent` that will move a ticket from **New** to **In Progress** - send an email to the mail alias from an email that doesn't have a contact in the database -> the automated action will be triggered whereas it shouldn't Problem: ======== To know if the email is from a customer and set the

To reproduce:
=============
- enable creating ticket in helpdesk with mail alias
- having to stages in helpdesk **New** and **In Progress**
- create an automated action that is triggered with `on_message_sent` that will move a ticket from **New** to **In Progress**
- send an email to the mail alias from an email that doesn't have a contact in the database -> the automated action will be triggered whereas it shouldn't

Problem:
========
To know if the email is from a customer and set the `mail_trigger` to `on_message_received` we were checking if the `author_id` of the message, which is `False` if the email is from an unknown contact.

Solution:
=========
if the `author_id` is `False`, it means that the email is from outside, so the `mail_trigger` should be `on_message_received`

opw-3833857

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

Forward-Port-Of: odoo/odoo#162805

**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 Forward-Port-Of: odoo/enterprise#62888 Forward-Port-Of: odoo/enterprise#59530

**Current behavior before PR:**

In mobile view, whatsapp tab had no search button.

**Desired behavior after PR is merged:**

In mobile view, added a search button to find whatsapp channel.

task-id:3525542

Forward-Port-Of: odoo/enterprise#62888
Forward-Port-Of: odoo/enterprise#59530

Create a new journal entry Post it Reset to draft Delete the name Go to General Ledger Export PDF Error TypeError: object of type 'NoneType' has no len() This occurs because when the name field is blanked, it is set to False opw-3925088 Forward-Port-Of: odoo/enterprise#63161

Create a new journal entry
Post it
Reset to draft
Delete the name
Go to General Ledger
Export PDF

Error
TypeError: object of type 'NoneType' has no len()

This occurs because when the name field is blanked, it is set to False

opw-3925088

Forward-Port-Of: odoo/enterprise#63161

The problem is that the message ``` This invoice will be paid using direct debit and is only sent for informative purposes. sent for informative purposes ``` is displayed even in invoices that doesn't use Direct Debit after a studio change. Steps: - install `account_sepa_direct_debit` - install `web_studio` - Edit `Invoices` report on studio - Save - Try to print an invoice report - SDD (Sepa Direct Debit) message will be displayed even if this invo

The problem is that the message
```
This invoice will be paid using direct debit and is only sent for
informative purposes. sent for informative purposes
```
is displayed even in invoices that doesn't use Direct Debit after a studio change.

Steps:
    - install `account_sepa_direct_debit`
    - install `web_studio`
    - Edit `Invoices` report on studio
    - Save
    - Try to print an invoice report
    - SDD (Sepa Direct Debit) message will be displayed
        even if this invoice doesn't use SDD

This inconsistency was due to two errors in the report generated by SDD
```xml
<p t-if="o.sdd_mandate_id">
    <span>
        <p>
            This invoice will be paid using direct debit and is only
            sent for informative purposes.
        </p>
        <p>
            Please do not pay it manually, the payment will be asked to your bank to be processed
            automatically.
        </p>
    </span>
</p>
```
A `<p>`/`<span>` can't contains another `<p>`

as defined here https://html.spec.whatwg.org/#the-p-element or https://html.spec.whatwg.org/#the-span-element `<P>`/`<span>` can only contains "Phrasing content" (https://html.spec.whatwg.org/#phrasing-content-2) `<div>` and `<p>` for example are not phrasing content

opw-3908411

Forward-Port-Of: odoo/enterprise#63345

This will add tracking to some employee field that have an impact on withholding taxes. Task: 3879035 Forward-Port-Of: odoo/enterprise#61315

This will add tracking to some employee field that have an impact on withholding taxes.

Task: 3879035

Forward-Port-Of: odoo/enterprise#61315

also modified: test_marketing_automation Previously, campaign templates could not be used by non-admin users. This commit allows non-admin users with access to the marketing_automation app to create campaigns from templates as expected. task-3603400 Backport of: odoo@8fcdb85f0c4279c6a16c26aa669496cf456f0631 Forward-Port-Of: odoo/enterprise#63155

also modified: test_marketing_automation

Previously, campaign templates could not be used by non-admin users.

This commit allows non-admin users with access to the marketing_automation app to create campaigns from
templates as expected.

task-3603400

Backport of: odoo@8fcdb85f0c4279c6a16c26aa669496cf456f0631

Forward-Port-Of: odoo/enterprise#63155

**Current behavior:** If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some unexpected behavior if a different destination barcode is scanned after the similar-product pickings have all been scanned. **Expected behavior:** With this specific configuration, pickings with the same product should all be changed when a different destination is scanned. **Steps to reproduce:

**Current behavior:**
If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some unexpected behavior if a different destination barcode is scanned after the similar-product pickings have all been scanned.

**Expected behavior:**
With this specific configuration, pickings with the same product should all be changed when a different destination is scanned.

**Steps to reproduce:**
1. In the Internal Transfers picking type, configure the barcode settings like so:
     `Source Location: Mandatory Scan`
     `Product: True`
     `Destination Location: After each product`

2. Create some new internal location (e.g., .../Stock/shelf)

3. Create a new batch picking with 2 internal transfer pickings for the same product

4. Go to the batch operation barcode menu, select the created batch picking

5. Scan the source location, scan the first product code and then manually add the second picking quantity with the add quantity button, scan the newly created internal location

6. Observe that the last picking destination location has changed and the first has not- furthermore trying to change the second's destination location via scan does not work (manual changes via the edit button/form still possible)

**Cause of the issue:**
The method of changing destination does not account for this setup, so there is no specific handling for it. Only the selected line will be modified by a new destination scan.

**Fix:**
Extract the line modification code into a new function and override it in the batch_picking module to change the entire current batch of lines that have been scanned (that all have the same product).

opw-3733870

Forward-Port-Of: odoo/enterprise#62201