**Steps to reproduce:**
- Set handle notifications in Odoo for one user
- Go to `Sign` app with another user
- Create a signature request for the first user
- The first user is properly notified of the signature request, as the counter badge is updated.
- When clicking on the badge, no new message is shown.

**Issue:**
Inbox messages are not considered in the `MessagingMenu` when they are not linked to any record. It's the case when a signature request is sent and while the notification counter is updated, the message can't be seen in the top bar menu, it's only visible in the `Discuss` app > Inbox which is quite confusing for the users.

In previous versions the behavior was different as the signature request was either considered as an activity or no notification was sent.

Also if the inbox message is linked to a record, it only appears in the `all` filter of the menu.

**Fix:**
Added the inbox explicitly to the top `MessagingMenu` to be able to read the corresponding messages.

We could also link the signature to its record when sending the message instead of `self.env['sign.request']._message_send_mail()` but it might cause access rights issues.

Also ensured that a category `others` was used for such messages, and prevented an error caused by clicking on the conversation when the `Discuss` app was opened.

Unfortunatly doing this will show duplicates in the notifications of the menu for messages which are in the inbox but which have a record set. (e.g. when such message appears, it will have one line in the inbox and one for the record itself) So we need to filter out the messages which have a thread from their record in the views to avoid it.

related: https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda

opw-4969005

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

Forward-Port-Of: odoo/odoo#235052
Forward-Port-Of: odoo/odoo#228740

Currently, an error occurs when trying to add an attachment after saving an
invoice email as a template in the `Send wizard`.

**Steps to produce:**
- Install the `account` module.
- Create a new invoice, fill in all required details, then `confirm` and click `Send`.
- Click the `three-dot (⋮)` menu and select `Save as Template`, enter a name,
  and save the template.
- Try to add an attachment.

**Error:**
`AttributeError: 'account.move.send.wizard' object has no attribute '_mail_post_access'`
`AttributeError: 'account.move.send.wizard' object has no attribute '_get_thread_with_access'`

Root **cause:**
At [1], the code sets a new `template_id` when the template is saved. This
triggers `_compute_model()` at [2], which updates the model field to
`account.move.send.wizard` instead of `account.move`, using the `active_model`
context, causing the `error`.

**Fix:**
This commit ensures that after saving a mail template, the wizard retains the
correct model, same as [3], and prevents the attachment upload error.

[1]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L296

[2]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L244-L248

[3]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/mail/wizard/mail_compose_message.py#L380-L389

sentry-6987172677

Forward-Port-Of: odoo/odoo#234268

### Issue:
We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups.

### Steps to reproduce:
- Go to the "Payment reminder" email template
- Under the page "Content", add an attachment by clicking the "Attachments" button
- Under the page "Settings", add a dynamic report
- Create an overdue invoice for a partner
- Go on the form view of the partner, "Accounting" page
- Click "Send", make sure the template used is the one with the attachments
- Send
- The attachments on the template and the dynamic report are not sent

### Cause:
The mail template to send the follow-ups is only used to prefill the wizard.

### Solution:
Add the template in `_get_wizard_options()` to add the template in the option and later use it to add/generate its attachments.

This commit also refactors how the attachments are computed:
The previous code was adding the invoices PDFs then removing them. The whole process was confusing.
Now `options['attachment_ids']` is appended in `_get_followup_attachments()` with the desired attachments
depending on the options.

opw-5147736

Forward-Port-Of: odoo/enterprise#99458
Forward-Port-Of: odoo/enterprise#98454

**Issue:**
As a user without "Administration / Settings" access, it is not possible to revoke SEPA Mandates that have been used to pay invoices through the customer portal.

**Steps to Reproduce:**
- Enable SEPA Direct Debit payment provider in Test Mode
- Create a mandate for a customer w/ valid IBAN
- Create an invoice for that customer and post it
- Action > Generate a Payment Link, open this in an incognito window
- Pay using SEPA Direct Debit
- Call `_set_done()` on the payment.transaction
- Try to revoke the mandate as a non-admin with "Accounting / Billing"

