[FIX] website: export image shape option plugin
In order to be patchable (in particular by design themes), the
`ImageShapeOptionPlugin` plugin has been exported.

Related to task-4367641
runbot-223813
runbot-223815


--------------------------------------------------------------------------------------------------------------------------------------------

[FIX] website: correct second argument of clickOnSnippet
This commit fixes a typo that appeared since [the website refactoring];
the second argument of `clickOnSnippet` has to be a string but was an
object.

[the website refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

Related to task-4367641
runbot-223813
runbot-223815

--------------------------------------------------------------------------------------------------------------------------------------------

[FIX] website: restore the way to compute and use snippetIDSelector
Since the [the website refactoring], the way to compute and use
`snippetIDSelector` has been modified for no good reason. This commit
reverts those changes.

[the website refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

Related to task-4367641
runbot-223813
runbot-223815

Here, when we try to open a report that is not linked to view, a traceback appears.

**Steps to reproduce:**
- Install the `stock` and `web_studio` modules.
- Navigate to `Settings > Technical > Actions > Reports`.
- Create a new report (e.g; **Model Name** = product.template, **Template Name** = product.report_test).
- Open the report in the web editor.

**Error:**
`ValueError: External ID not found in the system: studio_customization.studio_report_docume_product_label`

In this case, if no view is defined for the report, the system attempts to retrieve the related view from [1]. However, since the view does not exist, it raises a **ValueError**.

[1] - https://github.com/odoo/odoo/blob/924aa8aa2abe7765d2d605dc7643d1102e056fd6/odoo/addons/base/models/ir_ui_view.py#L2151

This behavior is already handled in **version 16.0** by [2] with a controlled exception. This commit adopts the same approach by raising **UserError** when no view is defined for a report, preventing an unhandled exception.

[2] - https://github.com/odoo/enterprise/blob/511781a6bfb52c88892a54e43133b90ddfddbe22/web_studio/controllers/report.py#L137-L143

Related Community PR: https://github.com/odoo/odoo/pull/208806

Sentry - 5715762959, 6303192517, 6577830303, 6577830303, 6577830303, 6303950186

**Current behavior:**
COGS dashboard items in a project's profitability report do not open any details when clicked on.

**Expected behavior:**
This should open a detailed view for an invoice linked via the analytic account on the project.

**Steps to reproduce:**
1. Create a service product that generates a project on sale, on the project template set a specific analytic account

2. Create another product with real time valuation and assign the COGS account on the product category's expense account

3. Sell some of the service product and the auto val product in the same order, deliver it -> generate invoice & post it

4. In the project's settings, open the profitability report and click on the `Cost of Goods Sold` dashboard item

**Cause of the issue:**
There is no action set up to return for this section, as it was just added in: 0fbc592

**Fix:**
Add an action to return the account move line records with COGS display type for the invoice record in question (in the request's `res_id`).

opw-4813885

Forward-Port-Of: odoo/odoo#212547

Before this **PR**:
When creating a new partner for the first time, the compute method for the invoice EDI format is triggered as expected. However, if a country is set while creating the partner, compute method is not triggered again.

This breaks the intended flow where a default edi_format should be automatically set based on the country (using _get_suggested_invoice_edi_format). Since the compute method doesn’t re-trigger upon changing the country during record creation, the inverse method ends up setting invoice_edi_format_store to 'none'. This prevents subsequent calls to _get_suggested_invoice_edi_format from resolving the appropriate format, requiring users to manually set it — defeating the purpose of automatic localization-based assignment.

After this **PR**:
The dependency for the compute method has been changed from commercial_partner_id.country_code to country_code. This ensures the compute method reacts to changes in the country field during record creation. The logic still utilizes commercial_partner_id internally, so the intended behavior and correctness should be preserved, while ensuring the default format is set appropriately.

Forward-Port-Of: odoo/odoo#212742

### Steps to reproduce:

- In the settings enable Multi-Step Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second Warehouse WH2
- Inventory > Reporting > Stock
- Click on the "Warehouse 2" of the left panel
> This updates the results
- Click on the wheel icon of the control panel > export All
#### > the values are exported for the commutative value of all warehouses

### Cause of the issue:

Click on a specific warehouse on the left panel actually updates the warehouse_id key of the context (on the listController). And this context is used to determine the values returned by the `web_search_read` performed on the `product.product` model. For instance the computed quantity fields are warehouse dependent:
https://github.com/odoo/odoo/blob/dba8ec896cc4d3cc93fc10f40c809a1ab863d46d/addons/stock/models/product.py#L131-L135 Now, the issue is that eventBus added by the list controller to export data's (and which needs to be initialised in the setup of the component as it setup hooks) is relying on the value of the context in the setup of the of the listController:
https://github.com/odoo/odoo/blob/dba8ec896cc4d3cc93fc10f40c809a1ab863d46d/addons/web/static/src/views/list/list_controller.js#L186-L188 https://github.com/odoo/odoo/blob/dba8ec896cc4d3cc93fc10f40c809a1ab863d46d/addons/web/static/src/views/view_hook.js#L126-L130 In particular, the parameter of the method will not be re-evaluated as `this.props.context` where this is the controller at the time of the callback the values of the export.

### Fix:

While the `env` provided at the initialization of the enventBus is a in the setup of the Controller is an immutable object, `env.resModel.root` correspond to the representation of the present record/records and hence carries the context of the current representation. It is therefore a valid object to rely on at callback time.

### Note:

The issue is not reproducible prior to saas-18.2 since the refactoring of the export system has been done in commit 1e4e40cf78fe8151dffdcb19df2688787084732c

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

Forward-Port-Of: odoo/odoo#210105

The adaptations from [1] and [2] added some code to the snippet preview
dialog, mainly to adapt text highlights in the snippets content
(starting from `18.0`) and enable the snippets preview interactions
(starting from `18.3`) [A].

In a runbot test context, the snippet selection happens too fast that
the code from [A] (linked to the async behaviour of `insertSnippets`)
can still process the snippets dialog `iframeDocument` (lost after the
dialog being closed on snippet selection).

The goal of this commit is to fix this behaviour by simply taking into
consideration the fact that the preview content can be lost (since in
a real use case, a user will select a snippet in a reasonable time).

[1]: https://github.com/odoo/odoo/commit/1aaf483c5d3b8e8816cfbea7da96ac007a42d492

[2]: https://github.com/odoo/odoo/commit/e008c92fcad2b8cc160586ba6ab94bc077b9bf3d

Remark: This commit will be adapted on `18.3` to fix the code from [2].

runbot-190596

Forward-Port-Of: odoo/odoo#210295

Currently, an exception is raised when validating a new receipt transfer where both the stock move and the push rule have the same destination location.

Steps to Reproduce:

1. Install `stock`  module
2. Enable Multi-Step Routes in Inventory
3. Routes -> Enable Warehouses and ensure they are linked to `YourCompany`.
4. Create a new rule for that route.
5. Set action to 'Push To' with same source and destination (e.g., WH/Stock) and Automatic Move to 'Automatic No Step Added'.
6. Go to Inventory -> Operations-> Receipts
7. Create a new receipt with the same destination location as defined in the rule.
8. Click on Validate

TypeError:
```TypeError
unsupported operand types in: stock.move() - None
```

This issue[1] occurs when the rule and stock have the same destination location. It does not execute and returns None, resulting in new_move being None. When `move.move_dest_ids - new_move` is executed, it raises an error.

[1]- https://github.com/odoo/odoo/blob/5c182227514af87659ee48360c63f33487de71bf/addons/stock/models/stock_move.py#L1048

sentry-6551676919

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

Forward-Port-Of: odoo/odoo#206850

### Description of the issue/feature this PR addresses:

When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. 

However, the current implementation does not properly handle this, with the default crone job running daily sending  email reminders up to one day late.


### Current behavior before PR:

Although the current implementation ensures the crone is not triggered for alarms of external-calendars-synced events, the default crone job that is running daily is going all over the events with reminders need to be sent and send them up to one day late.  

### Desired behavior after PR is merged:
When the crone goes to trigger the _send_reminder method, it will check first if the events are synced or not, and if synced then no reminders will be sent from odoo's side.




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


task-id: 4316693

Forward-Port-Of: odoo/odoo#211899
Forward-Port-Of: odoo/odoo#192876

When creating an inter-wh transfer, the replenish order was showing the product's supplier in the Received From (partner_id) field and not the correct wh.

Steps to reproduce:
-------------------
* In Inventory, activate Multi-step Routes
* Create a new WH that can be Resupplied From another WH
* On a product, in the Inventory tab, activate the Route 'ABC: Supply Product from XYZ'
* On the forecast of that product, click on Replenish
* Match fields: Warehouse = ABC, Preferred Route = 'ABC: Supply Product from XYZ'
* Confirm
* Open the generated order

> Observation:
> The field Receive From contains the supplier of the product instead of the supplying WH.

Why the fix:
------------
The supplier_id was automatically set with the product's supplier_id. It's not correct for every routes. It's now updated accordingly to the route used and if we need the vendor.

opw-4717654


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

Forward-Port-Of: odoo/odoo#212645
Forward-Port-Of: odoo/odoo#210336

Encountered an issue where `_name_search` would crash if a search term couldn’t be converted to all expected field types — specifically when using a string like "1971-01-01" that gets interpreted as a date, but also hits a float field in the comodel.

This happened when searching currencies by exchange rates, which involve both a date field (`name`) and a float field (`rate`) in `res.currency.rate`. The original implementation only caught `ValueError` during type conversion, but in my case it was raising a `TypeError` when attempting to convert a `datetime.date` to a float.

To fix this, I expanded the exception handling to also catch `TypeError`, ensuring `_name_search` gracefully skips over fields where conversion is invalid. This aligns with the intended behavior described in the original fix — to silently ignore incompatible fields instead of failing.

Failing in Distro Build , python version >=3.10  raises a `TypeError`
build_error-110207

Forward-Port-Of: odoo/odoo#212587
Forward-Port-Of: odoo/odoo#210551

…compute

**PROBLEM**
When creating a new operation type, changing the type to Delivery throws a warning to create a warehouse first despite there already being one.

**STEPS TO REPRODUCE**
1. On a fresh database, install stock with drop shipping and storage locations enabled.
2. Create a new operation type and set the type to Delivery.
3. You will receive the following warning, despite an existing warehouse:

```
Please create a warehouse for company <company>
```

**CAUSE**
https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock/models/stock_picking.py#L308-L316

https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock_dropshipping/models/stock.py#L70-L74

When the form is first loaded, the type is Receipt and the source location is consequently Vendors. After changing the type to Delivery, the source location is recomputed.

Observe the above code snippets. Before the source location is done being computed, the warehouse is accessed and computed. When computing the warehouse (in the midst of the source location compute), the `default_location_src_id` is still Vendors and `default_location_dest_id` is Customers, thus `warehouse_id` is set to False.

**FIX**
In the conditional that checks if the picking type is drop shipping, check the `code` instead. The value in `code` is up-to-date at the conditional, unlike `default_location_src_id`.

opw-4603495

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

Forward-Port-Of: odoo/odoo#199676

A series of recent commits were aiming at allowing to change the partner of some journal entries in batch to allow de-duplicating the database, in the context of the EC Saleslist report[^1]

There are a few residual issues:
1. the lock dates can prevent any change on the lines. However in this specific case, the partner is not really changing and we want to allow it. This issue is solved by adding a context key, using a sentinel to avoid any users bypassing it.
2. if the lines are reconciled, it was also impossible to update the lines. Since all the lines are changing the partner at the same time, there is no need to block changing it as the reconciliation keeps its meaning.
3. After the second commit, we were actually not checking that the VAT was indeed the same on the partner getting a `parent_id` assigned
4. We don't check that the user has a specific accounting group anymore to allow invoicing users to set the main partner. It should not be an issue since the accounting values stay the same (same VAT)

[^1]: https://github.com/odoo/odoo/commit/38d43360781250415c63aba36eadcdce586fcbc0
https://github.com/odoo/odoo/commit/3941972dc7bba3e9a3d4497b312ff7f86a497157

Forward-Port-Of: odoo/odoo#212990
Forward-Port-Of: odoo/odoo#212784

In version 18.0, a traceback occurs when editing the 'Appointment:
Attendee Invitation' email template and then signing up for an
appointment.

**Steps to reproduce:**
1. Go to **Appointments**.
2. Click the **"Action"** gear icon next to an appointment, then select **Edit**.
3. Navigate to the **Options** tab.
4. Hover over the **Booking Email** template and click the **arrow icon** to open
    it.
6. In the Content tab, add some text near "Hello", then click **Save**.
7. Return to the **Appointment form**
8. Click the "**Go to Website**" smart button at the top
9. Select a date and time.
10. Confirm the appointment.

This raises a traceback

**In saas-18.3**, editing the `Appointment: Attendee Invitation` email
template throws an error when saving, making the template uneditable.


**Issue:**

The issue originates from this [commit](https://github.com/odoo/enterprise/commit/8b9a1a4462453bf64e7bc1307ededd0d127a27fa), which introduced a
`<div>` inside a `<p>` — a structure that violates the HTML specification.
Editing anything near the word 'Hello' in the template causes the
`<p>` tag to close prematurely during rendering. This pushes the `<div>`
outside of the `<p>`, breaking the directive chain and resulting in
the following error:
     

> SyntaxError: t-elif directive must be preceded by t-if or t-elif directive

    
Previously, the `<div>` was also pushed outside the `<p>`, but only after
evaluating all `t-if, t-elif, and t-else` conditions. Hence, it worked
correctly without editing the template.


**Solution:**

Placed the `<span>` as a child of the `<p>` tag to resolve the issue.
    
This fix also resolves the issue of being unable to edit the template
"Appointment: Attendee Invitation" in the UI **on saas-18.3**.

[Task-4624645](https://www.odoo.com/odoo/project.task/project.task/4624645)

Forward-Port-Of: odoo/enterprise#85669

If one uploads a vendor bill from the list view using the "Upload" button, a banner is then shown on the form view of the created move to reload the data that were extracted via IAP.

However, this banner is not shown if one creates an empty move, then uploads via the attachments, then the banner is never shown.

This is because when we arrive in the `onWillStart` of the `StatusHeader`, we subscribe to a channel using the `extract_document_uuid` which does not exist upon creating a new empty move. Then, when we upload our document, the move record is saved, and is sent to the backend. At this point, the move exists, and a `extract_document_uuid` is set. Then we get the OCR results (in `_check_ocr_status`) and we have a new status, we send this status on the bus but on a channel named `f"extract.mixin.status#{self.extract_document_uuid}"` where the `extract_document_uuid` is set. However, in the JS part, it was empty because it was created in the `onWillStart`.

To resolve this, we create a new channel to detect newly created documents. We send the new `extract_document_uuid` in this channel from the backend to the frontend. The JS can now subscribe to the correct channel using an existing `extract_document_uuid`.

Now, correctly the JS receives the updates of the Python via the bus, and can update the view accordingly.

opw-4566944

Forward-Port-Of: odoo/enterprise#83522

Currently, when a user sends an article to the trash, the system triggers a notification email to relevant members informing them that the article has been trashed and will be permanently deleted in 30 days (see: `knowledge_article_trash_notification`).

This email includes a link to the trashed article (see: `article_url`). However, when a user clicks the link, they are taken to a 403 error page and cannot access the article to review or restore it.

Steps to reproduce the issue:
1. Open an article
2. Send the article to the trash
3. Open the notification email and click on the article link

=> The user is redirected to a 403 error page

When an article is trashed (see: `action_send_to_trash`), it is marked as inactive. As a result, it is excluded from ORM search results by default.

The `/knowledge/article/<id>` route uses the ORM to retrieve the article by its ID. Since trashed articles are inactive, the ORM does not return the article, leading the route to assume the article does not exist and redirect the user to a 403 error page.

To resolve this issue, we will modify the context of the search method to include the key `active_test=False`. This will allow the ORM to return inactive (trashed) articles. As a result, users who follow the link from the email will be correctly redirected to the trashed article page, where they can view its content and choose to restore it using the banner interface.

Task-4636494

Forward-Port-Of: odoo/enterprise#86065

The `action_timer_start` method caused infinite recursion when the user's timezone differed from the timesheet's timezone. The comparison between `fields.Date.today()` and `self.date` failed, creating a new timesheet.  That new timesheet triggered `action_timer_start` again, repeating the loop. 

**Steps to Produce:-**
1. Install the `Timesheets` application.
2. Navigate to `Settings > Users & Companies > User`.
3. Select your current user and, under `Preferences`, set the timezone to one that does not reflect today’s date.
4. Open the Timesheets application, and for any record, click on the `Search icon` in the column for today’s date.
5. Start the time tracking by clicking the `Play button`.
6. Wait for a moment; an error will generate.

**Error:-**
`RecursionError: maximum recursion depth exceeded.`

**Solution:-**
   - When action_timer_start() is invoked, it first checks for the _from_action_timer flag in the context.
   - If not set, it sets _from_action_timer=True.
   - The next time action_timer_start() is triggered, the presence of _from_action_timer in the context causes it to exit early, 
     preventing recursion.

**Sentry - 6592348827**

Forward-Port-Of: odoo/enterprise#85105

Currently, an error-level log is generated when confirming a Vendor Bill without setting the required AFIP Authorization Code.

**Steps to Reproduce:**
1) Install `l10n_ar_edi module`.
2) Select Company having Argentina code (e.g **(AR)Exento**) 
3) Navigate to `Invoicing->Configuration->settings`, under Argentina localization,
   set `Verify Vendor Bills validity in AFIP` to **required**.
4) Create a new Vendor Bill, select Vendor Name (e.g **ADHOC SA**).
5) Click on confirm.

