**PR Description:**

- Replace public widgets for portal subscriptions with new Interaction alternatives.  
  This continues the refactoring work for public widgets.

**Steps to Reproduce the Features:**

- **SubscriptionChangePlan:**
  - Log in as an **Admin**.
  - Navigate to the **Subscriptions app** and open a subscription with a recurring payment.
  - Modify the **Self-Service** section of the subscription plan to include an optional plan  
    (e.g., update "Monthly" to include "Yearly" as an option).
  - If the modified plan isn’t available on an existing subscription, create a new subscription for a **portal user**.
  - Log in as the **portal user** and open the subscription with the modified plan.  
    (Alternatively, you can preview it as an **Admin**.)
  - The **Change Plan** button should appear.  
    To test the feature, append `&change_plan=true` to the URL.

- **SubscriptionCloseFinish & SubscriptionCloseSelect:**
  - Navigate to **Subscriptions app** → **Configuration** → **Recurring Plans**.
  - Create a new plan or modify an existing one.
  - In the **Recurring Plans** form, enable the **Closable** option under the **Self-Service** section.  
    This allows customers to close their own subscriptions via the portal.
  - Open any subscription and click **Preview**.
  - The **Close Subscription** button should now be visible on the left.  
    Clicking it will trigger the two widgets.

Description
-----------
The non-stored field `user_has_access` is the primary `ir.rule` used for a `knowledge.article` and is included in every query. As a result, the method `_search_user_has_access` is frequently called and quickly becomes a performance bottleneck. This is particularly noticeable when opening the Knowledge app, as it involves reading the displayed article along with loading the sidebar.

This update optimizes the method as follows:

- For generic article access, the optimization leverages the field `inherited_permission`, which already contains the propagated `internal_permission` of the article along the hierarchy. This removes the need to recompute these permissions dynamically with a complex query since the data has already been precomputed.
- For member access, the query logic has been revised while maintaining the same outcome: Previously, the process involved: `for all articles, append the member and their permission, recurse into child articles for all in-sync and permissionless articles, and propagate the member's permission. Finally, discard all articles without any set permission.`, The new approach reverses the logic to avoid the need for discarding at the end and iterating through all articles: `for the articles the member belongs to, propagate the member's permission to its child articles, provided the child is in-sync, has no explicit permission, and the partner is not already a member of that article.` Although the last condition may seem counterintuitive, the initial set of articles considered encompasses those the member is linked to already. This also avoids cases where a parent article's member permission would overwrite differing permissions on its child articles.
- Additionally, `set` manipulations are used to handle IDs, thereby preventing the injection of large ID lists into multiple domain leaves. This improves query parsing and avoids poor query execution plans that could be caused by excessively large ID lists.

Benchmark
---------
On odoo.com, opening the Knowledge app from the Apps dashboard:

| Request              | Before | After | Speed-up |
|----------------------|--------|-------|----------|
| web_read             | 1.69s  | 160ms | **10x**  |
| get_sidebar_articles | 1.64s  | 160ms | **10x**  |

In a shell, searching articles with `[('user_has_access', '=', True)]`:

| User Type             | Before | After | Speed-up |
|-----------------------|--------|-------|----------|
| `sudo`                | 251ms  | 35ms  | **7x**   |
| regular internal user | 577ms  | 58ms  | **10x**  |

Reference
---------
task-4633813

Notice
------
⚠️ Note to clients/partners that might read this: For the full benefits of the patch, deploy the indexes that were added in this PR. This can be done by Upgrading the module `knowledge`, or creating the indexes manually in database. The patch should still be a net-benefit even for database without the indexes deployed.

Forward-Port-Of: odoo/enterprise#82773
Forward-Port-Of: odoo/enterprise#80971

When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref.

(Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.)

Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a now FBM offer.

While that second case would only require the user to delete and recreate a new offer (which would be a bother but not that problematic), sending a quantity to a FBA offer would trigger a well known problem of ghost listing on Amazon, where Amazon will consider having both channels, and randomly set an order as either FBA or FBM, until that ghost listing quantity drop down to 0.

When catching a discrepancy, we'll thus reset the value of the amazon_feed_ref, so that it'd be pulled again later if needed by the sync inventory with, this time, the correct value. This would also stop the inventory synchronization of a potentially FBA offer.

