Currently an error occurs when we try to remove bank accounts from a partner.

**Steps to reproduce:**
- Install `accountant` (with demo), Go to customers and create a new one with random name.
- Under accounting tab add a new bank account with an acc number, bank and save.
- Now remove the bank account record.

**Error:**
`AttributeError: 'NoneType' object has no attribute 'origin'`

**Cause:**
- The error occurs because of the SQL query [1] returning None values in the `id2duplicates` dict, somewhat like `{1: [None]}`, this caused the browse [2] to assign `None` to the `duplicate_bank_partner_ids`.
- While recording snapshots for diff checking in onchange system the none value will be stored like`None: {display_name:{}}` and when the line [3] tries to access `id_.origin` where `id_` is None and causes the error.

**Solution:**
- Added a condition which makes sure null values are not accounted. (The Join is added to makes sure that the correct `partner_id` is fetched.)

[1]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/account/models/res_partner_bank.py#L71-L85

[2]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/account/models/res_partner_bank.py#L88

[3]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/web/models/models.py#L1173

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

Steps to reproduce:
- Install website_event, with demo data
- Change Marc Demo's website access to "Restricted Editor"
- Log into Marc Demo and visit an event's website page e.g."Live Music Festival"
- user is able to edits is footer contents,make a change
- try to save.  

Observation: 
A pop-up for access right appears

Cause:
after this fix odoo/odoo@11e94cb059901ffc3c521a431259d627beb69e1e , 
we allow website to be editable for restricted user if, user can modify other
models, which are editable from website,like event.
And, if website is editable, we brand the ir.ui.views nodes, 
https://github.com/odoo/odoo/blob/3ceb04bf2aa90442430f5bf321bac4a9d872752c/addons/website/models/ir_qweb.py#L93-L94
but restricted user do not have access to ir.ui.view model, causing access issue

Note: if a node is branded, that means it is editable

Fix:
Brand ir.ui.view nodes only if user has full access to website editor

opw-4659114


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

Forward-Port-Of: odoo/odoo#221202

## Short functional explanation of the error
When duplicating a warehouse, if it has an PoS operation type,
this operation type will not be duplicated. On the other hand,
all other operation types will be duplicated. 

## Reproduction Steps
1. Make sure PoS and inventory are well installed.
2. Go to inventory. 
3. Click on configuration, then warehouse.
4. Select a warehouse, click on action, then duplicate.
5. Click on configuration, then on Operation Types.

### Expected behavior
We should be able to see 2 instances of PoS operation type:
one for the original company, and one for the copy.

### Unexpected behavior
There's only one instance of PoS operation type, which is
related to the original company.


## Origin of the issue
PoS operation type is a model inherited from stock.warehouse,
and no copy method was defined. Therefore, upon duplication,
the copy method of the original stock.warehouse was called,
leading to issues with the field created in the inherited
version.

__
opw-4991271

Forward-Port-Of: odoo/odoo#222694

### Description of the issue/feature this PR addresses:
Nilvera rejects E-Archive invoices if extra fields are present under
`PartyTaxScheme` when no tax office is set. In addition, the
`invoice_edi_format` selection name for TR was incorrect.  

### Current behavior before PR:
When generating E-Archive invoices, Odoo includes extra nodes such as
`registration_address_vals`, `registration_name`, and `company_id`
under the `PartyTaxScheme` element. Nilvera’s validation fails if
these nodes are present while no tax office is configured. At the same
time, the TR value for `invoice_edi_format` was using the wrong name,
which caused inconsistencies. These issues result in blocking
validation errors on Nilvera’s side and prevent the invoices from
being accepted.  

### Desired behavior after PR is merged:
After this fix, the `PartyTaxScheme` is cleaned up only to include the
expected XML structure:

```xml
<cac:PartyTaxScheme>
    <cac:TaxScheme>
        <cbc:Name>TAX OFFICE NAME</cbc:Name>
    </cac:TaxScheme>
</cac:PartyTaxScheme>
```
And the invoice_edi_format selection name for TR will be corrected
to display Türkiye rather than Turkyie.

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

## Steps to reproduce:
- Make sure the Mexican localization is installed and properly set up for signing invoices
- Make sure the payment providers are set up (it can be demo, the customer uses Stripe but it can be reproduced with any
- Make sure the online payment setting is active
- Go to subscription module
- Do a new order
- In other info, add the online payment checkmark
- Confirm the order
- Generate the payment link or go into the preview
- Make the payment

## Issue:
The invoice is generated, but is not signed by the government (no edi is generated), as it used to.

## Cause:
The flow works in 17.0 but for the wrong reason. Before this [commit](https://github.com/odoo/enterprise/pull/70562), two mails were sent. And during the chain of triggers of the second email, edi document was generated with `orders._send_success_mail(tx.invoice_ids, tx)`.
https://github.com/odoo/enterprise/pull/70562/files#diff-8778c8dce7ca1c24de19f26f11ac0c5410c6c2a4d121c3815682a2323cbb09c2L177

After the removal of the method, it should still work since we still have `payment.transaction._send_invoice` which calls `_generate_and_send_invoices` and should trigger the sub calls necessary for generating the edi stuff.
But in `_create_or_link_to_invoice`, we check that the transaction has no invoice_ids linked (make sense with the name of the method). However, at this stage, we already created the invoice in
https://github.com/odoo/enterprise/blob/2f3698b250092ad376344e959d46bdc0eebf1a81/sale_subscription/controllers/portal.py#L419-L424

And unfortunately, it will be effectively possible to "let the post process of transaction create" the invoices only in Master (the code is not ready yet). For now it would be too risky for a stable version to make such change.

## Solution:
We ensure EDI documents are generated whenever a `subscription_action` is set.

To achieve this, modify the `_post_subscription_action` hook to call `_subscription_post_success_payment` for any `subscription_action`, including `assign_token`.

From `_subscription_post_success_payment`, we can call `_generate_and_send_invoices` on any invoice that has an EDI associated with it, which sends & signs the required EDI documents.


opw-4648189