**Error:**
UserError('Please set AFIP Authorization Mode and Code to continue!')

**Root Cause:**
- The code  calls `_logger.error(repr(error))` on any exception at [1] during the AFIP verification attempt, causing an ERROR‐level log entry.

[1]- https://github.com/odoo/enterprise/blob/ca16c89c6f53b1c0adb0a1a061d985bdf3439e5e/l10n_ar_edi/models/account_move.py#L500

**Solution:**
- This commit handles `UserError` exceptions separately using a warning log to prevent error-level entries.

Sentry-6576006813

Forward-Port-Of: odoo/enterprise#85261

#PURPOSE:
 - Currently is the user is promoted as admin for accounting and he/she is try
   to generate/regenerate or view the gst report following Error is thrown.
 - Access Error

    ```Uh-oh! Looks like you have stumbled upon some top-secret records.

       Sorry, Marc Demo (id=5) doesn't have 'read' access to:
         - Document (documents.document)```

#STEPS TO REPRODUCE
  1) Install necessary modules for indian accounting localization.
  2) Enable GST E-Filing & Matching Feature from account's configuration.
  3) Go to Settings -> User & Companies -> Users
  4) Click new if no user is there other then administrator else click on
     another user.
  5) Under Access Rights section , inside Accounting select Administrator & Save.
  6) Now log in as new user in another tab.
  7) Go to Accounting -> Reporting under 'India' section click on
     GST Return Period.
  8) Click on generate/regenerate or View option.
  9) The above shown error will be raised.

