Scenario:
- create an object_write (Update the Record) action
- update a field with equation evaluation (Python expression) with an
  expression like "record.id"
- click on "Create contextual action"
- go to a list view of the model, execute the action for several records

Result: the value of the field of all records are computed based on the
first selected record.

Issue: we don't change the "record" in the evaluation context and just
keep the first record.

Fix: changing the record.

Note: without the fix, the added test fails because the city of the
second record is set to the value of the ID of the first record.

opw-4491099

__PR code note__:

I did the change in "run" but this could be done in `_run_action_object_write`, I chose run because we are already changing the action_id in it.

The "`if eval_context.get('record') is not None`" is to not change an hypothetical case where `self.model_id` doesn't match the `context.action_model`.

__PR note__:

If it was too risky, we could probably merge in an higher version, the ticket is in 17.0 and this is still happening in master.

I've not heard of this issue before so this must not be very frequent or urgent, but I guess this is because people either use a python constant or they just use a python action with a for loop in general.

Forward-Port-Of: odoo/odoo#211122
Forward-Port-Of: odoo/odoo#210855

**Problem:**
When changing the price type of a Discount pricelist rule to 
"formula" and going back to the original price type "discount"
the rule does not take into account the base pricelist anymore
and uses the list price of the product to compute the discount

**Steps to reproduce:**
- Navigate to Sales/Products/Pricelists
- Create a new pricelist, click on Add a line
- In "Price Type" select Fixed Price and set a Fixed Price of 10
- Save and Close > create a second new price list
- Click on "Add a line" and select a Price Type Discount
- Set a 50% discount percent and select your first pricelist
as the base price (next to "on")
- Save and Close > save the form
- Open the rule again and change the Price Type to formula 
- Change the Price Type back to Discount and set a discount percentage
of 50% again
- Save and Close
- Create a new quotation with a product and select the second pricelist
you created > click on Update Prices

**Current behavior:**
 Amount is 50% of the price of the product 

**Expected behavior:**
It should be 50% of 10 because our second pricelist is based on the 
first one which has a fixed price of 10

**Cause of the issue:**
when _onchange_compute_price is triggeredwhen going back 
to discount value, base will be set to list_price
https://github.com/odoo/odoo/blob/d3e43681fd2b989ae7272731662cc3ac6a6d913b/addons/product/models/product_pricelist_item.py#L334-L342
because of this, the base price will not be computed based on the 
base pricelist 
https://github.com/odoo/odoo/blob/d3e43681fd2b989ae7272731662cc3ac6a6d913b/addons/product/models/product_pricelist_item.py#L580-L583

**fix:**
By resetting the base_pricelist_id, it's now visible to the user
on the form that the computation is no more based on a pricelist.
If the user enters a pricelist, the correct value will be computerd
for base and base_pricelist_id at that time.

opw-4757951

Forward-Port-Of: odoo/odoo#208899

**Steps to reproduce:**
1. Go to definition of default_website and add `<field name="configurator_done" eval="True"/>` .
2. install website module.

**Issue:**
Users are incorrectly redirected to the configurator screen instead of the website page. However, refreshing the page correctly redirects to the home screen as the server-side route is triggered on reload.

**Reason:**
The issue started in Odoo 16. Until Odoo 15, redirection to the configurator route is handled using ir.actions.act_url, which triggered a full page reload, ensuring the server route executed.
From Odoo 16 onwards, this action is removed, and a direct client action is attached. Within `configurator.js`, navigation is now handled using the `history.pushState` method which replace the current url and does not trigger a reload. As a result, even when navigating to the configurator route, the server route is not executed, leading to incorrect redirection.

**Fix:**
Added a check in configurator.js to verify the configurator status. If it is true, the user is redirected to the website page instead of the configurator. Otherwise, the normal configurator flow continues.

**Key Changes:**
1. In configurator_init, added a check: if configurator_done is True, set the default theme using button_choose_theme and store its result (a dict containing the next action to execute) as redirect_url.
2. In the Configurator component, added redirect_url to the store, and inside the onWillStart method, checked if redirect_url exists. If it does, redirect to the home screen using doAction.

This PR ensures the correct redirection behavior when users follow the Industries installation flow.

task-4555467

Forward-Port-Of: odoo/odoo#197593

Problem:
Adding a document when creating a new email template using `/media`
results in duplicated content on save.