As for any stock synchronization that might happen between the listing changes from Amazon side and the first order received in FBA, we decided against forcing the FBM quantity to 0 on all FBA offer every time, to avoid sending too many useless calls for a corner case. As the product was until now sold in FBM, in most cases, it can still be until the end of the ghost listing. If not, our support is aware of it and can force the quantity to 0 again.

opw-4681035

Forward-Port-Of: odoo/enterprise#82754

Before this commit, when running a HOOT test suite with a dependency on `@mail`, the memory snapshot at end of suite test was higher than expected.

Steps to reproduce:

- run HOOT suite `global_filter_editor.test.js` with 51 tests
- make a snapshot of memory after test => observe that there's thousands of RecordList objects kept in memory (8976) instead of a few hundreds (176)

These tests do not make use of any mail code, but the manifest has dependency on `@mail` thus it loads mail store. This test suite is a good candidate to show constant memory issue from discuss code: 51 tests each having 176 record lists result in 8976 record lists in total.

The JS records are expected to be garbage collected after each test, thanks to store not being accessible from components and services (app is unmounted at end of test).

However, `Rtc.iceServers` field was preventing this and leads to keeping store in memory. This is happening because the default value of this field is `DEFAULT_ICE_SERVERS`, which is defined on window object globally and is shared among all the different stores in the test suite. The field is computed too, so an internal `onChange` also contributed in keeping a reference to observing this shared object.

This commit fixes the issue by providing a deep copy of this global variable as the default value of `iceServers`, allowing proper gc of store between tests of the suite.

**Problem**:
When the text is long, the switch for "Autoconvert to Relative Link"
is not visible also the "eCommerce Categories" refresh buttons shrinks.

**Solution**:
Adjust CSS to properly display them switch when the text is long.

