# How to reproduce
- Create a new Journal
- Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account
- Go to the Transactions of the Journal
- Add a new Transaction for partner X and amount Y
- Add a second Transaction also for partner X and amount Y

# The issue
A popup appears that can never be saved

# Cause
When we click on "Add & New" or "Add & Close", we run the `validate()` function :

https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16

Which tries to do a model save, but it fails so it show the Form dialog :

https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163

The save fails because :
This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so :

https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385

https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245

But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once:

https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737

opw-6063654

Forward-Port-Of: odoo/enterprise#113358
Forward-Port-Of: odoo/enterprise#112750

**Steps to reproduce:**
* Install `account_iso20022` and `hr_expense`  module.
* Create an expense with `Paid by Company` and `SEPA credit transfer` as the payment method.
* Leave the `Vendor` field empty.
* Submit, approve, and post the expense.

**Observed behavior:**
* The expense is posted successfully without a vendor, creating a payment with `partner_id = False`.
* The payment cannot be reset to draft due to the missing vendor, and SEPA XML generation fails because the creditor name (`<Cdtr><Nm>`) requires a partner.

**Cause:**
* The `hr_expense` module overrides `_compute_show_require_partner_bank`. to set `require_partner_bank_account = False` for expense payments, bypassing the partner bank validation in `account.payment.action_post`.
* `_prepare_payments_vals` uses `self.vendor_id.id` for `partner_id`, which evaluates to `False` when no vendor is set.
* The `_post` method on `account.move` only validates partner presence for invoices (sale/purchase documents), not for `entry` type moves, which payments use.

**Fix:**
* Add a validation in `hr.expense.action_post` that checks whether the payment method is `sepa_ct`. If so, `vendor_id` must be set before posting.
* This catches the issue early in the expense flow, before the payment and journal entry are created.

opw-5930687

Forward-Port-Of: odoo/odoo#252384

Currently, in the mass mailing editor, an error occurs when a user replaces an image with an illustration.

Steps to reproduce:
1. Open the mass mailing editor
3. Drag and drop a snippet containing an image
4. Double-click on the image
5. In the image search bar, type "test" and press `Enter`
6. Select an illustration

=> A traceback is raised.

When an illustration is selected, it is automatically stored as an attachment with the mimetype `image/svg+xml; charset=utf-8`. The editor then loads the image using the attachment URL (e.g. `/html_editor/shape/illustration/usability-testingsvg-258?...`).

When the media dialog is closed (via `on_media_dialog_saved_handlers`), the editor attempts to process the image and calls the `/html_editor/get_image_info` route to retrieve the image info. This route retrieves the corresponding attachment from the database using the attachment url, but filters results based on a predefined set of allowed mimetypes.

The issue arises because this set does not account for valid mimetypes that include optional parameters such as `charset=utf-8`. As a result, the attachment is not found, preventing the image from being processed and ultimately causing the crash. To fix the issue, we will update the domain used to retrieve image attachments so that it accepts valid mimetypes with optional parameters (e.g. `image/svg+xml; charset=utf-8`).

During image processing, the transformed image is temporarily encoded in base64 and stored in the src attribute. When the record is saved, this base64 image is converted into a new attachment via the `/html_editor/modify_image/<id>` route. **This conversion step is necessary because many email clients have limited support for SVG images. Converting the illustration to PNG ensures better compatibility and visibility across mail clients.**

After conversion, the image url is then set to `/html_editor/shape/illustration/335/usability-testingsvg-258?...` This URL is handled by the `html_editor/shape/<module>/<path:filename>` route. Its purpose is to process SVG files and dynamically adjust their colors based on query parameters (e.g. the `c1` parameter).

However, once the image has been converted to PNG, this logic no longer applies. To address this, an additional conditional check will be introduced: if the file is not an SVG, the route will bypass the SVG-specific transformation logic and instead serve the image directly.

Task-5977962

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

Forward-Port-Of: odoo/odoo#255134