-> Access Error, can't modify payment.token

**Cause:**
- When SEPA Mandate is revoked, we check for all associated payment tokens (saved payment methods from SEPA Direct Debit payment provider) and deactivate them.
- The check in code isn't called with sudo, so it uses the current user access rights, but only admins can modify the payment tokens in any way.

**Solution:**
- Write to the `linked_tokens` with sudo so we can archive the tokens regardless of user access

opw-5136221

Forward-Port-Of: odoo/enterprise#99447
Forward-Port-Of: odoo/enterprise#99232

**Problem:**
When confirming the invoice of an order delivered via dropship for some kit bom 
product with fifo/avco comp, if the price was manually set on the purchase order, 
the invoice lines generated for the cogs are inaccurate

**Steps to reproduce:**
- In settings enable dropshipping
- Create a kit product with one component (both storable).
- Set the route as Dropship for the component.
- add a vendor in the purchase tab of the component.
- set the cost of the component at 2
- and set an on hand quanity
- Set the product category to AVCO and perpetual for the
component and the product.
- Set the cost to 5 on the product.
- Create and confirm a sales order with a quantity
of 2 for the product.
- On the purchase order set the unit price at 20 for the component.
- Confirm the purchase order, then validate the delivery and
create the customer invoice.
- Confirm the invoice

**Current behavior:**
In the journal items tab of the invoice the lines for the cogs (expenses
and stock interim) have a value of 10

**Expected behavior:**
The value should be 40, in accordance with the purchase order

