**Steps to reproduce:**
- Install Accounting

- Create an invoice with an invoice line
- Save the invoice

- Change the unit price => The totals should change
- Change the product => The unit price and the totals should change
- Change the unit price again

**Issue:**
After this point, the totals don't change anymore, even if the unit price is changed several times.
Only saving the form will adapt the totals correctly.

**Cause:**
When changing the unit price the first time, a "price_unit "key is added in the onchange values.
When changing the product, a "product_id" key is added after the price key.
Changing the product triggers an onchange of the price with the price of the new product.
However, when the price is changed again, as the "price_unit" key already exists, it's reused and its position is still before "product_id" key even if it should be computed after.
This order results in the use of the price of the second product instead of the one entered manually when computing the "tax_totals".

**Solution:**
If "product_id" and "price_unit" are the values of the onchange method, the list of values is reordered to make sure that "product_id" is computed first.

opw-5012125




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

Forward-Port-Of: odoo/odoo#239110
Forward-Port-Of: odoo/odoo#232684

Calling Avatax without lines results in an error and blocks flows:

```
Odoo could not fetch the taxes related to MXXX - SOXXX/XXX.
Please check the status of `Sales Order XXX` in the AvaTax portal.
Transactions must have at least one line.
```

There are various cases this can happen:

1/ if `industry_fsm_stock` is installed, empty orders are confirmed [1],
2/ if you put the `end_date` of a subscription before the `next_invoice_date`,
   then none of the lines are considered invoiceable [2] and you get the
   error when viewing the subscription in the portal

This commit filters out orders without lines.

It's also possible to filter this on the level of the models by doing it in `_get_and_set_external_taxes_on_eligible_records()`. However, this means doing it separately for each model, and requires every implementer do it manually.

[1] https://github.com/odoo/enterprise/blob/703e7fd413e93a8287da98286aa93b9699ae3e96/industry_fsm_stock/models/project_task.py#L159
[2] https://github.com/odoo/enterprise/blob/c7bf4367a9bf6757a36a9f34a872a6e35a19a3a5/sale_subscription/models/sale_order_line.py#L475

opw-5214609
opw-5247727
opw-5311132
opw-5385960

Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city).

**Steps to Reproduce:**
1. Install and configure the **Envia Shipping** module.
2. Create a partner without an address (only name + phone).
3. Create quotation for that partner with a deliverable product (e.g; Conference Chair).
4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**".

**Error:**
`TypeError - quote_from_bytes() expected bytes`

**Cause:**
At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised.

**Fix:**
This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2]