### [FIX] website_sale: keep preview data of dynamic category snippet

Commit 08c41255d70ccbb35eff20e0a12671ffdfba3dfe loads the interaction for dynamic category snippet to show its dynamic content in snippet preview dialog.

Commit 5cd8ba3b5abcad5a119bb879a9892e0bcfe27d9f changed the condition to avoid replacing the preview data.

The dynamic category snippet's preview data does not have the class `s_dialog_preview` to mark them as preview data. Thus the interaction was started and cleared the content (but could not fill it as the snippet does not have a valid configuration yet).

This commit uses a `html_builder.snippetsPreprocessor` to add the class on the preview data of that specific snippet in the loaded snippets.

Steps to reproduce:
- Open website builder
- Click on "Catalog" snippets category
- Bug: the dynamic snippet containing categories is missing its preview data part

task-6088029

### [FIX] website_sale: scale down height of dynamic category snippet's item

Commit 08c41255d70ccbb35eff20e0a12671ffdfba3dfe enables preview of custom dynamic category snippets.

But the height of the item is not adapted to the downscaling of the iframe. Thus they looked 3 times too tall.

This commits adds a patch to the interaction when loaded in this context to adapt the computed value for the height.

Steps to reproduce:
- Open website builder
- Click on "Catalog" snippets category
- Add the dynamic category snippet
- Select the added snippet
- Save this snippet as a custom snippet
- Click on "Custom" snippets category
- Bug: the items int the snippet looks way too big

task-6088029

Forward-Port-Of: odoo/odoo#257026

Steps to reproduce:
1. Create a currency with a non-1 exchange rate with the company's
currency (e.g. VEF with a rate of 0.000005 against USD).
2. Create a pricelist in that currency.
3. Create an event.
4. Create a sale order with the new pricelist.
5. Add a sale order line with a ticket of the event and confirm
the order.
6. Go to the event's page and check the total sales smart button.
7. Check the total sales of the event: it should be equal to the sale
order's total price converted to the company's currency, but it is not,
because of the wrong conversion (it used the inverse of the correct
exchange rate, which is 200000 instead of 0.000005 in our example).

Problem:
The total sales smart button in an event's page shows wrong totals when
sales are in a currency other than the company's currency.