Cause:
During HTML processing on save, `flattenBackgroundImages` wraps
elements with inline background images (`style*=background-image`)
in MSO-specific comments: `<!--[if mso]><![endif]-->`.

However, if multiple such elements are nested, they are each wrapped,
resulting in invalid nested comments and broken layout.

Solution:
Since the two conditions are opposites, we remove completely the content
of the nested comment if it has oppisite condition otherwise we just
remove the comment tags since they will be replaced with the upper
comment

Fixed in `web_editor` in https://github.com/odoo/odoo/commit/fcedeb63f5b5da6758e75d02f0c1d4f3b965adc1

Steps to reproduce:
1. Create a new email template.
2. Add a document using `/media`.
3. Save.
→ The content is duplicated or layout is broken.

opw-4775908

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

Forward-Port-Of: odoo/odoo#208788

- On a slow connection;
- In a list view (or a form view), click on a button (a view button);
- Make some changes and click on the Discard button;
- Make some changes in the main view.

Because the connection is slow, the main view reloads after the user has made some changes. This causes some issues, for example : the changes may be lost, editable list views may become uneditable, forcing the user to click again.

This happens because on the action service, the callback function (`onClose`) is called after the dialog is closed. In the case of a view button, the callback function will reload the main view.

This commit, is related to [1], in which an almost identical issue was resolved. The difference is that in previous commit the user clicked on the `Save` button in the dialog; whereas in this commit, it is the `Discard` button that is causing the issues.

This commit changes that order, we will wait for the execution of the callback to complete before closing the dialog.

[1] : https://github.com/odoo/odoo/commit/31c00161fd3a77c9fbd260754cb8c142fcb0d652

Forward-Port-Of: odoo/odoo#210521

The system raised a `psycopg2.errors.UndefinedFunction` error when attempting to compute a `SUM` on a `timestamp field (create_date)` in gamification goals. This is because PostgreSQL does not support `SUM(timestamp)` — `SUM` can only be used with numeric types such as integer, float, or monetary.

Steps to reproduce:
---
- Install `Gamification` and `hr_appraisal` modules
- Create a Gamification Challenge, and also create a Goal Definition and set `Computation Mode` -> `Sum`, `Model` -> `Appraisal Goal`, `Field to Sum` -> `Created on (Appraisal Goal)`, `Filter Domain` -> `[]`
- `Start Challenge` in Gamification Challenge

Traceback:
---
```
UndefinedFunction
function sum(timestamp without time zone) does not exist LINE 1: SELECT SUM("hr_appraisal_goal"."create_date") FROM "hr_appra...
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
```

To fix this, we now check the field type before applying aggregation. If the computation mode is set to `sum` but the field is not numeric, we gracefully fallback to using `count` instead. This prevents SQL errors and ensures that goal computations remain reliable even with misconfigured definitions.

sentry-6575130734

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

Forward-Port-Of: odoo/odoo#208077

### Steps to reproduce:

- Have 2 companies: COMP1 and COMP2
- Create a storable product P with a kit bom for attached to COMP1.
- With COMP2 create a delivery for 1 unit of P.
> If you click on check availability the move should not be assigned.
- As COMP1 and with COMP2 active, click on check availability once more
#### > The move is assigned.

### Cause of the issue:

Checking the availability will launch a call of the `action_assign` of the stock picking. During this call, the moves that shoudl by pass the reservation process will automatically be reserved: https://github.com/odoo/odoo/blob/9b0c1c416eaa0df64fbe28c5672f2590a218f315/addons/stock/models/stock_move.py#L1852-L1853 However, kit products are flagged to bypass the reservation process by these lines:
https://github.com/odoo/odoo/blob/9b0c1c416eaa0df64fbe28c5672f2590a218f315/addons/mrp/models/stock_move.py#L521-L522 The issue with this line being that the product is a kit form COMP1 and not for COMP2 (the context is used to determine this in the compute method):
https://github.com/odoo/odoo/blob/9b0c1c416eaa0df64fbe28c5672f2590a218f315/addons/mrp/models/product.py#L38-L40

### Note:

The issue can not be reproduced prior to 18.0, since the override of the `_should_bypass_reservation` was introduced by commit 4e1d46869e6c2d1ff473317179393007522a10a3

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

Forward-Port-Of: odoo/odoo#209900