**Before**:
![image](https://github.com/user-attachments/assets/324db4ab-70cc-4e88-8ecc-6df89e9fd54f)
![image](https://github.com/user-attachments/assets/49dbd33c-2a41-4d33-b3df-3e0920603a63)

**After**:
![image](https://github.com/user-attachments/assets/6ab270c3-00a5-49cf-8b71-2f5dc2bbde0a)
![image](https://github.com/user-attachments/assets/765024a0-9104-48ce-85fd-34080e109e11)

**Steps to Reproduce**:
1. Change language to **Dutch**.
2. Open the **website editor**.
3. Click on any **link**.
4. Copy your current link and paste it into the link input to trigger the "Autoconvert to Relative Link" switch.
   - **Issue**: The switch is not visible.

**opw-4558476**

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

Forward-Port-Of: odoo/odoo#204286
Forward-Port-Of: odoo/odoo#204244

**Problem:**
In the purchase app, when selecting 2 Purchase Orders that have
different currencies, and clicking Action then Accrued Expense
Entry, a traceback will appear. It works as intended if the two
Purchase Orders have the same currency, but if there is more than
one currency, the traceback will be displayed.

**Steps to reproduce:**
- Go to the purchase app and select two Purchase Orders that have
different currencies (you can make a group by Currencies).
- Click on Action then Accrued Expense Entry.
- The traceback appears.

**Cause of the issue:**
https://github.com/odoo/odoo/blob/a07a8589a8cb391a801ef1ffd60e02d83fc963f8/addons/account/wizard/accrued_orders.py#L246
The currency is given as a parameter to a function that requires
only one parameter. With this code, if there are multiple
currencies in orders, all of them will be given, which
creates a traceback.

**Fix:**
After checking with a PO, the multiple currency use case is not
supported. Hence make sure that there is only one currency in the
quotations we are trying to work with. If there is more than one,
we throw an error telling the user to only pick quotations with
the same currency.

opw-4562933

Forward-Port-Of: odoo/odoo#204007
Forward-Port-Of: odoo/odoo#202733

We encountered an error when trying to open `Furniture` or `Clothes` from the 
`Dashboard` if the Administrator has been assigned Admin rights to a new user.

Step to Reproduce:
- Install the Point of Sale module without demo data.
- Navigate to `Settings` > `Users` and `create` a new user with `Admin rights` of POS.
- Log in with the newly created admin user.
- Try to load sample data for `Furniture` or `Clothes`.

Traceback:
```
while parsing /home/odoo/src/odoo/saas-18.1/addons/product/data/product_demo.xml:5, somewhere inside
<record id="base.group_user" model="res.groups">
            <field name="implied_ids" eval="[(4, ref('product.group_product_variant'))]"/>
        </record>
```

Error[2]  generated when solving above problem :

Traceback :
```
while parsing /home/odoo/odoo/community/addons/point_of_sale/data/orders_demo.xml:86, 
somewhere inside <function model="pos.session" name="update_closing_control_state_session" eval="[[ref('pos_closed_session_1')], '']"/>
```

This issue was occuring since new users does not have access right of `res.groups`.

This commit will fix the above errors by using Superuser environment to load data..

sentry-6239966848

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

Forward-Port-Of: odoo/odoo#195374

When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref.

(Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.)

Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a now FBM offer.

While that second case would only require the user to delete and recreate a new offer (which would be a bother but not that problematic), sending a quantity to a FBA offer would trigger a well known problem of ghost listing on Amazon, where Amazon will consider having both channels, and randomly set an order as either FBA or FBM, until that ghost listing quantity drop down to 0.

When catching a discrepancy, we'll thus reset the value of the amazon_feed_ref, so that it'd be pulled again later if needed by the sync inventory with, this time, the correct value. This would also stop the inventory synchronization of a potentially FBA offer.

As for any stock synchronization that might happen between the listing changes from Amazon side and the first order received in FBA, we decided against forcing the FBM quantity to 0 on all FBA offer every time, to avoid sending too many useless calls for a corner case. As the product was until now sold in FBM, in most cases, it can still be until the end of the ghost listing. If not, our support is aware of it and can force the quantity to 0 again.

opw-4681035

Forward-Port-Of: odoo/enterprise#82754

Relocated the get_fiscal_year_start_date method from l10n_in_reports_gstr to l10n_in_reports to ensure availability even if the GSTR module is uninstalled.

This improves modularity and prevents dependency issues.

Trace-back:
```RPC_ERROR

Odoo Server Error

Occured on 77578514-18-0-all.runbot143.odoo.com on model account.report and id 10 on 2025-04-01 13:02:27 GMT

Traceback (most recent call last):
  File "/data/build/odoo/odoo/http.py", line 1962, in _transactioning
    return service_model.retrying(func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 156, in retrying
    result = func()
             ^^^^^^
  File "/data/build/odoo/odoo/http.py", line 1929, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http.py", line 2177, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http.py", line 727, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/web/controllers/dataset.py", line 36, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/api.py", line 533, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 5225, in get_report_information_readonly
    return self.get_report_information(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports_cash_basis/models/account_report.py", line 17, in get_report_information
    info = super().get_report_information(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 5209, in get_report_information
    'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2544, in _get_lines
    dynamic_lines = self._get_dynamic_lines(options, all_column_groups_expression_totals, warnings=warnings)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2996, in _get_dynamic_lines
    rslt = self.env[self.custom_handler_model_name]._dynamic_lines_generator(self, options, all_column_groups_expression_totals, warnings=warnings)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_in_reports/models/l10n_in_report_handler.py", line 173, in _dynamic_lines_generator
    self._get_out_of_fiscal_year_reversed_moves(options)
  File "/data/build/enterprise/l10n_in_reports/models/l10n_in_report_handler.py", line 146, in _get_out_of_fiscal_year_reversed_moves
    ('reversed_entry_id.invoice_date', '<', AccountMove.get_fiscal_year_start_date(self.env.company, datetime.strptime(options['date']['date_to'], '%Y-%m-%d')))
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'account.move' object has no attribute 'get_fiscal_year_start_date'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
    RPC_ERROR
        at makeErrorFromResponse (https://77578514-18-0-all.runbot143.odoo.com/web/assets/3b85f28/web.assets_web.min.js:3153:163)
        at XMLHttpRequest.<anonymous> (https://77578514-18-0-all.runbot143.odoo.com/web/assets/3b85f28/web.assets_web.min.js:3158:13)```

Forward-Port-Of: odoo/enterprise#82681