**Steps to reproduce:**
- Install Accounting
- Create a tax with the following configuration:
  * Tax Type: Purchases (also reproducible with Sales)
  * Included in Price: [any]
  * Affect Base of Subsequent Taxes (include_base_amount): [checked]
  * Base Affected by Previous Taxes (is_base_affected): [checked]
  * Distribution:
      |  %   | Based On |  Account  |   Tax Grids |
      | ------ | ------------- | ------------ | -------------- |
      |      |   Base   |           | +Tag_1  +Tag_2 |
     | 100.00 |  of tax  | Account X | +Tag_3 |
     | -100.00 |  of tax  | Account Y | -Tag_4 |

(Or FR localization and "20% EU G" purchase tax can be used)
- Create a bill
- Add a line with the created tax
- Check journal items

**Issue:**
The tax tags of the base line are also added to first tax line.

**Cause:**
When a tax is "include_base_amount", the tags of its base line is propagated to the tax lines of the following taxes. However in this case, as there are several tax lines for the same tax, the system propagate the tags to the second one as if it was coming from another tax.

**Solution:**
Check if the tags are coming from another tax before adding them.


opw-4510882




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

HTML content is often saved as XML (i.e. through templates) and saved as such in the database. This introduces issues when elements are written under their `self-closing` format (i.e. `<a/>` or `<br/>`) as browsers will incorrectly parse these values as HTML by adding a closing tag at an arbitrary position which may modify the initial nodes configuration. This can be prevented by post-processing untrusted content before the html parsing.

This commit is an overhaul of:
https://github.com/odoo/odoo/commit/26b922ef5cad42da7e188195e919e54878d472fc https://github.com/odoo/odoo/commit/1a8a943d8373864165cb513b3767b866d626fad8 https://github.com/odoo/odoo/commit/4e547b24a323f8e59a11c5b78cbea38effc37938

in order to apply the conversion at critical entry points for editor assets:
- HtmlField is an entry point for data coming from the server, stored on the record. Every access of the record data should not be trusted and go through the post-processing.

- HtmlViewer is an entry point as it can be used as a standalone (see `website_knowledge`, or the HistoryDialog) for data coming from the server.

- Editor is an entry point as it was developed to be useable as a standalone.

task-4547973

Steps to reproduce:
[l10n_de]
- create an invoice
- confirm the invoice
- send the invoice
- send the invoice again

Issue:
You will get an error "You cannot remove parts of the audit trail. Archive the record instead."

Cause:
We don't prevent entering the hook if there is already a generated pdf. During the hook, we want to "generate a Factur-X and embed it inside the PDF for inter-portability" https://github.com/odoo/odoo/blob/84a0b81a258262e3bb9dbaa9c9f37796303a9dad/addons/account_edi_ubl_cii/models/account_move_send.py#L124-L128

In the German loca, while trying to write on the attachment, we'll check that the move has not been already posted. In which case it will raise the error https://github.com/odoo/odoo/blob/5215428114842c606202e7b1c69f5f597a977f92/addons/l10n_de/models/ir_attachment.py#L13-L34

solution:
Prevent entering the hook if there is already a pdf as it is done a few lines before https://github.com/odoo/odoo/blob/9f65f1a3b0b6b893f230729c56f287f5aff6af35/addons/account/models/account_move_send.py#L607

opw-4471377

Steps to reproduce:
-------------------
- In a Spanish company, make sure l10n_es_edi_tbai is installed.
- Create an invoice with one product and add 2 taxes for that line (for example, the 21% goods and the 5.2 ES tax).
- Confirm and send the invoice with TBAI.
- In the TBAI xml you will find the total amount wrong as the base amount was calculated twice, one time for each tax.