The usecase occurs in x2many lists in form views. The total width of the table's parent div may change, for instance if a scrollbar appears on the sheet at some point. When this happens, the widths must be recomputed, to properly fit with the new available space. Before this commit, we only listened to window resize, not to the parent div itself.

This could lead to an horizontal scrollbar being sometimes displayed, for instance:
 - with the chatter below the form view, as it is loaded asynchronously, when it contains messages such that there's no (vertical) scrollbar before it is loaded, and there's one after.
 - with the document previewer, as its width changes when it is loaded.

This commit fixes the issue by using a resize observer to listen to the parent div directly, instead of on a window, which is more accurate.

Bug reported by our cto

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#210798
Forward-Port-Of: odoo/odoo#210366

Steps:
------
1. Create a combo product and make it available in restaurant
2. In PoS, add this product to an order
3. Click the product line, and set the quantity to 2 let's
4. Click split button, it takes you to the split screen

Observation: We can not select one of these 2 combos to split, it's either all of them, or none.

Reason:
-------
That's because combos are considered as non groupable in pos, see `is_pos_groupable` [1]. And then, when splitting a combo in `_splitQuantity` [2], we either take all the quantity or 0.

Fix:
----
We update the split logic to account for special combo cases.

[1]: https://github.com/odoo/odoo/blob/bee8b55d7783ea11f2362990cd9d7695b877b8e9/addons/point_of_sale/static/src/app/store/models.js#L829
[2]: https://github.com/odoo/odoo/blob/bee8b55d7783ea11f2362990cd9d7695b877b8e9/addons/pos_restaurant/static/src/app/split_bill_screen/split_bill_screen.js#L124-L127

opw-4737788

Forward-Port-Of: odoo/odoo#208679
Forward-Port-Of: odoo/odoo#208055

### Steps to reproduce:

- install fsm_industry
- run any of these tests:
    - test_change_parent_plan
    - test_change_parent_plan_conflict
    - test_change_parent_plan_with_intermediate
    - test_change_plan
    - test_change_plan_conflict
    - test_change_plan_no_conflict
#### > create access right error for the `account.analytic.line` model

### Cause of the issue:

The following three record rules provide the creation of `account.analytic.line` for users related to project or timesheet access rights unless the analytic line it self is linked to a project: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L52-L64 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L78-L83 Since the analytic module is unrelated to the project module, these tests will inevitably fail.

### Note:

These record rules do not stop the record creation once the account module is installed since the following record rules override the creation access rights for `account.group_account_invoice` users: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/account/security/account_security.xml#L102-L107

Similar issue treated in commit 9d164c1d2cd8e532109b9859ab776fcf2f71d115

### Note 2:

A priori, the same problem would occur if we were to write post install analytic tests for portal users:
https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L50

### Forward port additional fix (18.0):

Since Commit 0e997470b7174a187c876d734e38f633223f65ec the test  of the `TestAnalyticAccount` class are launched in sudo mode since the environment is set using OdooBot and never associated with an other user:
https://github.com/odoo/odoo/blob/ed38752e55d6bafbc71fac3df249f226a4eba332/odoo/tests/common.py#L979
https://github.com/odoo/odoo/blob/4baf55a5d108063b0b60beddf332b6ae367f1871/odoo/api.py#L568-L571
In 17.0 the environment was reset to a non sudo mode by the user  reassignement:
https://github.com/odoo/odoo/blob/d2ea23f252f0f8f329e2b0ff96de6ee2a14b922f/addons/analytic/tests/test_analytic_account.py#L28-L31
In order for the tests to also check access rights we have added our own `setup_independent_user` in the `AnalyticCommon` class.

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

Forward-Port-Of: odoo/odoo#210001
Forward-Port-Of: odoo/odoo#208978

In the Time Off app dashboard, employees can view whether some of their unused time off days are set to expire and the exact expiration date.

At the accrual plan level, a validity period can be defined for carried-over days, after which they expire. However, the expiration date of these carried-over days hasn't been considered when calculating the employee's expiring balance.

Steps to reproduce:  
1. Create a new accrual plan.  
2. Define a new accrual plan level.  
3. Configure the level to accrue 10 days annually.  
4. Set the carryover validity to 2 months.  
5. Keep all other settings as default.  
6. Create a new allocation.  
7. Apply the previously defined accrual plan.  
8. Set the start date to 01/01/20xx (where xx is the previous year).  
9. Confirm the employee's balance is now 10 days.  
10. Navigate to the dashboard.  
11. Set the date to 01/01/(20xx + 2), corresponding to the carryover date.  
12. Notice that no expiration date is displayed on the dashboard.  
13. The expiration date should be displayed as 01/03/(20xx + 2).

