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

Currently, an error occurs when a user tries to add multiple comma-separated new tags to a forum post.

**Steps to reproduce:**

- Install the `website_forum` module.
- Go to: `Website > Configuration > Forums`, create a new forum, then click `Go to Website`.
- Click on `Start by creating a post`, enter content, and set the `Tags` to `_test, retour affectif rapide`.
- Click on `Post Your Question`.

**Error:**
`ValueError: invalid literal for int() with base 10: 'retour affectif rapide'`

**Root Cause:**

After PR #169472, at [1], the code prepends an underscore (_) only to the entire input string instead of each tag. When multiple tags are entered, the backend receives a mixed list of values (e.g., ['__test', 'retour affectif rapide']), leading to an error during `int()` conversion at [2].

**Fix:**
This commit updates the `onCreateOption` logic to prepend an underscore to each tag in the comma-separated input,  similar to [3].

Also updated the test case at [4], to click `Create option` to save the tags.

[1]:
https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/static/src/js/website_forum.js#L54-L61

[2]:
https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/models/forum_forum.py#L304

[3]:
https://github.com/odoo/odoo/blob/ac93a25b216e6194895a64fe12c0d01f6833f743/addons/website_forum/static/src/js/website_forum.js#L69-L80

[4]:
https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/website_forum/static/tests/tours/website_forum_question.js#L34-L37

sentry-6761920887

Forward-Port-Of: odoo/odoo#227185
Forward-Port-Of: odoo/odoo#220058

Description of the issue this PR addresses:

Issue 1:

Steps to Reproduce:

- Open the website.
- Create a mega menu.
- Enter edit mode.
- Change the mega menu template to “Cards”.
- Click on any option available in the mega menu.
- A link popover will open.
- Click the Edit link button in the popover.
- Click the Apply button to save the link.
- A traceback occurs.

The error occurs because the text-wrap class is applied to the link. When the
hasColor method is triggered, it checks whether a.nav-link has a text color
class. However, TEXT_CLASSES_REGEX incorrectly matches text-wrap as a color
class. As a result, the removeColor method attempts to remove it and triggers
_applyColor to remove the color, but in _applyColor method it does not find any
color to remove on selected text. As a result, the removeColor process enters an
infinite loop, which eventually leads to a traceback.

Solution:

Update TEXT_CLASSES_REGEX so that it only matches valid text color classes and
excludes formatting classes such as text-wrap, text-center, etc.

Issue 2:

This commit ensures that the remove format action is disabled when a button
(.btn element) has custom color or background color applied.

Because buttons include padding, there is no proper way to remove a background
color from a partially selected button, so the action must be ignored in this
case.

task-5062715


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

Forward-Port-Of: odoo/odoo#226722
Forward-Port-Of: odoo/odoo#225477

Currently, an error occurs when user tries to select any measure in cohort view.

Steps to replicate:
- Install `sale_management` and `web_studio`.
- Open the Sales app and turn on studio mode.
- Under the Views tab, turn on cohort view.
- Under the Measures field, select any value and observe the error appearing in the terminal.

Error:
`ValueError: Invalid aggregate method 'None' for 'create_date:None'`

Cause:
- The Measure field dropdown in the Cohort Editor was mistakenly assigned the choices of `dateFields` [1] instead of `measureFields`.

- This allowed users to select incompatible field types (e.g., date/datetime), which lead to error in aggregation behavior in the cohort view.

Solution:
- Corrected the choices of Measure field to `measureFields`.

- Also added a condition to allow only those fields that have an aggregator
  (for some fields like `sequence` that dont have an aggregator).

- Also removed context field from arguments [2] in the rpc call as function doesnt need it [3]
  (This shows warning on runbot as well).

[1]: https://github.com/odoo/enterprise/blob/d8539dff5f3dcecfeb99fd7fc22a6915aaa02c4b/web_studio/static/src/client_action/view_editor/editors/cohort/cohort_editor_sidebar.xml#L30

[2]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/static/src/client_action/editor/new_view_dialogs/new_view_dialog.js#L87

[3]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/controllers/main.py#L805

sentry-6781792463

Forward-Port-Of: odoo/enterprise#94450
Forward-Port-Of: odoo/enterprise#91599

If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised.

Steps to reproduce:
-------------------
* Create a loyalty cards program
* Set company to the current company
* Create a branch company for the current one
* Switch to branch company
* Create a sale order, no need to add products, just a partner
* Try to confirm the order
> Observation: Access Error:
> Sorry, Mitchell Admin (id=2) doesn't have 'create' access to:
> -History for Loyalty cards and Ewallets (loyalty.history)

Why the fix:
------------
Here's where the access error is being triggered:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/sale_loyalty/models/sale_order.py#L106

Branches currently have access to the discounts & loyalty programs from the parent company, we extend the access to include loyalty history.

Another solution could be to create the loyalty history using sudo() if the coupon's program id is a parent of the current company.

opw-5055999

Forward-Port-Of: odoo/odoo#226226