This improvement enhances user control over cookie preferences by making
the Cookie Policy page (/cookie-policy) more accessible and allowing
users to modify their consent at any time.

**Issue:**

- Previously, the only way to access the Cookie Policy page was through
  the link in the cookie consent popup. However, once users accepted
  cookies, the popup was no longer displayed, making it impossible to
  navigate to the policy page later.

- Additionally, the Cookie Policy page had a button to reopen the cookie
  consent popup, but it was only visible if cookies were not accepted.
  Once cookies were accepted, the button was hidden, preventing users
  from changing their preferences.

**Improvements:**

- Added a permanent link to the Cookie Policy page in the copyright
  footer, ensuring it remains accessible at all times.

- The cookie consent toggle button now remains visible even after a user
  has accepted cookies, allowing them to update their preferences at any
  time.

task-[4502416](https://www.odoo.com/odoo/project/974/tasks/4502416)

### **Summary**

In a real multi-company setup with multiple Belgian companies registered on Peppol, incoming Peppol invoices are systematically created in the **current user’s company**, instead of the company that actually received the document.

The problem occurs even though the correct journal is identified in `account_edi_proxy_client.user` and used to call `_create_document_from_attachment()`.

### **How to reproduce**

#### **Environment**

* Two Belgian companies: e.g. **Company A** and **Company B**
* Both registered and active on Peppol
* Each company has its own **Peppol purchase journal** (`company.peppol_purchase_journal_id`)
* An accountant with access to both companies

#### **Steps**

1. Trigger Peppol incoming document retrieval (`_peppol_get_new_documents`)

2. Odoo resolves the correct receiving company and journal:

   ```python
   company = edi_user.company_id
   journal = company.peppol_purchase_journal_id
   ```

3. The code uses this journal to import the invoice:

   ```python
   move = journal\
       .with_context(
           default_move_type='in_invoice',
           default_peppol_move_state=content['state'],
           default_peppol_message_uuid=uuid,
       )\
       ._create_document_from_attachment(attachment.id)
   ```

4. **Actual result**:
   The `account.move` is created in **the company of the current user**, *not* in `journal.company_id`.

5. **Expected result**:
   The vendor bill must belong to the company that received the Peppol document (i.e. `journal.company_id`).

This behaviour is reproducible 100% of the time when a user has multiple companies enabled.

---

### **Root Cause**

The selected journal is **never propagated** to the EDI XML decoder.

#### 1. The call in the Peppol module *looks* correct:

```python
journal.with_context(...)._create_document_from_attachment(...)
```

…but `_create_document_from_attachment()` in `account.journal` does *not* use `self` to determine the journal:

```python
invoices = self.env['account.move']
# `self` (journal) is not used at all during decoding
decoders = self.env['account.move']._get_create_document_from_attachment_decoders()
```

So the journal passed to `.with_context()` is effectively **ignored** inside the decoder chain.

#### 2. The XML decoder in `account.edi.format` explicitly uses the *environment company*:

```python
res = edi_format.with_company(self.env.company)._create_invoice_from_xml_tree(...)
```

Thus:

* The company used during invoice creation is **self.env.company**
* That is the **current user’s company**
* Not the Peppol recipient’s company
* Not the journal’s company
* Not the company associated with the Peppol identifier

#### 3. `_create_invoice_from_xml_tree()` supports a journal, but it is never provided

```python
if not journal:
    journal = self.env['account.journal'].browse(self._context.get("default_journal_id"))
```

Since `default_journal_id` is **never set**, the fallback is always used.

---

### **Why the fix requires passing `default_journal_id` explicitly**

Even if it **feels redundant**, it is necessary.

* We *are* calling the decoder through `journal.with_context(...)`
* But `_create_document_from_attachment()` does **not** use `self`
* The decoder receives **no reference to the journal**
* And is executed in a context where `self.env.company` = current user’s company

Because Odoo intentionally allows calling `_create_document_from_attachment()` on an **empty journal recordset**, the decoder cannot deduce the journal from `self.id`.

Therefore, the only reliable way to pass the journal down the stack is through the context key `default_journal_id`.

---

### **Proposed Fix**

Add `default_journal_id=journal.id` in the context at the point where the journal is still known:

```diff
--- a/addons/account_peppol/models/account_edi_proxy_user.py
+++ b/addons/account_peppol/models/account_edi_proxy_user.py
@@
 move = journal\
     .with_context(
         default_move_type='in_invoice',
         default_peppol_move_state=content['state'],
         default_peppol_message_uuid=uuid,
+        default_journal_id=journal.id,  # ensure correct company is used
     )\
     ._create_document_from_attachment(attachment.id)
```

This allows the EDI decoder to resolve:

```python
journal = self.env['account.journal'].browse(self._context.get("default_journal_id"))
```

Which in turn ensures:

* the invoice is created in `journal.company_id`
* the correct taxes, accounts, fiscal settings, and partner mapping are applied
* multi-company Peppol setups behave as designed

---

### **Impact**

Without this fix:

* All incoming Peppol invoices are created in the wrong company in multi-company environments.
* This leads to:

  * wrong journal assignment
  * wrong fiscal configuration
  * partner mismatches
  * tax errors
  * reconciliation issues

With this fix:

* Each Peppol invoice is correctly routed to the receiving company’s journal
* Behaviour is stable and consistent with Odoo’s EDI design

---

### ✔️ This is a minimal, safe and backward-compatible fix

* It changes only the Peppol integration behavior
* It does not modify EDI core internals
* It uses an existing mechanism (`default_journal_id`) already expected by Odoo
* It matches the intended API contract
* It prevents silent cross-company data corruption

Forward-Port-Of: odoo/odoo#237904