[1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593
[2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624

sentry-7063870478

Forward-Port-Of: odoo/enterprise#100734

Versions
--------
- 18.0+

Steps
-----
1. Create a loyalty program;
2. Create a reward;
3. Add a Product domain to the reward containing the `not ilike` operator;
4. Load the POS;
5. Try to trigger the Loyalty program;
6. The Reward is not applied when the domain is satisfied

Issue
-----
Loyalty Program rewards containing `not ilike`-based product domains are not applied when they should.

Cause
-----
The `_replace_ilike_with_in` function in loyalty_reward.py converts the `ilike` and `not ilike` operators by first fetching the records that very the domain with the operator used, and then by replacing the domain by `in` or `not in` with the returned records ids. This is problematic as in the case of `not ilike`, it leads to a double negation.

Example
-----
For `ilike`: `['categ_id', 'ilike', 'service']`
-> Search for all categories that contain "service": `_search([('display_name', 'ilike', 'service')])` 
-> Return new domain `['categ_id', 'in', matching_ids]`
Which is correct.

For `not ilike`: `['categ_id', 'not ilike', 'service']`
-> Search for all categories that **do not contain** "service": `_search([('display_name', 'not ilike', 'service')])`
-> Return new domain `['categ_id', 'not in', matching_ids]`
Which is incorrect, as the matching_ids are already the ids that are not like "service". (i.e., *categ_id not in the categories that do not contain "service"* <=> *categ_id in the categories that contain "service"*, opposite of what is expected.)

Solution
--------
1. Perform the initial search with `ilike` for both operators

opw-5182818

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

Forward-Port-Of: odoo/odoo#235656

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#101625
Forward-Port-Of: odoo/enterprise#100275

### Steps to reproduce:

- Create a rentable, storable product
- Create and confirm a rental order for 1 unit of this product
- Click on pickup
- Inventory > Reporting > Moves History
#### > Your pickup move appears without any reference

### Cause of the issue:

The issue has been introduced in d0c1e7845feeee1c2e85a21b5d40570d051458d3 which purpose was to remove the `name` field of the `stock.move` model. However, the `_compute_reference` compute method use to rely on this `move.name` to propagate the info that the move was related to a rental order (since there is no picking). Indeed prior to saas-18.4, the compute method was:
https://github.com/odoo/odoo/blob/404cb10283cbc706eae67dd793ced363273f3602/addons/stock/models/stock_move.py#L325-L328 
And the reference to the rental order was set on the move at pickup: https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L303-L313 https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L248-L257

### Fix:

Since the reference field is a computed and stored fields and since some of its dependencies are set at creation the rental move we can not set the `reference` directly in the creation of the record as we used to do for its name since the compute method will then override and erase or reference.

opw-5385004

**Steps to reproduce:**
- Install Accounting

- Create an invoice with an invoice line
- Save the invoice

- Change the unit price => The totals should change
- Change the product => The unit price and the totals should change
- Change the unit price again

**Issue:**
After this point, the totals don't change anymore, even if the unit price is changed several times.
Only saving the form will adapt the totals correctly.

**Cause:**
When changing the unit price the first time, a "price_unit "key is added in the onchange values.
When changing the product, a "product_id" key is added after the price key.
Changing the product triggers an onchange of the price with the price of the new product.
However, when the price is changed again, as the "price_unit" key already exists, it's reused and its position is still before "product_id" key even if it should be computed after.
This order results in the use of the price of the second product instead of the one entered manually when computing the "tax_totals".

**Solution:**
If "product_id" and "price_unit" are the values of the onchange method, the list of values is reordered to make sure that "product_id" is computed first.

opw-5012125




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

Forward-Port-Of: odoo/odoo#239110
Forward-Port-Of: odoo/odoo#232684

Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city).

**Steps to Reproduce:**
1. Install and configure the **Envia Shipping** module.
2. Create a partner without an address (only name + phone).
3. Create quotation for that partner with a deliverable product (e.g; Conference Chair).
4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**".

**Error:**
`TypeError - quote_from_bytes() expected bytes`

**Cause:**
At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised.

**Fix:**
This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2]