Cause:
The code converts the sale price from the event's currency (which is the
same as the company's currency) to each sale order's currency, while it
should be the other way around (from each sale order's currency to the
event's currency).
https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38

opw-5494790

Forward-Port-Of: odoo/odoo#258000
Forward-Port-Of: odoo/odoo#253605

### Issue:

In certain flows, basic mrp users (mrp.group_mrp_user) can not mark MO's as done or split production due to the associated automatic creation of accounting analytics.

As concrete examples, the tests:
- test_automatic_backorder_no_redirect
- test_change_qty_produced can not be performed with a user with basic mrp access rights.

### Steps to reproduce:
- Incarnate a user with only mrp user rights
- Create and confirm an MO for 2 units with an operation
- Click on the cog wheel icon > Split production > split
#### > Access Error: You are not allowed to access 'Analytic Line' (account.analytic.line) records.

### Cause of the issue:

To begin with, members of the `mrp.group_mrp_user` do not and should not have read nor create access rights with respect to the `account.analytic.line` model. However, as soon as `mrp_account` is installed the `button_mark_done` can end up requiring such access.

1. The `_split_productions` fails for multiple reasons:

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2000 fails because of the assignment since this call:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L27-L35 requires write and read access on the `account.analytic.line` model.

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2002 fails because the `copy_data` now checks that the user has the `read` access rights of the comodel when copying `many2many` data's: https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/odoo/orm/models.py#L4781-L4783 This is an issue for instance for the `wip_move_ids` field that can not be copied since mrp users do not have a read access to the `account.move` comodel:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L15

This line:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp/models/mrp_production.py#L2017 will fail since it checks the read access right on the comodel `account.move` of the `wip_move_ids` fields.

2. The `_post_inventory`:

https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L2221 Fails as it sets the duration:
https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L1922 which calls the `_create_or_update_analytic_entry`: https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp_account/models/mrp_workorder.py#L18-L21 which it self creates and update `account.analytic.lines` to which you do not have any read access.

backport of b5c7d5fed2d893bcd5ea2c2c5ed1cb9d8dfa2424

opw-6066674

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

Forward-Port-Of: odoo/odoo#257350

[FIX] html_editor: undo link autoconvert before space insertion

When adding a space after an URL, the URL text is converted to an URL.
When pressing undo, first the space is undone, then the link is undone.
This is wrong because if the user did not want a link, after undoing the
link, inserting a new space will again convert to a link.

This commit splits `handleAutomaticLinkInsertion` into two parts:
determining if a link must be created, and actually inserting the link.
This makes it possible to execute code within the condition before and
after the insertion.
To fix the similar behavior for enter and shift-enter, another before
input handler is also added in order to let the default before input be
executed before creating the link.

Steps to reproduce:
- Go to a "To do" note
- Type "odoo.com"
- Press space/enter/shift-enter
- Undo a single time

=> The insertion was undone instead of the link transform.

task-5936310


[FIX] html_editor: not include surrounding backtick in pasted URL

When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF.

This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`).

Steps to reproduce:
- Copy the following text in the clipboard:
```
`odoo.com`
```
- Go to a "To do" note
- Paste

=> The link's URL was
```
odoo.com`
```

task-5936310

Forward-Port-Of: odoo/odoo#258337
Forward-Port-Of: odoo/odoo#248619

Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation.

## Steps to replicate:
- Install Sales, CRM, and Inventory.
- Create a new Warehouse and move it to the first position in the warehouse list view (highest priority).
- Archive the newly created warehouse.
- Navigate to Contacts > Acme Corporation > Opportunities >Office Design Project
- New Quotation > Other Info > Delivery and check the Warehouse field.

## Observed behavior
The archived warehouse is still assigned to the Warehouse field in the Delivery section. This issue does not occur when the user creates a quotation directly from the CRM app, it only happens when the quotation is created through the Contacts apps.

## Root cause:
This unintentional behavior was introduced after commit [1]. When a user opens 'Opportunities' from the contacts view, the function `action_view_opportunity` [2] is triggered, which sets `active_test` to False in the context.

Later, when a new quotation is created, the compute method [3] is executed. This method calls `_get_default_warehouse_id` [4], which performs a search. Because `active_test` is already set to False in the context, the search also includes archived warehouses, causing them to be fetched unintentionally.
[2]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/crm/models/res_partner.py#L39-L53 [3]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/sale_stock/models/sale_order.py#L194-L204 
[4]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/stock/models/res_users.py#L9-L12

## Solution:
Explicitly set `active_test=True` in the context when preparing the quotation for an opportunity. This ensures that archived warehouses are excluded from the search and prevents them from being selected.

**Alternate Solution:**
We could also make `active_test` to true when searching for warehouse directly as well.
```py
 def _get_default_warehouse_id(self): 
     # !!! Any change to the following search domain should probably 
     # be also applied in sale_stock/models/sale_order.py/_init_column. 
     return self.env['stock.warehouse'].with_context(active_test=True).search([('company_id', '=', self.env.company.id)], limit=1)
```
[1]:
https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 

opw-5999034

Forward-Port-Of: odoo/odoo#252166

Steps to reproduce
1. Create a to-do from the To-do app (no project set, appears as "Private")
2. Open the Project app, go to My Tasks, open the to-do
3. The "Private" label shows correctly
4. Refresh the page

Issue
After refresh, the "Private" label vanishes and the project field becomes required (red), making the record unsavable.

The web client merges (ORs) the `required` attribute of fields sharing the same name across view nesting levels. Commit 46adf760a3a33 introduced `required="1"` on the sub-task `project_id` inside the `child_ids` One2many list: https://github.com/odoo/odoo/blob/46adf760a3a33e48d34fe99c565a8c6c1194fb65/addons/project/views/project_task_views.xml#L479

This causes the main form's `project_id` required expression (`parent_id or child_ids or is_template`) to be ORed with `1`, always evaluating to true. On initial navigation the sub-task list is not yet loaded so it works, but on a full page refresh all field attributes are merged at once, making the main task's project field unconditionally required.

Solution
Change the sub-task's `project_id` required expression to `parent_id or child_ids or is_template`, matching the main form's field. This still evaluates to true for sub-tasks (they always have a `parent_id`) while no longer forcing true on standalone to-dos that have no project.

opw-6008266

Issue:
--
The query created by the function '_compute_sale_order_ids' takes
around 20-40 seconds since its doing "WHERE" searches on millions
of stock.picking records

Fix:
--
Added an index to the "lot_id" field of the stock.move.line model.
(Already existing databases can be fixed by using the webshell)

Steps to recreate the issue:
--
1. Have around a million stock.picking records
2. Go to "Inventory/Products/Lots/Serial Numbers"
3. Select any existing record or create and save a new one
4. These actions will take around 20-40 seconds to complete

Before this commit:
--
Selecting or saving any 'stock.lot' takes around 20 seconds

After this commit:
--
Selecting or saving any 'stock.lot' takes around 1-4 second

Benchmark:
--
Benchmark test was done one a database with ~4000 stock.move records and
1.74 million stock.picking records
Opw-5459842
| Before this Commit | ~20 seconds
| After this Commit | **~1-4 seconds & Memory usage just a little bit higher

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

Forward-Port-Of: odoo/odoo#255255

Currently, payments may remain in the 'in_process' state even when the
associated vendor bills are fully paid. This occurs primarily when using
early payment discounts (EPD) and journals without outstanding accounts.

Steps to reproduce:
- Create an early payment term.
- Create a Vendor Bill with EPD and post it.
- Register a payment for this bill (no outstanding account set on
  journal => no move created).
- Create a bank transaction fully paying the bill.
- Reconcile the transaction with the bill.

Issue: Access the payment of the bill. The payment state remains
'in_process' instead of 'paid'.

Analysis: The issue occurs because the reconciliation process misses the
trigger to set the payment state to 'paid'. Specifically:
- The payment amount does not match the bill total due to the EPD.
- The payment compute method does not monitor 'reconciled_bill_ids',
  causing it to ignore the status of linked vendor bills.

This change adds 'reconciled_bill_ids' to the compute dependencies and
ensures that if a payment is reconciled with any moves (invoices or
bills), their payment_state is considered to determine the final state
of the payment.

Test in enterprise: https://github.com/odoo/enterprise/pull/112398

opw-5881976

Forward-Port-Of: odoo/odoo#256486

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/dfe248143f [REL] 19.1.14 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4ffd4dcb57 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/8e47b01f6f [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/ac3c47f78a [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/80781d1730 [FIX] zoom: gauge chart rendering with zoom [Task: 5942124](https://www.odoo.com/odoo/2328/tasks/5942124)
https://github.com/odoo/o-spreadsheet/commit/45a6362d99 [FIX] uuid: remove useless `require` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1832943a61 [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092)
https://github.com/odoo/o-spreadsheet/commit/aa16066e98 [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3dd022cec7 [FIX] spreadsheet: chart side panel content should use full height [Task: 6080680](https://www.odoo.com/odoo/2328/tasks/6080680)
https://github.com/odoo/o-spreadsheet/commit/053f945858 [FIX] xlsx: export formula that returns an error [Task: 6008904](https://www.odoo.com/odoo/2328/tasks/6008904)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Before this commit, when in inbox mobile and scrolling & swiping on inbox notifications, the message actions was displayed at the same time.

Steps to reproduce:
- have Admin with "Handle in Odoo" Notification preferences
- have some messages in Inbox (e.g. receive @ mentions from chatter)
- open Inbox in Discuss app in mobile, and scroll up / swipe horizontally on each message

=> this opens message actions in bottom sheet

This happens because when scrolling up/down or swiping left/right on a message, this is triggering a longpress. The longpress has some dedicated code to detect that there's no scrolling or swipe at the same time, however since 1 the action swiper was changed and made this regression. This happens because 1 introduced some
`ev.stopPropagation()` on touch event, which are crucial for the hook useLongPress() to determine whether a scroll or swipe is occuring. Because the events have been stopped, the useLongPress() wrongly assumes the user triggers a long press.

One could think we could use capture in useLongPress(), which is generally the way to prevent this issue. However, ActionSwiper is stopping propagation at the capture mode, therefore giving no chance for useLongPress() to detect the touch events.

Thankfully the capture event listener target is the `ActionSwiper` itself, so one solution is to register in capture mode in a broader scope like `window`. This commit fixes the issue by registering on `capture` of the touch event on `window` for `useLongPress()`.

Task-6008171

Scroll up in inbox, Before / After:
![before](https://github.com/user-attachments/assets/14453752-e6bb-41ed-8947-969680222588)
![after](https://github.com/user-attachments/assets/5bc5ce81-4088-4b37-bb37-c18ffd2d5da7)

Steps to Reproduce:
-
1. In the Project app, create a new project and enable "Timesheets".
2. Create a parent task with allocated hours (e.g., 20h).
3. Create one or more sub-tasks under the parent, also with allocated hours (e.g., 8h and 5h).
4. Log in to the portal and navigate to the project's task list.
5. Observe the "Total" allocated time shown in the list header.

Issue:
-
- The total allocated time displayed in the portal incorrectly sums the hours of the parent task and all its sub-tasks (e.g., 20h + 8h + 5h = 33h). This leads to an inflated and confusing total for the customer.

Cause:
-
- The `_get_portal_total_hours_dict` method calculated the sum of `allocated_hours` on the entire recordset of tasks passed to it, without distinguishing between parent tasks and their children when both were present.

Fix:
-
- This commit excludes sub-task hours from the total allocated time computation if their parent task is also present in the view.
- The total time spent now uses parent `total_hours_spent` which includes both time spent on parent and sub-task.

task-4939234

Forward-Port-Of: odoo/odoo#258485
Forward-Port-Of: odoo/odoo#221563

When buttons (`a.btn` elements) are translated inline, or badges (`span.s_badge`), the background color that shows the status of the translation appears under the background of the button/badge. The status is thus only visible on the surrounding text, and completely invisible when the button is alone (unless it has a transparent background).

This commit adds a plugin in translate mode which adds a span with the color of the translation status in the problematic elements if they are inside a translation span and have a background color.

Steps to reproduce:
- Open website builder
- Drop the `s_banner` snippet (or add a button by typing `/button`)
- Add a second language
- Open in translate mode
- Bug: the text of the button does not have the green/yellow highlight that shows the translation state (technically, it is hidden under the background of the button, which you can see if you set a transparent background on the button)

`o_translate_inline` on links:
  - 8fe88de0d5cc61395721cd8bda7b7ef2ea961760
  - f65ac79631180e77aca5a53fc557b3e1acfcbd65
  - 6aef5ee411656ec400e92fcc2bbd62e420645e0e

task-6038029

Forward-Port-Of: odoo/odoo#258203
Forward-Port-Of: odoo/odoo#254000

### Issue before this commit:
After generating a stock valuation closing entry from the Inventory Valuation report, reopening the report raised an access rights error. Users with Accounting permissions could no longer access the report.

### Steps to reproduce the issue:
1. Access the database with a user having Accounting Admin rights.
2. Go to the Inventory Valuation report.
3. Click to generate a closing entry.
4. Try to open the Inventory Valuation report again.
5. Result: System shows an access rights error.

### Cause of the issue:
The method _get_last_closing_date() retrieves the field state of the model account.move by querying the technical model ir.model.fields. However, accounting users do not have read access to this model. When the report tries to compute the last closing date after a closing entry exists, this lookup triggers an error.

### Reason to introduce the fix:
The lookup of account.move.state is only used internally to inspect tracking values in the chatter and determine the posting date of the closing entry. Since this requires reading a technical metadata model, the query is executed with sudo() to bypass the restriction while keeping the functional access to accounting data unchanged.

opw-5998151

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

Forward-Port-Of: odoo/odoo#254188

Example of steps:
- Install todo module
- Create a todo task (it will be created without project_id)
- Go to project -> my task
- You can see your previously created todo task (with project set as)
- This todo task is marked as Private (since no project)
- Refresh page
- There is now an error because project is now required and you cannot save the current task

This problem is caused by `addFieldDependencies` from `relational_model/utils` Let's simplify the case with this view for example:

```xml
<form>
    <field name="foo" widget="my_widget"/>
    <field name="name" />
    <field name="child_ids">
        <list editable="top">
            <field name="foo" widget="my_widget"/>
            <field name="name" required="1"/>
        </list>
    </field>
</form>
```
my_widget is defined with these fieldDependencies:
```js
[
    {
        name: "name",
        type: "char",
    }
]
```
We have twice the same group of fields (name + foo with my_widget), one in the form view and the other one in the subview list (child_ids).

Currently, we firstly process subviews in `addFieldDependencies`. As "name" field is used in dependencies of `my_widget` and name is already use in the same view (subview list) with required="1" we will change `my_widget` dependencies to be required too by mutating `widget.fieldDependencies`.

And after, we will do the same with the main form view, but as fieldDependencies object from fieldInfo is the same for every instances of the widget everywhere (from form arch parser), we should not alter it because we might accidentally add attributes to certain fields (for example, in our case, making the “name” field in the main view required when it shouldn't be).

This commit fix this case by using a spread operator to shallow copy fieldDependencies items.

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/4561a9a809 [REL] 19.0.29 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/cd7707f944 [FIX] format: keep negative accounting suffix in large number [Task: 6068834](https://www.odoo.com/odoo/2328/tasks/6068834)
https://github.com/odoo/o-spreadsheet/commit/f7b1c449c8 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/46c70d8670 [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/bd47b32e9e [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/bfb8e0595f [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092)
https://github.com/odoo/o-spreadsheet/commit/aee92bcbdd [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/f5e1d32287 [FIX] spreadsheet: chart side panel content should use full height [Task: 6080680](https://www.odoo.com/odoo/2328/tasks/6080680)
https://github.com/odoo/o-spreadsheet/commit/89c8b30ee2 [FIX] xlsx: export formula that returns an error [Task: 6008904](https://www.odoo.com/odoo/2328/tasks/6008904)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Forward-Port-Of: odoo/odoo#258579

**Description of the issue/feature this PR addresses:**
The `Store.getMentionsFromText` method fails to identify mentions for users with special characters (&, <, >) in their names. Because the function processes raw HTML, these characters are encoded as entities, causing them to be [filtered out](https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/mail/static/src/core/common/store_service.js#L599-L601)

In order to resolve this, I translate the entities back into their normal representation, allowing our includes to find them.

**Steps to reproduce bug:**
1) Create a user with a name containing &, <, >
2) Set it so they receive emails for notifications
3) Mention them in a long note
4) Observe that no email is sent

**Current behavior before PR:**

https://drive.google.com/file/d/1itBlz6havFmFi2G3mbOm3qh2_WH6uM76/view?usp=drive_link

**Desired behavior after PR is merged:**

https://drive.google.com/file/d/1PC2_hjBAhhC6ZSOEzs9SPYjSHrZbaplp/view?usp=drive_link

opw-5895188

Forward-Port-Of: odoo/odoo#249350