#SPECIFICATION:
- The issue is with documents access rights
- After promoting user to admin of accounting, the document's folder right is
  not properly assign to user.
- fix this by giving rights of GSTR folder to user if user is in accounting 
  manager group.
  
task-4770583

Forward-Port-Of: odoo/enterprise#86660
Forward-Port-Of: odoo/enterprise#84747

When Acerta Affiliation Number is unset and user tries to generate export file,
A traceback will appear.

Steps to reproduce the error:
- Install ``l10n_be_hr_payroll_acerta`` module and switch to belgian company
- Create an employee A > Create a contract(Status: Running) for that employee A >
  Details > Set Acerta code > save
- Go to Payroll > Configuration > Settings > Unset Acerta Affiliation Number
- Go to Payroll > Reporting > Export Work Entries to Acerta > New > Populate > Click on Generate Export File button

Traceback:
```
File "/home/odoo/src/enterprise/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py", line 45, in _generate_line
    return 'KLX1' + self.company_id.acerta_code + contract.acerta_code.zfill(20) \
TypeError: can only concatenate str (not "bool") to str
```

https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py#L45
When ``self.company_id.acerta_code`` is not set,
It will lead to the above traceback.

sentry-6620429585

Forward-Port-Of: odoo/enterprise#86098

Currently, an error occurs when updating data for payroll if a referenced partner record has been deleted by the user.

**Steps to produce:**
- Install the `contacts` and `l10n_ma_hr_payroll` module.
- Delete the partner **National Social Security Fund**.
- Navigate to `Settings > Technical > Scheduled Actions`.
- Run action manually for **Payroll: Update data**.
- Observe the error.

**Error:**
`ValueError: ParseError('while parsing /home/odoo/src/enterprise/saas-18.3/l10n_ma_hr_payroll/data/hr_salary_rule_data.xml:169 ...`

The error occurs because the method at [1] tries to load the `hr_salary_rule_data.xml` file, which references a deleted `partner_id` [2], resulting in a parsing failure.

[1] - https://github.com/odoo/enterprise/blob/b7c26a504264ee02ce40fc522faa2ef3624c9915/l10n_ma_hr_payroll/models/hr_payslip.py#L9
[2] - https://github.com/odoo/enterprise/blob/b7c26a504264ee02ce40fc522faa2ef3624c9915/l10n_ma_hr_payroll/data/hr_salary_rule_data.xml#L169

This commit ensures that all the referenced data is loaded properly, preventing errors due to missing references.

Sentry - 6617089492

Forward-Port-Of: odoo/enterprise#85979