**Cause of the issue:**
In this forward port, the fix is different.
- Prior to this commit https://github.com/odoo/odoo/pull/222169/commits,
the cogs of a dropship kit were handled in this way:
When _stock_account_prepare_anglo_saxon_out_lines_vals() computes the
price_unit, it calls _stock_account_get_anglo_saxon_price_unit().
https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/stock_account/models/account_move.py#L131
For regular kits, the sale_mrp override of this method computes the correct
price. But for dropshipped kits, because the moves are generated
from the purchase order, they do not have a bom linked, so the
variable 'boms' is empty and the override do not modify price_unit.
https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/sale_mrp/models/account_move.py#L17-L18
However, the sale_stock override of this method calls
_compute_average_price()
https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/sale_stock/models/account_move.py#L212
The computation is handled in the mrp_account override, because
the product of the moves is different than self (because it's a kit).
There, for each component there is a call to _compute_average_price().
https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/mrp_account/models/product.py#L73
This time the computation is done in the super method where the value
is computed based on the stock.valuation.layer created by the purchase
order.
So the price taken into account is, rightly so, the one of the purchase order.

- But since the commit, there is no more stock.valuation.layers and no more
_compute_average_price().
_stock_account_prepare_realtime_out_lines_vals() now calls _get_cogs_value().
In the sale_mrp override of this method ( because the moves are still created 
from the purchase order), the variable boms is empty and the computation does not
happen here.
https://github.com/odoo-dev/odoo/blob/2a46a4e2c5a1f0a7848b50f3bf3ac6887a78b2df/addons/sale_mrp/models/account_move.py#L17
The computation happens in the super method where the standard price of 
the product is returned.
https://github.com/odoo-dev/odoo/blob/2a46a4e2c5a1f0a7848b50f3bf3ac6887a78b2df/addons/stock_account/models/account_move_line.py#L65
So now to fix the issue, we can not rely on compute_average_price but we need 
to modify the sale_mrp override of _get_cogs_values.

opw-4985440

Forward-Port-Of: odoo/odoo#229956

…er uom

**Problem:**
The overview of a produced MO does not take into account the uom of the component for the valuation

**Steps to reproduce:**
- Create a storable product (the comp)
- set the uom as L and the cost as 40$ per L
- set an on hand quantity
- Create a storable product (the final product)
- Create a bom for this final product using 100 ml of the comp
- Create, confirm and produce a MO for the final product
- click on the overview smart button

**Current behavior:**
the real cost is 4000$ (100*40)

**Expected behavior:**
it should be 4 (0.1 * 40)

**fix**
A fix was first introduced in this PR https://github.com/odoo/odoo/pull/230585.
But it was closed because this PR had already fixed https://github.com/odoo/odoo/pull/232364. 
However since this PR the issue is back https://github.com/odoo/odoo/pull/232872.

Here is the explanation of the new fix :
Inside _get_component_real_cost
_get_unit_cost returns the unit cost of the move
expressed for 1 unit of the uom of the product (which
is correct).
But quantity is expressed in the uom of the move
so we need to convert it in the uom of the product. https://github.com/odoo/odoo/blob/2ba4998b470236feee3a1636bf6d1807c74eac3a/addons/mrp/report/mrp_report_mo_overview.py#L583-L586

This commit adjusts a previous fix that was causing a new crash in certain contexts, like studio.

The original fix relied on view-specific information to be available, but this information was undefined in those edge cases. This new fix adds a safeguard to check that this information exists before trying to access it, preventing the crash.

Original fix:
Action icons (like 'Open Folder', 'Rename', etc.) were incorrectly appearing in list views outside of the main Documents app, for example, when selecting a folder in a settings menu or a popup dialog.

This was confusing and caused a crash when an icon was clicked, as the required functionality was not loaded in those contexts.

This fix removes the action icons from these secondary views. To keep the fix stable-proof, the template of the widget was modified, in 19.1 we will fix this in cleaner way.

The icons are now correctly restricted to the main Documents list view, where they function as intended. Other views (like folder pickers) now behave as standard selection lists without errors.

Task-5258848
Original Task-5166843

**Problem:**
the stock putaway rules do not apply
when the uom on the move is different
than the base uom of the product

**Steps to reproduce:**
- set the warehouse incoming shipment as 'two steps'
- enable the 'packages' setting
- navigate to 'Operation Types' and select Receipts
- check the 'set package type' box
- create a storable product
- in the sales tab add 'pack of 6' to the packagings
- navigate to 'package types' and create a new one
- navigate to 'storage categories' and create a new one
- In the 'capacity by pacakge' tab set a limit by package to 1 quantity of your new pacakge type
- open 'warhouse management/locations' and create a new one
- set the parent location to stock and the storage category to your new storage category
- open 'putaway rules' and create a new one
- set the 'store to' field as your new loc
- set the 'when product arrives in' field to stock
- set the 'product' field to your product
- create a new receipt for your product
- set the demand as 4 and the unit as 'pack of 6'
- mark as to do
- change the quantity to 2 and click on put in pack
- in the 'package type' field of the widget enter your new package type
- set the quantity to 4 and click on put in pack
- in the 'package type' field of the widget enter your new package type
- validate the picking
- click on next transfer
- validate the picking
- click on the moves smart button

**Current behavior:**
- both moves are going to your new location

**Expected behavior:**
- as there is a one package limit for this package type only the first move should be going
there

**Cause of the issue:**
The problem comes from the fact that there is no
destination package (result_package_id) on the
move lines of the second pick.
As a consequence the limits regarding packages
can not apply.

Here is why there is no result_package_id on those move lines :
when assigning the new move, action_assign
calls check_entire_pack().
https://github.com/odoo/odoo/blob/96264f88e6ea2dc61ba6c546f9f1a03d49df55ea/addons/stock/models/stock_move.py#L2013 There, before writing the 'result_package_id'
field of the move lines, the method calls
check_move_lines_map_quant_package inside the
if statement.
https://github.com/odoo/odoo/blob/96264f88e6ea2dc61ba6c546f9f1a03d49df55ea/addons/stock/models/stock_picking.py#L1301-L1305 This results in a call to _check_move_lines_map_quant.
Inside _check_move_lines_map_quant, when building
the grouped_ops dictionnary, the quantity of the
move line is expressed in the uom of the line
(here pack of 6) so it will be 2.
Whereas in grouped_quants the quantity used is expressed
in the uom of the quant (here unit) so it will be 12.    https://github.com/odoo/odoo/blob/96264f88e6ea2dc61ba6c546f9f1a03d49df55ea/addons/stock/models/stock_package.py#L403
As a consequence the diff in the float_is_zero
will not be null and the return value will be False.
    https://github.com/odoo/odoo/blob/96264f88e6ea2dc61ba6c546f9f1a03d49df55ea/addons/stock/models/stock_package.py#L405-L406

opw-5154168

_
## Short functional explanation of the error
Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund.

Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO.

## Reproduction Steps
1. Create a SO containing 2 different products and confirm it.
2. Create a regular invoice and confirm.
3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams.
4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds".
5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned.
6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund.
7. Click on reverse.

### Expected behavior
A credit note containing only the specified product to refund should be created.

### Unexpected behavior
The created credit note contains both products originally present on the SO.

## Origin of the issue
When issuing a refund from helpdesk_stock_account, this piece of code is called:
https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17

which calls the ```reverse_moves``` method in the
helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on.
Finally, we arrive in the account_move.py file. In the
```_reverse_moves``` of this file, we can see the code:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947
where we simply copy all the lines of the move in the SO
without filtering them. As a result, we get the lines
of the product we don't want to refund

__
opw-5148789

Forward-Port-Of: odoo/enterprise#98771

**Steps to reproduce:**
- Add some folders
- Create a new company
- Assign some folders to the new company
- Archive the company
- Click on Documents app
- AccessError is raised when opening it

**Issue:**
The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`:
`folders = accessible_records.filtered(lambda d: d.type == 'folder')`

This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched.

**Fix:**
Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere.

For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows.

opw-4931278

Forward-Port-Of: odoo/enterprise#99043
Forward-Port-Of: odoo/enterprise#96817

**Steps to reproduce**
- With Studio, create a many2one field in relation to the Employee
model.
- Have a user with no "Employees" rights.
- With this user and in mobile view, click on the field to select
an employee.
-> No records found.

Note: the many2one_avatar_employee widget used in HR apps avoid this problem.

**Cause**
Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374
The `web_search_read` on the private employee model returns no
records when an `image_*` or `avatar_*` field is part of the requested
fields.
This is because we try to fetch these fields
https://github.com/odoo/odoo/blob/188a3fe45fb41463ff86d1fa5e930ab43fb70d0e/addons/hr/models/hr_employee.py#L240
but they are not stored on the public employee model, and will not be
put in cache.

When performing a read after that, these fields are missing from cache.
We try to fetch them from the db
https://github.com/odoo/odoo/blob/e962860c6f0d8ec9e50bb376e1faab5c7bc69374/odoo/models.py#L3185
but this fetch is again done using the public employee.

This results in missing values and is interpreted as an access error, no
data is returned in `web_search_read`.

**Solution**
Read the problematic fields to make them present in cache when the cache
of the public employee is copied to the one of the private employee.

opw-4297115

Forward-Port-Of: odoo/odoo#234806
Forward-Port-Of: odoo/odoo#197575

Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered.

**Steps to Reproduce:**
- Install Sales module
- Create a Quotation
- Add a product(e.g Acoustic Bloc Screen), then only remove the name from the orderline and click on **edit button(pencil Icon)**.

**Error:**
`TypeError: SaleProductConfiguratorController.sale_product_configurator_get_values()`
 `missing 1 required positional argument: 'product_template_id'`

**Root Cause:**
When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_product_configurator_get_values`. which expects product_template_id at [1] and since it is removed from order line the error is encountered.

[1]- https://github.com/odoo/odoo/blob/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/sale/controllers/product_configurator.py#L11-L13

**Solution:**
This commit prevents the error by correcting `depends` on the field
`is_configurable_product`, which will ensure that edit button will be only
present if the configurable product is selected.

Sentry-5741581459, 6925770690

Forward-Port-Of: odoo/odoo#217464

## The issue

Prior to this commit, the `other` parameter in the `_merge`
method could belong to a different class, not necessarily an
instance of `Intervals`.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165

The comment indicates that normalization should be enforced; however, there
is no corresponding reference to it within the  `_boundaries` method.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53

That normalization just happens in the `__init__`.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132

## Example

For example, in Planning module, we perform operations between
`Intervals` and `WorkIntervals`.

The `WorkIntervals` class behaves differently from `Intervals`:
while `Intervals` uses disjoint closed intervals, `WorkIntervals`
uses disjoint semi-closed intervals.

## Side effects

During these operations, the `_merge` method was not normalizing
the `_items`, which caused inconsistencies and errors (when we are
merging two unormalized intervals `([0, 10], [10, 20])` with an empty
`others`).

## The fix

This commit ensures that the `other` parameter is normalized before
processing the `_merge` operation. The fix ensures that normalized
intervals are always produced after `_merge`, even when unnormalized
intervals are provided as input.

## Real case

That issue has been found in that ticket: 5184291

Forward-Port-Of: odoo/odoo#235233
Forward-Port-Of: odoo/odoo#234352

### Issue:
We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups.

### Steps to reproduce:
- Go to the "Payment reminder" email template
- Under the page "Content", add an attachment by clicking the "Attachments" button
- Under the page "Settings", add a dynamic report
- Create an overdue invoice for a partner
- Go on the form view of the partner, "Accounting" page
- Click "Send", make sure the template used is the one with the attachments
- Send
- The attachments on the template and the dynamic report are not sent

### Cause:
The mail template to send the follow-ups is only used to prefill the wizard.

### Solution:
Add the template in `_get_wizard_options()` to add the template in the option and later use it to add/generate its attachments.

This commit also refactors how the attachments are computed:
The previous code was adding the invoices PDFs then removing them. The whole process was confusing.
Now `options['attachment_ids']` is appended in `_get_followup_attachments()` with the desired attachments
depending on the options.

opw-5147736

Forward-Port-Of: odoo/enterprise#99458
Forward-Port-Of: odoo/enterprise#98454

**Current behavior:**
The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed when actually clicking the button and looking at the report.

**Expected behavior:**
Same values

**Steps to reproduce:**
1. Make a workcenter and a BoM with an operation performed at the workcenter

2. Use the BoM in an MO such that there is some un-productive time (e.g., recorded production duration takes longer than expected duration)
* example: 0:20 expected, 1:01 actual

3. Go to the workcenter list view -> click on the created workcenter -> look at OEE smart button display value -> click on it to see report -> report values are different

**Cause of the issue:**
the `oee` field on the workcenter is computed with rounded intermediary `blocked_time` and `productive_time` values, the actual report uses the raw values.

**Fix:**
Don't use the rounded intermediary values in computing `oee`.

Post-this-diff, we actually do one less `_read_group` (along with computing a more accurate field value).

opw-4795463

Forward-Port-Of: odoo/odoo#232730
Forward-Port-Of: odoo/odoo#218310

Currently, an error occurs when trying to add an attachment after saving an
invoice email as a template in the `Send wizard`.

**Steps to produce:**
- Install the `account` module.
- Create a new invoice, fill in all required details, then `confirm` and click `Send`.
- Click the `three-dot (⋮)` menu and select `Save as Template`, enter a name,
  and save the template.
- Try to add an attachment.

**Error:**
`AttributeError: 'account.move.send.wizard' object has no attribute '_mail_post_access'`
`AttributeError: 'account.move.send.wizard' object has no attribute '_get_thread_with_access'`

Root **cause:**
At [1], the code sets a new `template_id` when the template is saved. This
triggers `_compute_model()` at [2], which updates the model field to
`account.move.send.wizard` instead of `account.move`, using the `active_model`
context, causing the `error`.

**Fix:**
This commit ensures that after saving a mail template, the wizard retains the
correct model, same as [3], and prevents the attachment upload error.

[1]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L296

[2]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L244-L248

[3]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/mail/wizard/mail_compose_message.py#L380-L389

sentry-6987172677

Forward-Port-Of: odoo/odoo#234268

### Steps to reproduce:
	- Create a sale order with a SOL and an optional product
	- Preview the sale order and add the optional product to the order
	- Go back to edit mode and change the pricelist
	- Click on 'Update Prices'
	- Notice the optional product price won't change

### Cause:
When updating the prices of the SOLs we filter some lines that we won't recompute. Upon this commit https://github.com/odoo-dev/odoo/commit/2d919694d5c9588e0644d5ba82b15b9d3f762373 we remove the optional products from the recordset that will get price recomputation.

If sale_subscription is installed we will set the product's prices to 0 

https://github.com/odoo/enterprise/blob/85e0689ba12442e22e83f3337749c7ad2eb9d7d8/sale_subscription/models/sale_order.py#L674 

so the price of the 'Optional product' SOL will change but will be equal to 0

### Fix:
An exception for the filtering has been introduced as we will recompute the price of the optional products only if the pricelist is getting changed

opw-5058609

Forward-Port-Of: odoo/odoo#230053

**Issue:**
As a user without "Administration / Settings" access, it is not possible to revoke SEPA Mandates that have been used to pay invoices through the customer portal.

**Steps to Reproduce:**
- Enable SEPA Direct Debit payment provider in Test Mode
- Create a mandate for a customer w/ valid IBAN
- Create an invoice for that customer and post it
- Action > Generate a Payment Link, open this in an incognito window
- Pay using SEPA Direct Debit
- Call `_set_done()` on the payment.transaction
- Try to revoke the mandate as a non-admin with "Accounting / Billing"

-> Access Error, can't modify payment.token

**Cause:**
- When SEPA Mandate is revoked, we check for all associated payment tokens (saved payment methods from SEPA Direct Debit payment provider) and deactivate them.
- The check in code isn't called with sudo, so it uses the current user access rights, but only admins can modify the payment tokens in any way.

**Solution:**
- Write to the `linked_tokens` with sudo so we can archive the tokens regardless of user access

opw-5136221

Forward-Port-Of: odoo/enterprise#99232

While investigating a few support tickets related to how the l10n_cl override the fetch mail methods, we noticed a more general issue:

As of now, the payload parsing business logic of Odoo can't handle emails encoding parts with `charset=cp-850`.

This is due to the fact that `cp-850` is not a accepted/standard encoding alias for cp850 charsets in python's `encoding` library.

Whether or not a mail stack should generate mail using `charset=cp-850` or not, we this fix aims at pro-actively declaring `cp-850` as a valid alias for cp850, so that implicitly the email CPython library can correctly decode the payloads in emails.

### Before this bug:

Sending a mail using `charset=cp-850` would generate a traceback.

Example:
```
From: Sender Name <sender@example.com>
To: Recipient Name <odooalias@example.com>
Subject: Test Email with CP-850 Encoding
Date: Thu, 13 Nov 2025 12:00:00 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_4987654321-00000000"

This is a multi-part message in MIME format.
------------=_4987654321-00000000
Content-Type: text/plain; charset=cp-850
Content-Transfer-Encoding: quoted-printable

Hallo, dit is een test met een =82 speciale letter.
=
------------=_4987654321-00000000--
```

Would generate:
```
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1398, in message_process
    msg_dict = self.message_parse(message, save_original=save_original)
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1792, in message_parse
    msg_dict.update(self._message_parse_extract_payload(message, msg_dict, save_original=save_original))
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1592, in _message_parse_extract_payload
    content = part.get_content()
  File "/home/odoo/miniconda3/lib/python3.10/email/message.py", line 1096, in get_content
    return content_manager.get_content(self, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 22, in get_content
    return self.get_handlers[maintype](msg, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 67, in get_text_content
    return content.decode(charset, errors=errors)
LookupError: unknown encoding: cp-850
```

### After fix:
`content = part.get_content()` correctly handles the `cp-850` alias

OPW-5171501
OPW-5247486


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

Forward-Port-Of: odoo/odoo#235529