Prior to this commit, the attribute previewer was not properly rendered on mobile in the "List thumbnails" and "List grid" product designs.

Also, since the attribute previewer was not updated when resizing the window in edit mode, it caused layout issues.

This commit updates the attribute previewer to ensure it renders correctly in all cases.

task-5016573

---

### Update attribute preview in edit mode
| | edit mode | normal mode |
|--------|--------|--------|
| 19.0 | <img width="1065" height="932" alt="Capture d’écran 2025-09-11 à 11 43 47" src="https://github.com/user-attachments/assets/33c3386e-c07b-4b60-bde5-69152c1b91c5" /> | <img width="1065" height="933" alt="Capture d’écran 2025-09-11 à 11 43 57" src="https://github.com/user-attachments/assets/9e046721-7afe-4109-8a2f-6168f5ada89e" /> |
| this branch | <img width="1346" height="975" alt="Capture d’écran 2025-09-11 à 14 48 35" src="https://github.com/user-attachments/assets/8166fbad-41ba-4bf1-9aff-78daf532f112" /> | <img width="1355" height="929" alt="Capture d’écran 2025-09-11 à 14 48 54" src="https://github.com/user-attachments/assets/61b3ad5a-bf15-43cf-8ab2-e04886d8b876" /> |

### Attribute preview in mobile

| | 19.0 | this branch |
|--------|--------|----------|
| List thumbnail | <img width="410" height="211" alt="Capture d’écran 2025-09-11 à 14 53 12" src="https://github.com/user-attachments/assets/c7cadadd-87dd-4e33-9d78-39027fd68602" /> | <img width="409" height="200" alt="Capture d’écran 2025-09-11 à 14 53 26" src="https://github.com/user-attachments/assets/9f938485-6421-453d-89fa-61cd0db26e72" /> |
| List thumbnail | <img width="818" height="386" alt="image" src="https://github.com/user-attachments/assets/ce87f4a1-9387-4cad-9098-0bb9ca085162" /> | <img width="406" height="178" alt="Capture d’écran 2025-09-11 à 14 54 29" src="https://github.com/user-attachments/assets/08496b4a-14c8-4090-85a5-db09dcf47bf0" /> |
| List grid | <img width="405" height="184" alt="Capture d’écran 2025-09-11 à 14 58 53" src="https://github.com/user-attachments/assets/ff10b4ce-8cb1-49c9-823e-34f354a25b81" /> | <img width="404" height="175" alt="Capture d’écran 2025-09-11 à 14 59 37" src="https://github.com/user-attachments/assets/eb01f787-17bd-4c02-b840-09d74b24a274" /> |
|List grid | <img width="409" height="159" alt="Capture d’écran 2025-09-11 à 14 59 57" src="https://github.com/user-attachments/assets/c6e73b57-eb02-4450-b52d-872aed179671" /> | <img width="408" height="144" alt="Capture d’écran 2025-09-11 à 15 00 07" src="https://github.com/user-attachments/assets/cce19acc-3d26-4ae4-8945-55025bc64490" /> |

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

Use correct domain to compute new orderlines upon clicking "Add All" from purchase catalog suggestion feature.

REASON: Typo in rush before freeze on which context to use: 
BEFORE: `domain = fields.Domain.AND([domain, self.env.context.get('domain')])`
AFTER: `domain = fields.Domain.AND([domain, suggest_ctx.get('domain')])`

Separated in 2 commits for review but they can be squashed on merge. 
Fixed typo above in first commit (along some other relevant changes) 
The second commit is just some unrelated cleaning up, and the following small changes:

- Moves In the order filter out of Good / Service filter group.
- Clamp suggestion percent factor between 0-999 (previously 0-inf)
- Removes the Activate text from the Suggest Toggle and cleans spacing.
- Put suggestion back on top of sections in SearchPanel (It was on top but then a PR for search panel sections inadvertently moved it below sections) 
- Change default suggest state to OFF (first time ever, afterwards state is saved/loaded from localStorage).