[1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593
[2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624

sentry-7063870478

Forward-Port-Of: odoo/enterprise#100734

Versions
--------
- 18.0+

Steps
-----
1. Create a loyalty program;
2. Create a reward;
3. Add a Product domain to the reward containing the `not ilike` operator;
4. Load the POS;
5. Try to trigger the Loyalty program;
6. The Reward is not applied when the domain is satisfied

Issue
-----
Loyalty Program rewards containing `not ilike`-based product domains are not applied when they should.

Cause
-----
The `_replace_ilike_with_in` function in loyalty_reward.py converts the `ilike` and `not ilike` operators by first fetching the records that very the domain with the operator used, and then by replacing the domain by `in` or `not in` with the returned records ids. This is problematic as in the case of `not ilike`, it leads to a double negation.

Example
-----
For `ilike`: `['categ_id', 'ilike', 'service']`
-> Search for all categories that contain "service": `_search([('display_name', 'ilike', 'service')])` 
-> Return new domain `['categ_id', 'in', matching_ids]`
Which is correct.

For `not ilike`: `['categ_id', 'not ilike', 'service']`
-> Search for all categories that **do not contain** "service": `_search([('display_name', 'not ilike', 'service')])`
-> Return new domain `['categ_id', 'not in', matching_ids]`
Which is incorrect, as the matching_ids are already the ids that are not like "service". (i.e., *categ_id not in the categories that do not contain "service"* <=> *categ_id in the categories that contain "service"*, opposite of what is expected.)

Solution
--------
1. Perform the initial search with `ilike` for both operators

opw-5182818

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

Forward-Port-Of: odoo/odoo#235656

#### [FIX] snailmail: extract report PDF generation function
We extract a function `_generate_report_pdf` from `_fetch_attachment`
to create the report PDF (and its filename).
The resulting PDF's margins are fixed and a cover page is added to it
after the function is called in `_fetch_attachment`.

The new function is extended in the related enterprise commit to generate the
followup report inside `_fetch_attachment` (when sent via snailmail).
This way it will respect the cover page option and page layout / size requirements.
(See the related enterprise PR for more details.)

#### [FIX] snailmail: extract letter resending function

We extract a function `_resend_letters` from the `update_resend_action`.
It handles the regeneration of letters after the cover option has been updated.
This way the resending logic can easily extended to adjust the logic depending
on attributes of the letter.

The new function is extended in the related enterprise commit to disable
the resending for followup report letters.
This is necessary because the followup report requires special options
to be generated that are not available at the point of the regeneration.

#### references

opw-5160121
opw-5209504
opw-5226366

Forward-Port-Of: odoo/odoo#238905
Forward-Port-Of: odoo/odoo#235699

#### [FIX] snailmail_account_followup: fix address, cover page and layout

Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
   lead to problems with the service we use to send the actual letter.
   They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
   So we can not work around problems with the address generation
   by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
   with our current snailmail provider (Pingen). But there is no error
   message about it. (Although we do have something in the usual
   snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
   so the user does not receive any feedback.
   This could be an issue in case multiple follow-up reports are sent
   at the same time.

This commit fixes these issues. (See below for details.)

(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.

(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
  not rejected by Pingen because of this

But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.

(4)
We try to print / send the letter even if the address is invalid

Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
   (Settings -> Accounting -> section "Customer Invoices")
   - enabled to test for the cover page
   - disabled to test that the address generation is adjusted
4. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
   In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
   (or just search for "snailmail" in the main screen)
   And select the letter
6. Download the PDF document

#### [FIX] snailmail_account_followup: forbid regenerating failed letters

The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.

Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).

After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.

Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
   Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)

#### references

opw-5160121
opw-5209504
opw-5226366

Forward-Port-Of: odoo/enterprise#101596
Forward-Port-Of: odoo/enterprise#99491

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#101625
Forward-Port-Of: odoo/enterprise#100275

Steps to reproduce
-----
- Enable batch pickings
- Create a product
- Create 2 receptions for the product (qty > 1)
- Create a batch with the 2 transfers
- Open the batch in barcode
- Scan part of both pickings
- Go back to the barcode main screen
- Open the batch again

> Both pickings have their demand = partially delivered quantity

Cause
-----
When leaving the page, we trigger

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68

in which we end up merging the moves together

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51

This has been added by 9753c24 (ade0bef in 17.0)

The problem is that `_merge_moves` merges all of the moves into the first of `merge_into`

https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088

This, however, doesn't make much sense for batches because the moves can be from different pickings.

-----
Ticket:
opw-5163740

Forward-Port-Of: odoo/enterprise#101630
Forward-Port-Of: odoo/enterprise#100940

### Steps to reproduce:

- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
    - Final Product (FP) with an empty bom
    - By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination

### Cause of the issue:

Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.

### Note:

The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f

opw-5350222

Forward-Port-Of: odoo/enterprise#101455
Forward-Port-Of: odoo/enterprise#101087

Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city).

**Steps to Reproduce:**
1. Install and configure the **Envia Shipping** module.
2. Create a partner without an address (only name + phone).
3. Create quotation for that partner with a deliverable product (e.g; Conference Chair).
4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**".

**Error:**
`TypeError - quote_from_bytes() expected bytes`

**Cause:**
At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised.

**Fix:**
This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2]

[1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593
[2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624

sentry-7063870478

Forward-Port-Of: odoo/enterprise#100734

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#101625
Forward-Port-Of: odoo/enterprise#100275

How to Reproduce : 
1. Remove 'Create' access on the 'Knowledge Article' model for Portal and 
   Internal users.
2. Now log in as a Portal.
3. Try to create a new private article.
4. Log in as an Internal user.
5. Try to create a new private article.

Both Internal and Portal users can still create private articles even after
'Create access' is removed.

Article creation logic in `knowledge.article` was bypassing the usual access
rights because of `sudo` (mainly to add the creator as a member, since creation
rights on the member model are not granted). This allowed users to create
private articles even without create access.

This commit introduces:
1. Model-level access check in `create`. Sudo the creation of articles only when
   the user has create rights.

2. UI imp to hide the '+' button in the sidebar and the `New` button in
   the topbar when the user doesn't have create access.

3. New test cases to verify that model-level access rights are respected when creating an article.

task-4916280

Forward-Port-Of: odoo/enterprise#98910
Forward-Port-Of: odoo/enterprise#93034

**Steps to reproduce:**
- create a product tracked by lot 
- create a lot with a quantity of 2
- create a new sale order
- add two sale order lines, both for a quantity of 1 of the product
- confirm
- open the picking in barcode
- scan the stock location
- scan the lot 
- scan the lot another time
- validate

**Current behavior:**
a backorder is created

**Expected behavior:**
No back order should be created 

**Cause of the issue:**
After scanning the lot for the first time we have the following situation: 
two lines : 
- one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1
- one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1
both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2
All of this is correct.

when scanning the lot for the second time: 
_findLine iterates through the lines to select the right 
line to use.
 _findLine calls _lineIsNotComplete on the first line to check 
if it's complete (this first line is complete).
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684
But _lineIsNotComplete will actually do the check on the 
parent line (which is not complete), so the return value will 
be true. 
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338
As a consequence, the quantity will be added in the first line and 
we will have a qty_done of 2 in the first line 
and a qty_done of 0 in the second line. 
Which will lead to the creation of a back order

opw

Forward-Port-Of: odoo/enterprise#101508
Forward-Port-Of: odoo/enterprise#99774

## Versions
19.0+

## Issue
A customer subscribing to a service can checkout without filling its data (incl. country). This leads to a failure of the next payment and a message in the chatter telling that "Automatic payment failed. No country specified on payment_token's partner".

## Steps to reproduce
*Ensure Sales app is installed*
- Create a customer account without filling personal data in;
- Navigate to the shop:
  - Look for a subscription service (ending with "SUB") and add it to cart;
  - Go to the cart and click the checkout button (automatically bypassing the addresses form);
  - Pay with Demo.
- Logout and sign in as admin user:
  - Go to Sales and open the latest SO (related to the test user):
    - Duplicate the SO and activate debug mode;
    - Open "Other Info" tab:
      - Change the subscription starting date for any date in the past;
      - Set the Payment Token selecting the available one; - Confirm the order.
- Navigate to Scheduled Actions:
  - Look for "Sale Subscription: generate recurring invoices and payments" action and open it:
    - Click "Run Manually".
- Come back to the duplicated subscription SO and look at the chatter's last message:
  - OdooBot's message tells that "Automatic payment failed. No country specified on payment_token's partner".

## Cause
Task 4307281 introduced address info bypass to fasten checkout for services but subscriptions, even for services, require the country to be set for recurring payments as per https://github.com/odoo/enterprise/blob/f40e24e67a1664a13acdd01578d8269d084ee421/sale_subscription/models/sale_order.py#L1751-L1757

opw-5268156

Forward-Port-Of: odoo/enterprise#101372

Before this commit:
- For an employee with a Working Schedule as the work entry source and a default overtime ruleset (which creates a specific work entry type for overtime hours), creating an attendance with a check-in earlier than the employee’s normal working schedule start was not handled correctly. The early portion was ignored, resulting in a wrong attendance work entry duration (e.g., 06:15 instead of 08:00).
- Work entries were not created automatically when approving the attendance. The user had to click Reset to force the generation, which is not the intended workflow.

After this commit:
- Attendance boundaries are now correctly normalized against the employee’s Working Schedule, ensuring the full expected duration is taken into account, even when the check-in occurs before the official start time.
- The overtime ruleset is applied correctly, and the generated intervals properly reflect both standard working hours and overtime hours.
- Work entries are now automatically created upon approval of the attendance, removing the need for any manual Reset action.

task-5082562

Forward-Port-Of: odoo/enterprise#100616

**Steps to reproduce:**
- Install Accounting

- Create an invoice with an invoice line
- Save the invoice

- Change the unit price => The totals should change
- Change the product => The unit price and the totals should change
- Change the unit price again

**Issue:**
After this point, the totals don't change anymore, even if the unit price is changed several times.
Only saving the form will adapt the totals correctly.

**Cause:**
When changing the unit price the first time, a "price_unit "key is added in the onchange values.
When changing the product, a "product_id" key is added after the price key.
Changing the product triggers an onchange of the price with the price of the new product.
However, when the price is changed again, as the "price_unit" key already exists, it's reused and its position is still before "product_id" key even if it should be computed after.
This order results in the use of the price of the second product instead of the one entered manually when computing the "tax_totals".

**Solution:**
If "product_id" and "price_unit" are the values of the onchange method, the list of values is reordered to make sure that "product_id" is computed first.

opw-5012125




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

Forward-Port-Of: odoo/odoo#239110
Forward-Port-Of: odoo/odoo#232684

Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city).

**Steps to Reproduce:**
1. Install and configure the **Envia Shipping** module.
2. Create a partner without an address (only name + phone).
3. Create quotation for that partner with a deliverable product (e.g; Conference Chair).
4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**".

**Error:**
`TypeError - quote_from_bytes() expected bytes`

**Cause:**
At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised.

**Fix:**
This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2]

[1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593
[2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624

sentry-7063870478

Forward-Port-Of: odoo/enterprise#100734

Versions
--------
- 18.0+

Steps
-----
1. Create a loyalty program;
2. Create a reward;
3. Add a Product domain to the reward containing the `not ilike` operator;
4. Load the POS;
5. Try to trigger the Loyalty program;
6. The Reward is not applied when the domain is satisfied

Issue
-----
Loyalty Program rewards containing `not ilike`-based product domains are not applied when they should.

Cause
-----
The `_replace_ilike_with_in` function in loyalty_reward.py converts the `ilike` and `not ilike` operators by first fetching the records that very the domain with the operator used, and then by replacing the domain by `in` or `not in` with the returned records ids. This is problematic as in the case of `not ilike`, it leads to a double negation.

Example
-----
For `ilike`: `['categ_id', 'ilike', 'service']`
-> Search for all categories that contain "service": `_search([('display_name', 'ilike', 'service')])` 
-> Return new domain `['categ_id', 'in', matching_ids]`
Which is correct.

For `not ilike`: `['categ_id', 'not ilike', 'service']`
-> Search for all categories that **do not contain** "service": `_search([('display_name', 'not ilike', 'service')])`
-> Return new domain `['categ_id', 'not in', matching_ids]`
Which is incorrect, as the matching_ids are already the ids that are not like "service". (i.e., *categ_id not in the categories that do not contain "service"* <=> *categ_id in the categories that contain "service"*, opposite of what is expected.)

Solution
--------
1. Perform the initial search with `ilike` for both operators

opw-5182818

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

Forward-Port-Of: odoo/odoo#235656

Currently, when the product specification is shown in an accordion, single-value attributes are displayed twice, causing duplicate information to appear.

**Steps to replicate:**
* Install `website_sale` with demo data.
* Open Products, pick any product, and add an attribute with a single value.
* Edit that product’s website page and set Specification → In accordion.

**Observed Behavior:**
* Specifications for single valued attributes are shown twice.

**Root cause:**
* This happens because [1] always shows single attribute values, regardless of the specification display style.

**Solution:**
* Hide the extra table when accordion is active.

**Before:**
<img width="1851" height="928" alt="image" src="https://github.com/user-attachments/assets/dbaccc28-dbbb-41df-9a04-b0330479e480" />
**After:**
<img width="1858" height="927" alt="image" src="https://github.com/user-attachments/assets/09317662-3d40-4128-a6d3-9f9c0af618c4" />

[1]:
https://github.com/odoo/odoo/blob/ac6960dc553088894e688bcc0f4a49245aa02d6c/addons/website_sale/views/templates.xml#L2175-L2195

opw-5382484

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#101625
Forward-Port-Of: odoo/enterprise#100275

Issue
-----
Procurement quantities are computed wrong (for non-dropshipped sales) when the dropship module is installed.

Steps to reproduce
-----
- Enable dropshipping & multi step route
- Set delivery rule as MTSO
- Create a product
    - Stock of 5
    - Add a vendor
- Create a SO
- Sell 6 of the product
- Confirm SO
- Open linked PO and confirm it
- Go back to the SO and change quantity of the product to 8
- Open the second linked PO

> Quantity is 7 instead of 2

Cause
-----
Writing the new quantity triggers `action_launch_stock_rule`

https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/sale_stock/models/sale_order_line.py#L255

in which we call `_get_qty_procurement` to get the 'already handled' quantity

https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/sale_stock/models/sale_order_line.py#L384

The problem is that this function is overriden in `stock_dropshipping`

https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/stock_dropshipping/models/sale.py#L42-L52

Because the condition is true, we use the purchase line's `po_line.product_qty` instead of calling `super()`. Since `po_line.product_qty == 1`, we simply return 1.

With this, we end up creating a procurement of 8 - 1 = 7 units as if we were doing a dropship, instead of the expected 2 units.

-----
Ticket:
opw-5121035

Steps to reproduce
-----
- Enable batch pickings
- Create a product
- Create 2 receptions for the product (qty > 1)
- Create a batch with the 2 transfers
- Open the batch in barcode
- Scan part of both pickings
- Go back to the barcode main screen
- Open the batch again

> Both pickings have their demand = partially delivered quantity

Cause
-----
When leaving the page, we trigger

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68

in which we end up merging the moves together

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51

This has been added by 9753c24 (ade0bef in 17.0)

The problem is that `_merge_moves` merges all of the moves into the first of `merge_into`

https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088

This, however, doesn't make much sense for batches because the moves can be from different pickings.

-----
Ticket:
opw-5163740

Forward-Port-Of: odoo/enterprise#101630
Forward-Port-Of: odoo/enterprise#100940

### Steps to reproduce:

- Create a rentable, storable product
- Create and confirm a rental order for 1 unit of this product
- Click on pickup
- Inventory > Reporting > Moves History
#### > Your pickup move appears without any reference

### Cause of the issue:

The issue has been introduced in d0c1e7845feeee1c2e85a21b5d40570d051458d3 which purpose was to remove the `name` field of the `stock.move` model. However, the `_compute_reference` compute method use to rely on this `move.name` to propagate the info that the move was related to a rental order (since there is no picking). Indeed prior to saas-18.4, the compute method was:
https://github.com/odoo/odoo/blob/404cb10283cbc706eae67dd793ced363273f3602/addons/stock/models/stock_move.py#L325-L328 
And the reference to the rental order was set on the move at pickup: https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L303-L313 https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L248-L257

### Fix:

Since the reference field is a computed and stored fields and since some of its dependencies are set at creation the rental move we can not set the `reference` directly in the creation of the record as we used to do for its name since the compute method will then override and erase or reference.

opw-5385004

Forward-Port-Of: odoo/enterprise#101670

Before this commit, deleting a thread in a group chat could lead to the following crash:

```
Cannot read properties of undefined (reading '_proxy')
```

Steps to reproduce:
- install mail and im_livechat modules
- create a group chat (3 users minimum)
- create a subthread
- delete the subthread

This happens because when deleting the thread of group, there are the following side-effects:
- it deletes relation `parent_channel_id`
- deletion of `parent_channel_id` side-effects to delete subthread again (because deletion in relation may come from parent)
- deletion of subthread triggers deletion of members
- deletion of member deletes subthread.correspondent since this is being used.

While the subthread is being deleted, it's not technically deleted yet, as fields.onDelete() may still need to refer to this record. This is intentional design [1].

However there was a typo in code: code of deletion of record in relation this is being used assumes that the record using it is a proxyInternal, therefore the `proxyInternal[one] = undefined` was expected to work properly. However the deleting records were stored as raw record, and this mistakenly and actually assigned `undefined` instead of clearing the internal record list.

Because of this problem, any `Proxy.get()` on this relational field would trigger the crash above.

We could fix the PR with `_proxy` on deleting record, but to keep code as fast as possible, this commit instead retrieve the raw record in usingRecord instead, and apply the deletion on internal record list on the raw record. This works with reactivity because even when operations are done on raw record, the function `.delete()` and `clear()` on record list have dedicated implementation to properly make writes on `_proxy` thus notifying reactive change as expected.

[1]: https://github.com/odoo/odoo/pull/224912

Before this commit, when downgrading from 19.1 to 19.0 with chat hub data from 19.1, i.e. chat windows or bubbles that are open, loading web client would crash with following error:

```
KeyError: 'thread_model'
```

This happens because of mismatch of format of chat hub data in 19.0 and 19.1:

- 19.0 identifies channels with model "discuss.channel" and id
- 19.1 identifies channels with just id

When downgrading from 19.1 to 19.0, it attempts to getOrFetch a thread to server by providing channel id but without passing a model. The getOrFetch of 19.0 looks at thread level, so it cannot guess providing just id means a channel, therefore it crashes due to missing model to provide.

This commit fixes the issue by dropping the chathub local storage data if the format of chathub data in local storage is invalid, i.e. the identifying data of opened / closed should necessarily have id and model. If no model is provided like with downgrade from 19.1 to 19.0, then it drops local storage and assumes no chat window or bubbles is open.

Task-5223650

In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]

To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#101275
Forward-Port-Of: odoo/enterprise#99871

When importing a bank statements xlsx in a bank journal, the wizard would
not match the "Cumulative Balance", not even proposing it for manual setup.

Steps to reproduce:
- Go to the accounting dashboard
- On a bank journal tile, in the right corner menu "New > Import File"
- Upload a file (there is one attached to the ticket)
- Cumulative Balance is not matched

This commit adds module.init() that is skipped in the "onWillStart"
override (it's present in the parent onWillStart). This has for consequence
that the "bank_stmt_import" key is now present in the context when
get_fields_tree() from Base_ImportImport is called, allowing the addition
of missing field.
See https://github.com/odoo/enterprise/blob/19.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L18

This commit also adds a check to only add debit & credit in the added
field list if they are not actual field on the bst line model (see:
https://github.com/odoo/enterprise/commit/af863c5a53d0ab50fe67cb9ea910391d4a1979dd)
This commit also checks that those fields are only added when the model
is account bank statement line (only useful in this case).

opw-5222326

Calling Avatax without lines results in an error and blocks flows:

```
Odoo could not fetch the taxes related to MXXX - SOXXX/XXX.
Please check the status of `Sales Order XXX` in the AvaTax portal.
Transactions must have at least one line.
```

There are various cases this can happen:

1/ if `industry_fsm_stock` is installed, empty orders are confirmed [1],
2/ if you put the `end_date` of a subscription before the `next_invoice_date`,
   then none of the lines are considered invoiceable [2] and you get the
   error when viewing the subscription in the portal

This commit filters out orders without lines.

It's also possible to filter this on the level of the models by doing it in `_get_and_set_external_taxes_on_eligible_records()`. However, this means doing it separately for each model, and requires every implementer do it manually.

[1] https://github.com/odoo/enterprise/blob/703e7fd413e93a8287da98286aa93b9699ae3e96/industry_fsm_stock/models/project_task.py#L159
[2] https://github.com/odoo/enterprise/blob/c7bf4367a9bf6757a36a9f34a872a6e35a19a3a5/sale_subscription/models/sale_order_line.py#L475

opw-5214609
opw-5247727
opw-5311132
opw-5385960

Forward-Port-Of: odoo/enterprise#101643

## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Avoid payment wrong initialization when a default value has been set to initialize the `account.payment.register`. Indeed, the `account.payment` also has a `partner_bank_id` property, and so the method `_create_payment`of the `account.payment.register` can initialize payment with wrong `partner_bank_id`.

[enterprise#99373](https://github.com/odoo/enterprise/pull/99373)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`.

Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. 

## Tests
Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment).

Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error.

This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment.

[community#235475](https://github.com/odoo/odoo/pull/235475)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

This commit fixes three issues occurring when editing nested `s_card` snippets.

**Problem 1 - Incorrect cover image detection**

Issue: An `s_card` without a cover image displayed the cover image option if it contained a child `s_card` with a cover image.
Cause: The `querySelector` in `CardImageOption` could detect images inside child snippets.
Fix: Now the `querySelector` only searches among direct children of the snippet root element.

**Problem 2 - Ratio settings applied to all child cards**

Issue: Changing the cover image ratio on an `s_card` applied the setting to all nested cards.
Cause: The `we-select` in `s_card` options targeted `.o_card_img_wrapper`, causing the class to apply to all descendants.
Fix: The selector is now `>.o_card_img_wrapper`, so the option acts only on the current snippet.

**Problem 3 - Parent image positioning leaking to children**

Issue: Adjusting the cover image position on a parent `s_card` affected the rendering of all child card images.
Cause: CSS rules for `.o_card_img_horizontal` applied to all descendant elements matching `.o_card_img_wrapper`.
Fix: The rules now apply only to direct children of `.o_card_img_horizontal`. The same correction was applied to `.o_card_img_ratio_custom`.

task-5349540

**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).

**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line

**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').

opw-4948696

Forward-Port-Of: odoo/enterprise#95329

##  Steps to reproduce:

- Install 'website_crm_partner_assign' module.
- Create a partner X with a partner level.
- Save and go to "Opportunities".
- Create an new opportunity.
- Edit it and set the partner X as the assigned partner
- Grant the partner x portal access and change his password.
- Logout then login with the partner X credentials.
- Go to "My account" page and click on "Opportunities"
- Select the opportunity Y and edit the revenue or another field.
- Traceback on save. (Or no reaction, popup traceback from notification)

### Issue:
Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead.

### Solution:
To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead.

opw-2764563


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