### Summary

Previously, when a user attempted to **register as a Peppol receiver** while already registered through a different Odoo database, the system would raise a **User Error**.  
The user had to **manually deregister** and **re-register** from the desired database.

---

### New Behavior (After This Commit)

With this update:
- The system **detects existing Peppol registrations** across databases.  
- Instead of raising an error, it now **sends an automated email** to the user with a **secure transfer link**.  
- This allows the user to **migrate their Peppol connection** to the current database seamlessly.

---
###  Flow Overview

```text
            ┌────────────────────────────┐
            │  User initiates Peppol     │
            │  registration (becomes     │
            │  sender)                   │
            └────────────┬───────────────┘
                         │
                         ▼
          ┌──────────────────────────────┐
          │  Check existing registration  │
          └────────────┬─────────────────┘
                       │
        ┌──────────────┴──────────────┐
        ▼                             ▼
┌─────────────────────┐       ┌──────────────────────────────┐
│ User NOT registered │       │ User ALREADY registered      |
│ in any Odoo DB      │       
└────────────┬────────┘       └──────────────┬───────────────┘
             │                               │
             ▼                               ▼
 ┌──────────────────────────┐      ┌──────────────────────────────┐
 │ Proceed with normal      │      │ Send email with transfer link│
 │ registration flow        │      │ to the user                  │
 └──────────────────────────┘      └──────────────┬───────────────┘
                                                  │
                                                  ▼
                                     ┌──────────────────────────────┐
                                     │ User clicks transfer link    
                                     │                                                                              
                                     └──────────────┬───────────────┘
                                                    │
                                                    ▼
                                     ┌──────────────────────────────┐
                                     │ Peppol connection migrated 
                                     └──────────────────────────────┘


```
---
iap pr- https://github.com/odoo/iap-apps/pull/1236
task- 5023252

Versions
--------
18.0+

Issue
-----
The `test_website_sale_add_and_remove_main_product_image_no_variant` and `test_website_sale_remove_main_product_image_with_variant` tours fail because the main product image is not removed as expected after the tour completes.

Cause
-----
Both tours assume that once the product `<img>` element is removed from the DOM, the action is fully completed. The tour then ends, and the remaining Python code verifies the result. However, this assumption can lead to issues. If the save request takes longer than expected, the Python code may execute prematurely and fail.

Solution
--------
Add a step at the end of both tours to wait for the `<img>` element to be fully saved and updated in the preview DOM.

Additionally, during debugging, it was observed that using an alias URL (i.e., a redirect) to an `ir.attachment` could introduce further issues or slow down the test due to the server fetching the image with a remote call. To address this, this commit replaces the alias URL with a simple binary attachment.

opw-5159593
runbot-163025
runbot-163615

**PROBLEM**
Internal users can access the documents of a private project even when they are not followers of the project. They shouldn't.

**STEP TO REPRODUCE**
1. Create a project, and set its visibility to Invited internal users (private), and upload a document to the project folder.
2. Switch to a user that is not a follower of the project, but is a user of the document app.
3. Go to the documents app, and notice you have access to files in the private project folder.

**CAUSE**
1. When creating the project folder, we don't specify `access_ids`, which means it will copy the `access_ids` of the folder above it. If a user have access to the "Project" folder, they will have access to any sub-folder ("Project" folder is the default parent folder of the any project folder).
2. `is_access_via_link_hidden` is by default set to False, which means the project folder is visible to anyone who has access to its parent folder.

**FIX**
1. Don't copy `access_ids` from the parent folder.
2. If project visibility is private, `is_access_via_link_hidden` is set to True.
3. To give access to the folder to the followers of the project, update the `access_ids` of the project folder and documents when add/removing followers.

opw-4791346

Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).

Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.

Example (processed in reverse order):
```js
[
  { type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
  { type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
    node: { textValue: 'b' } },
  { type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
  { type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
  { type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.

Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.

Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.

opw-5139795

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

Forward-Port-Of: odoo/odoo#233582

Issue
-----
Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML.

Steps to reproduce
-----
- Create a subcontracted product with 2 components
- Add one of each component in subcontractor's stock
- Create a PO for the finished product and confirm it
- Go to the production
- Open the "Record components" wizard
- Set quantity then remove the second line
- Confirm production (don't update consumption)
- Go to Inventory > Reporting > Moves History and remove the "Done" filter

> There is a pending move in the report

Cause
-----
When saving the wizard's changes, we call a write on the production's `move_line_raw_ids` field to remove delete the line. The field is a simple compute, so we go through its' inverse method

https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/mrp_subcontracting/models/mrp_production.py#L34-L46

The problem is that we populate `line_by_product` using the values present in `move_line_raw_ids` from which we just removed the line. This means that when we do

`move.move_line_ids = line_by_product.pop(move.product_id, self.env['stock.move.line'])`

we replace the value of `move_line_ids` with only the remaining ones, which means we unlink the move line (*from the move*). Because the inverse field (`move_id` of the SML) is not set as `ondelete='cascade'`, the link is broken but the line remains in db.

https://github.com/odoo/odoo/blob/f173c738b1adcf85a80eb641ad307b7cccf17294/odoo/fields.py#L4311-L4322

We cannot change the field to `ondelete='cascade'` as such a change would not be stable.

Solution
-----
Keep reference of the lines to be removed in order to delete them once `move_line_ids` has been updated.

-----
Ticket:
opw-4817397

Forward-Port-Of: odoo/odoo#229310

Problem: When a user changes the product on a scrap order, the bom_id field does not get updated. If they update the product from a product that has BoM to a product that doesn’t have one, then the bom_id field is hidden and remains set. This will cause the scrap quantity to be set to 0 when they validate the scrap. However, the product move actually happens for the correct quantity causing an inconsistency.

Purpose: This will either set the bom_id field to False if the new product doesn’t have a valid BoM, or it will update it to the first available BoM.

Steps to Reproduce on Runbot:

1. Create a scrap order for a product that has a kit type BoM and set the kit field.
2. Change the product to a product without a kit type BoM.
3. Validate the scrap order.
4. Observe the quantity field is set to 0, but there are product moves for the correct quantity.

opw-5122880

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

Forward-Port-Of: odoo/odoo#231937

### Issue:
Some valid Swedish account numbers are not recognized as Swedish.

### Steps to reproduce:
- Install 'l10n_se_bban' and switch to Swedish company
- Create a new partner, under the 'Accounting' page create a new bank account
	1- 62074-0
	2- 678653833066
	3- 99603406872188
- In the partner list view select this new partner
- Click Actions > Export, select "Banks" and "Bank Type"
- Check the file
	1- 62074-0 not recognized as Plusgiro
	2- 678653833066 not recognized as BBAN
	3- 99603406872188 not recognized as BBAN

### Cause:
These numbers are not recognized by the checks of Odoo but are valid numbers:
1. Plusgiro account numbers can be 2 to 8 digits long, Odoo accepted only 7 to 8 digits account numbers
2. Old Handelsbanken numbers (6000-6999) can have 8 digits instead of 9, Odoo only accepts 9 digits numbers
3. Only clearing numbers starting with 8 are 5 digits long, Odoo also included ranges 9500-9549 and 9960-9969

### Sources:
1 and 3: https://www.amcbanking.com/kb/swedish-payments-how-to-configure-sender-and-vendor-bank-accounts-in-fo/ 
1 and 3: https://github.com/Tobbe/kontonummer.js/blob/04959502d7d2d52938aabda80b8a3464efddfdd1/kontonummer.js 
2: https://github.com/barsoom/banktools-se/commit/b964806d5cad0491ea121419520fd5b5d4478c15

opw-5099867