Original PR: odoo/odoo#218343 
Original task: task [#4783508](https://www.odoo.com/odoo/project/966/tasks/4783508)
Bug ticket: task [#5076240](https://www.odoo.com/odoo/project/966/tasks/5076240)

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

### Steps to reproduce:
- Install l10n_br_edi, switch to Brazilian company
- Set up Avalara
- Create an invoice with the tax "ICMS Exemption Incl." which is included in price
- Click "Generate taxes" to compute the taxes with Avalara
- In "Journal Items" we can see a line for "ICMS Exemption Incl.", its value appears as excluded

### Cause:
The result from Avalara included a value for this tax:
```
'tax': 1.44,
'taxImpact': {
	'accounting': 'none',
	'impactOnFinalPrice': 'Included',
	'impactOnNetAmount': 'Included',
},
```
But the untaxed amount is computed without this tax. Odoo keeps the untaxed amount from the response and add a line for the tax. As a result, the tax is added to the amounts like an excluded tax would.

### Solution:
In the response from Avalara, taxes with `['taxImpact']['accounting'] == 'none'` should be part of the accounting: no line should be created for this tax. So we filter them out in `_get_external_taxes`.

We also log these taxes in the chatter to keep a trace of them. As the parameter `'accounting': 'none'` is linked with the tax and not the line, if a tax on one line has `'accounting': 'none'` then the same tax will also have 'accounting': 'none' on all other lines. We use this to fetch all non accounting taxes, then we use the summary to construct the message like it was done before.

The logging in the bridge with pos needed to ba adapted because now the taxes may not be unarchived as they are ignored when they have `'accounting': 'none'`.

opw-4964315

## Versions:
16.0+

## Issue:
After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of all eligible ones.

## Cause:
When the SO is confirmed, the cost in points for each line is retrieved and deducted to compute remaining available points. However, when promotions are re-applied, the system re-evaluates the total cost of the SO and deducts the points again, effectively double-counting the same lines.

## Steps to reproduce:
- Set up a `Discount & Loyalty` promotion program:
  - 2 points granted per purchase (minimum $0).
  - Rewards:
    - 5% discount on "Simple Pen" (costs 1 point).
    - 10% discount on "Whiteboard Pen" (costs 1 point).
  - Create a Quotation with "Simple Pen" and "Whiteboard Pen".
  - Confirm the Quotation into a Sales Order.
  - Apply promotions:
    - The first reward applies correctly
    - The second reward does not apply

opw-4753472

Forward-Port-Of: odoo/odoo#226656
Forward-Port-Of: odoo/odoo#211342

In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations.

To reproduce the bug:
1- Create a db with, stock, mrp, sale installed.
2- Unarchive `MTO` route.
3- Set `Security Lead` Time in Setting.
4- Create two warehouses wh1, wh2.
5- In wh1, set `Manufacture to Resupply` to True.
6- In wh2, set `Manufacture to Resupply` to False and make it resupply from wh1.
7- Create a product and track inventory.
8- Create a BOM for the product.
9- Enable `Manufacture`, `MTO`, `wh2: Supply Product from wh1` routes for the product.
10- Create a new Quote for the product and in the Delivery, select `wh2` as the warehouse. Confirm the Quote.
11- Open MO. Security lead time is considered twice in dates calculations which is mistake.

To solve this issue, we must call `_get_dates_info` only once. The current condition might be True more than once for multiple moves. We should also check that it is not True for next moves which otherwise means the security lead time is already effected.

This issue is reproduced because this condition is not sufficient to ensure it is called once:
https://github.com/odoo/odoo/blob/c0a7b51c9e14d29cefa96c29dd716b7aec698818/addons/stock/models/stock_move.py#L1656-L1657

The above condition is written to ensure we are adding the delay only when move location is warehouse stock location.

This cause problem in multi-warehouse because we have this case that move location is warehouse stock location once for wh1 and once in wh2.

To solve this issue, we make sure the call `_get_dates_info` doesn't affect when the move has rules with src location in warehouse stock location.

related: #112325

opw-4889642

Forward-Port-Of: odoo/odoo#226712
Forward-Port-Of: odoo/odoo#224232

**Steps to Reproduce:**

1. Create DB in 18.0 with calendar module and google_calendar without demo data.
2. create a calendar event with videocall location other then odoo generated and mark that as guest_readonly.
3. after that  install appointment module and ``acces_token``.
4. upgrade to 18.3 below mentioned traceback will raise or can update to mail template.

**Issue**

why from 18.3 [from](https://github.com/odoo/odoo/commit/999df6d4a3b5d21648e5e09757661714e99e1154#diff-bd520efea06a5449c8694b54f5f7aa8587c929a5669ea0439bb9d5e38f8d29c8) this commit now template will render on record for checking.  During render checking the  ``videocall_redirection``  field value as it [compute](https://github.com/odoo/enterprise/blob/f5d99ea7ae7c2748c4a23a793c46ab1a123b3aad/appointment/models/calendar_event.py#L188) and non store field it going for compute over here the access_token is missing so it will go for compute and during that this [validation](https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/google_calendar/models/calendar.py#L106) is triggering and it breaking because env user is odoobot and user_id is different this issue occur during checking on write on mail template.

**Fix:**

 For fixing this checking is the fields syncable with calendar or not

```
 File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1751, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1914, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/saas-18.4/addons/calendar/models/calendar_event.py", line 696, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/saas-18.4/addons/mail/models/mail_thread.py", line 469, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/models.py", line 4620, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 207, in _compute_videocall_redirection
    event.access_token = uuid.uuid4().hex
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1847, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 246, in write
    res = super().write(vals)
  File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 96, in write
    self._check_modify_event_permission(values)
  File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 108, in _check_modify_event_permission
    raise ValidationError(_("The following event can only be updated by the organizer "
odoo.exceptions.ValidationError: El organizador es el único que puede actualizar el siguiente evento de acuerdo con los permisos del evento establecidos en Google Calendar.
```
opw-5042454
upg-3113613
TBG - 2082


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

Forward-Port-Of: odoo/odoo#226890

## **Issue Before This Commit:**
In the workcenter planning view, the total hours displayed were misleading,
as they always showed 24 hours of the day instead of the workcenter’s
defined working hours.
This caused confusion for users since the displayed total hours did not
match the actual available working time of the workcenter.

## **Steps to Reproduce:**
- Create a Manufacturing Order (MO).
- Add "Drawer" as the product.
- Add a "SEC-ASSEM: [FURN_8855] Drawer" BOM.
- Set the quantity to produce as 10.
- Confirm the MO and plan it.
- Open the planning view and notice that the total hours count
  incorrectly shows 24 hours instead of the defined working hours.

## **Cause of the issue:**
The bug was introduced by this PR (https://github.com/odoo/odoo/pull/205486),
as the related changes were not adapted here.
Because of that, pill.record.workcenter_id[0] returns an undefined value.

## **With This Commit:**
The calculation of total hours has been corrected to consider only
the workcenter’s defined working hours.
Users now see accurate hours in the planning view, making it easier
to plan and schedule work orders reliably.

task - 4900885

Forward-Port-Of: odoo/enterprise#93035

Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings.

**Steps to reproduce:**

- Install the `l10n_ec_edi_stock` module and switch to the `EC company`.
- Uncheck `Barcode Scanner` in the Inventory `settings`.
- Create a new warehouse and set the `Entity` and `Emission Point`.
- Navigate to Inventory > Operations > Deliveries and create a new delivery.
- Add details > mark as Todo > Validate > Generate Delivery Guide.

**Error:**
`AttributeError: 'stock.move.line' object has no attribute 'qty_done'`

**Root Cause:**
At [1], the code references `line.qty_done`, but this field is defined in the
`stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, 
the field is not available, leading to the `error`.

**Fix:**
This commit updates the delivery guide values to use `line.quantity` instead
of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3],
`qty_done` is derived from `quantity`.

[1]:
https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354

[2]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23

[3]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50

[4]:
https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165

sentry-6851008674

Forward-Port-Of: odoo/enterprise#93775

Issue Before This Commit:
============================
When only the quants/move line were changed without modifying the quantity,
the system automatically marked components as consumed (manual consumption
and picked boolean were set). This created confusion for the user since
no actual consumption took place.

Steps to Reproduce:
============================
- Install the `mrp` module.
- Create a tracked product (lot/serial) with quants.
- Create and confirm an MO having that product as a component.
- Change only the quants (e.g., location of the quant, not quantity);
  notice that manual consumption and picked boolean are set.

Cause of the Issue:
===========================
This issue occurs when clicking the 'Details' button (`action_show_details` 
method) on a stock move. That action passes the context `force_manual_consumption`, 
based on that which directly sets the `manual_consumption` and `picked` booleans in the 
`write` and `create` methods. [see](https://github.com/odoo/odoo/blob/master/addons/mrp/models/stock_move.py#L276).

With This Commit:
============================
Manual consumption and picked boolean are no longer set when only quants
(not quantity) are changed. Component consumption is now triggered only if
the quantity differs from the demand, ensuring consistency and avoiding
confusion for the user.

This fix avoids unintended behaviour by ensuring that the picked and manual
consumption booleans change only when the quantity differs from the demand.

TaskID:- 5062365

Forward-Port-Of: odoo/odoo#225386