This update addresses the issue by incorporating the expiration dates of carried-over days into the calculation.

task-4207987

Forward-Port-Of: odoo/odoo#209992
Forward-Port-Of: odoo/odoo#181502

Before this commit, when a message has at least 1 reaction, using the quick reaction button in mobile displayed the emoji picker that shared the viewport of message list.

This makes it hardly practical.

This happens because the `useEmojiPicker()` in message reactions provide a ref, and this ref in mobile is used as a target to mount the emoji picker. This feature is useful for discuss composer to place emoji picker nicely under the composer input. In desktop the ref is used for click target of popover.

In practice the passing of ref in mobile is niche use-case: most of the time it should open in bottom screen as a dialog in a similar fashion as popover.

This commit fixes the issue by making 1st param of `useEmojiPicker` only act as the toggler part . In mobile to provide the container of emoji picker, one need to call `open(ref)` explicitly.

Task-4800688

From click there:
![Screenshot 2025-05-20 at 13 17 11](https://github.com/user-attachments/assets/40daf28b-bfe0-4c62-9385-b12d2d3264a0)

Before
![Screenshot 2025-05-20 at 13 16 43](https://github.com/user-attachments/assets/7719ef22-9aae-4fdd-90fb-89d19514125e)

After
![Screenshot 2025-05-20 at 13 15 56](https://github.com/user-attachments/assets/ee5bb01c-35f3-485d-987f-38add201dee1)

Forward-Port-Of: odoo/odoo#210802

Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB.

In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting indexes. The timing goes from minutes to seconds. The frontend is usable again.

Example of the data stored in the temp table:
```
=> select count(*) from analytic_temp_account_move_line
+----------+
| count    |
|----------|
| 60669759 |
+----------+
```

The example DB has 31 "plan columns". In other words we are duplicating 31 times 1957089 rows. That's too much data. It's also a waste of space and time. Especially if we later issue more filtering commands as the report is refined in the frontend. This leads to current approach being unusable for some clients. In the example DB the timing is bigger than the standard timeout for frontend requests.

Planning and execution of for the insert in the temporary table:
```
Insert on analytic_temp_account_move_line  (cost=0.86..6659742.75 rows=0 width=0) (actual time=209651.484..209651.487 rows=0 loops=1)
  ->  Subquery Scan on "*SELECT*"  (cost=0.86..6659742.75 rows=157594266 width=548) (actual time=644.693..92507.579 rows=60669759 loops=1)
        ->  Result  (cost=0.86..5083800.09 rows=157594266 width=548) (actual time=644.689..85762.552 rows=60669759 loops=1)
              ->  ProjectSet  (cost=0.86..1143943.44 rows=157594266 width=366) (actual time=644.657..72959.699 rows=60669759 loops=1)
                    ->  Merge Left Join  (cost=0.86..317844.46 rows=5083686 width=486) (actual time=644.562..22711.962 rows=1957089 loops=1)
                          Merge Cond: (account_analytic_line.move_line_id = account_move_line.id)
                          ->  Index Scan using account_analytic_line__move_line_id_index on account_analytic_line  (cost=0.43..97499.67 rows=1957619 width=150) (actual time=641.529..7738.521 rows=1957089 loops=1)
                                Filter: (general_account_id IS NOT NULL)
                                Rows Removed by Filter: 136994
                          ->  Materialize  (cost=0.43..144877.29 rows=2272735 width=344) (actual time=3.014..13564.293 rows=3022715 loops=1)
                                ->  Index Scan using account_move_line_pkey on account_move_line  (cost=0.43..139195.45 rows=2272735 width=344) (actual time=3.005..11312.577 rows=2274827 loops=1)
Planning Time: 132.775 ms
JIT:
  Functions: 78
  Options: Inlining true, Optimization true, Expressions true, Deforming true
  Timing: Generation 4.236 ms (Deform 2.533 ms), Inlining 64.617 ms, Optimization 351.121 ms, Emission 222.715 ms, Total 642.690 ms
Execution Time: 209672.536 ms
```

Planning and execution of a query based on the new view (note the usage of indexes from the actual tables):
```
Hash Join  (cost=72813.40..294958.00 rows=7724 width=4) (actual time=1760.970..3493.933 rows=61 loops=1)
  Hash Cond: (account_move_line.account_id = account_move_line__account_id.id)
  ->  Subquery Scan on account_move_line  (cost=72794.39..294349.71 rows=223360 width=8) (actual time=1725.998..3477.187 rows=246 loops=1)
        Filter: (account_move_line.analytic_distribution = ANY ('{1703,898,896,890,648,670,673,685,818,899,828,837,846,849,848,891,901,904,905,906,907,942,952,1039,980,985,1049,1050,1051,1093,1107,1114,1233,1126,1129,1133,1151,1152,1153,1222,1272,1218,1230,1243,1282,1249,1369,1271,1286,1328,1371,1396,1432,1403,1404,1406,1409,1430,1431,1437,1449,1473,1498,1515,1516,1517,1524,1525,1527,1528,1543,1549,1588,1592,1604,1605,1784,1641,1650,1652,1676,1677,1678,1679,1680,1702,1751,1759,1760,1767,1964,1796,1826,1832,1838,1926,1866,1883,1916,1922,1923,1954,1963,2144,1977,1974,2005,2011,2013,2015,2016,2032,2035,2037,2038,2064,2142,2097,2106,2110,2111,2112,2115,2121,2122,2130,2131,2141,2157,2311,2251,2252,2263,2269,2270,2271,2272,2274,2275,2279,2280,2287,2300,2307,2312,2316,2330,2339,2720,2370,2372,2423,2439,2462,2494,2477,2478,2480,2483,2491,2492,2493,2537,2533,2534,2535,2536,2546,2550,2551,2573,2574,2575,2576,2587,2598,2658,2691,2710,2721,2763}'::jsonb[]))
        Rows Removed by Filter: 2617642
        ->  Gather  (cost=72793.94..290647.16 rows=246807 width=910) (actual time=1720.216..3369.512 rows=2617888 loops=1)
              Workers Planned: 1
              Workers Launched: 1
              ->  Result  (cost=71793.94..264966.46 rows=4500611 width=910) (actual time=1706.592..2884.302 rows=1308944 loops=2)
                    ->  ProjectSet  (cost=71793.94..197457.29 rows=4500611 width=12) (actual time=1706.573..2654.189 rows=1308944 loops=2)
                          ->  Parallel Hash Join  (cost=71793.94..173865.38 rows=145181 width=132) (actual time=1706.560..2554.799 rows=42224 loops=2)
                                Hash Cond: (account_move_line_1.id = account_analytic_line.move_line_id)
                                ->  Parallel Index Scan using account_move_line__journal_id_index on account_move_line account_move_line_1  (cost=0.43..100906.82 rows=149368 width=4) (actual time=2.633..788.321 rows=126675 loops=2)
                                      Index Cond: (journal_id = ANY ('{23,21,17}'::integer[]))
                                ->  Parallel Hash  (cost=67363.05..67363.05 rows=354437 width=136) (actual time=1699.502..1699.503 rows=421304 loops=2)
                                      Buckets: 1048576  Batches: 1  Memory Usage: 54880kB
                                      ->  Parallel Index Scan using account_analytic_line__date_index on account_analytic_line  (cost=0.43..67363.05 rows=354437 width=136) (actual time=9.963..1507.693 rows=421304 loops=2)
                                            Index Cond: ((date <= '2024-12-31'::date) AND (date >= '2024-01-01'::date))
                                            Filter: ((general_account_id IS NOT NULL) AND (company_id = 3))
                                            Rows Removed by Filter: 57954
  ->  Hash  (cost=18.65..18.65 rows=29 width=4) (actual time=16.619..16.620 rows=29 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 10kB
        ->  Index Scan using account_account__account_type_index on account_account account_move_line__account_id  (cost=0.15..18.65 rows=29 width=4) (actual time=16.513..16.592 rows=29 loops=1)
              Index Cond: ((account_type)::text = 'income'::text)
Planning Time: 75.050 ms
JIT:
  Functions: 51
  Options: Inlining false, Optimization false, Expressions true, Deforming true
  Timing: Generation 4.433 ms (Deform 2.707 ms), Inlining 0.000 ms, Optimization 2.501 ms, Emission 30.127 ms, Total 37.061 ms
Execution Time: 3496.425 ms
```

OPW-4782916

Forward-Port-Of: odoo/enterprise#85942