Cause:
-----
Since (#180062), the tax details calculation process was reworked.
the total amount is calculated inside a loop with this formula
```
for values in values_per_grouping_key.values():
	total_amount += values['base_amount'] + values['tax_amount']
```
In case one invoice line has 2 taxes of different tax groups, this code will add the base_amount twice in the total_amount calculation.

Fix
---
Move the base amount addition in a separate loop with a new aggregation (with no grouping) to add the base amount to the total.

opw-4501051

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

This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``.

Traceback:
---
```
KeyError: 'content-type'
  File "odoo/http.py", line 2366, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1894, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1957, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1924, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2171, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 727, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/html_editor/controllers/main.py", line 355, in add_url
    attachment = self._attachment_create(url=url, res_id=res_id, res_model=res_model)
  File "addons/html_editor/controllers/main.py", line 256, in _attachment_create
    mime_type = response.headers['content-type']
  File "requests/structures.py", line 52, in __getitem__
    return self._store[key.lower()][1]
```

https://github.com/odoo/odoo/blob/2fe55ae592e5812c5ee5e39ed1e8332bde608cb2/addons/html_editor/controllers/main.py#L257

sentry-6015024235

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

Steps to reproduce:
- Install "l10n_ch" and switch to a Swiss company
- Create a new invoice with a Swiss customer
- Confirm
- In the actions, select "PDF without payments"
- The generated PDF has a blank page at the end

Cause:
Some computation looks for report applicable to invoices.
PDF without payment (`report_invoice_with_payments`) is a
special case of such report. We don't want it to be used as an
official report template for invoices, but we want to allow the
Swiss case where the payment QR code should be possible to add.

The bug appears after this commit which modified the
`_is_invoice_report` method to only validate report with
is_invoice_report=True.
https://github.com/odoo/odoo/commit/bb60952c944db27d71d7fe32ead2dff05c3fe922#diff-b6e108b605fbefba066e3b20f8e030ea78881bbed816f8ac5cb38e745c542739R50

Solution:
Fix the method _is_invoice_report to recognize PDF without payment,
without setting the latter to is_invoice_report=True (which triggers
undesirable behaviors surch as showing multiple templates in the
Print & Send wizard).

opw-4467250

**Issue**
Recruitment-type surveys do not appear in the Participations section, even when participants have completed the survey.

Steps to Reproduce:
1. Install hr_recruitment_survey module 
2. Open the Surveys app.
3. Create a new survey or open an existing one.
4. Set the survey type to Recruitment.
5. Click on the Participations smart button.

Expected behavior: Participants who completed the survey should be listed.
Actual behavior: No participants are shown.

**Root Cause**

https://github.com/odoo/odoo/blob/de935a1b3ad96e24b5fd1bd317c73c12e9b3a08f/addons/survey/models/survey_survey.py#L1090-L1096

Once the smart button is clicked, the action variable is populated through the following record

https://github.com/odoo/odoo/blob/de935a1b3ad96e24b5fd1bd317c73c12e9b3a08f/addons/survey/views/survey_user_views.xml#L153-L168

The record includes a domain filter that restricts the displayed results to specific survey types. Since "recruitment" is not listed among the accepted survey types, it fails the check and is excluded from the results.

**Fix**
Overriding the action_survey_user_input action template in XML to extend the domain was impractical because it replaced the existing domain rather than extending it. This prevented seamless integration with other modules, limiting flexibility. Instead, we opted to extend the domain within the action's returned values, ensuring better modularity and maintainability.

opw-4516112

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

**Steps to reproduce:**
- Install Accounting
- Go to "Accounting / Configuration / Accounting / Journals"
- Open "Bank" Journal
- Go to "Outgoing Payments" tab
- Set a check layout
- For "Checks" line, set "101401 Bank" (i.e. an account that doesn't allow reconciliation) as outstanding payments account
- Create a vendor bill and confirm it
- Pay the bill with "Checks" as payment method
=> The bill is directly marked as "PAID" and not "IN PAYMENT" because the "Bank" account doesn't allow reconciliation
- Go the the check payment

**Issue:**
It is not possible to print it.
The same configuration allows to print the check in previous versions.

**Cause:**
As the check payment is using an account that doesn't allow reconciliation, the payment is set in "Paid" state directly, but the printing is disabled for checks in that state.

**Solution:**
As it should be harmless to allow to print the check even if it is already paid, we will allow to print it to keep a consistent behavior with previous versions.
Only printing the check will be allowed.
Voiding or rejecting will still be impossible.

opw-4498446




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

**Current behavior:**
When a user wants to upload its VAT return to the French Government, they receive the following error message:
```
    report_line_code = report_lines_code_per_id[report_line_id]
                       ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
KeyError: None
```

**Expected behavior:**
The user should be able to upload their VAT return without any error message.

**Steps to reproduce:**
1. Create a French company, using French Accounting. (`l10n_fr_reports`, `l10n_fr_account`).
2. In the Settings, activate the Analytics option "Add totals below sections".
3. Go to Tax reports > Actions > EDI TVA > Send Report

**Cause of the issue:**
When the "Add totals below sections" parameter is enabled, the system will add new total lines on the report for each group of report lines. In the case of the Standard French VAT report, a single total line is added.

The issue is that before sending the report, the values are formatted by `_get_formatted_edi_values`. Each line to format is mapped to its corresponding line ID in line [255](https://github.com/odoo/enterprise/blob/0c32410b50b0edc2bc68c3199f741756b49600a2/l10n_fr_reports/wizard/l10n_fr_send_vat_report.py#L255): `report_line_id = self.report_id._get_model_info_from_id(line['id'])[-1]` Alas, for the new total lines, the line ID and its corresponding model are both None, which leads to an error on the next line. In version 17.0, there was a check for the model of the line, which was removed in version 18.0.

**Fix:**
- Add a check on the model of the line before formatting its values, to prevent the total lines from being formatted and sent.

opw-4496692