Problem:
Bootstrap grid classes like `row` and `col` are not handled properly when placed inside an `o_text_columns` container. During processing (e.g., for email rendering), rows are expected to be converted to tables — but since `o_text_columns` is not included in the selector query, the transformation is skipped.

As a result, when rendering the email, columns are not preserved and fall back to stacked layout.

Solution:
Update the container selection logic to include `o_text_columns` when querying Bootstrap-based containers that need to be transformed into tables.

Steps to reproduce:
1. Go to Email Marketing.
2. Create a new email.
3. Add a Text snippet.
4. Type `/col` and choose "2 Columns".
5. Add text to both columns.
6. Save and send the email. → In the received email, the two columns appear stacked
   vertically instead of side by side.

opw-4675310

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

Forward-Port-Of: odoo/odoo#211109

### Steps to reproduce:

- install fsm_industry
- run any of these tests:
    - test_change_parent_plan
    - test_change_parent_plan_conflict
    - test_change_parent_plan_with_intermediate
    - test_change_plan
    - test_change_plan_conflict
    - test_change_plan_no_conflict
#### > create access right error for the `account.analytic.line` model

### Cause of the issue:

The following three record rules provide the creation of `account.analytic.line` for users related to project or timesheet access rights unless the analytic line it self is linked to a project: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L52-L64 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L78-L83 Since the analytic module is unrelated to the project module, these tests will inevitably fail.

### Note:

These record rules do not stop the record creation once the account module is installed since the following record rules override the creation access rights for `account.group_account_invoice` users: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/account/security/account_security.xml#L102-L107

Similar issue treated in commit 9d164c1d2cd8e532109b9859ab776fcf2f71d115

### Note 2:

A priori, the same problem would occur if we were to write post install analytic tests for portal users:
https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L50

### Forward port additional fix (18.0):

Since Commit 0e997470b7174a187c876d734e38f633223f65ec the test  of the `TestAnalyticAccount` class are launched in sudo mode since the environment is set using OdooBot and never associated with an other user:
https://github.com/odoo/odoo/blob/ed38752e55d6bafbc71fac3df249f226a4eba332/odoo/tests/common.py#L979
https://github.com/odoo/odoo/blob/4baf55a5d108063b0b60beddf332b6ae367f1871/odoo/api.py#L568-L571
In 17.0 the environment was reset to a non sudo mode by the user  reassignement:
https://github.com/odoo/odoo/blob/d2ea23f252f0f8f329e2b0ff96de6ee2a14b922f/addons/analytic/tests/test_analytic_account.py#L28-L31
In order for the tests to also check access rights we have added our own `setup_independent_user` in the `AnalyticCommon` class.

Note 3:
Since saas-18.3, there are new problematic groups:
https://github.com/odoo/enterprise/blob/e54a44bf6c8e0f37ccc72006ab691be18d79859b/helpdesk_timesheet/security/helpdesk_timesheet_security.xml#L4-L24
In addition, since the accounting group `account.group_account_invoice` is not part of the default group when `account.accountant` is installed, we need to remove the problematic groups in all independantly of the install of `account.accountant`.

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

Forward-Port-Of: odoo/odoo#210001
Forward-Port-Of: odoo/odoo#208978

If a user tries to open a combo product on the website and the combo item
has been deleted, a traceback will appear.

Steps to reproduce the error:
- Install ``website_sale_stock`` module
- Create ``Product A`` > product type: ``Goods`` > Save
- Go to Website > eCommerce > Combo choices > Create New(``Combo choice A``) >
  Add ``Product A`` in combo item
- Create ``Product Combo A`` > product type: ``combo`` > Combo Choices: ``Combo choice A``
- Delete ``Product A``
- Go to Website > Shop > Open ``Product Combo A``

Traceback:
```
File "/home/odoo/src/odoo/addons/website_sale_stock/models/product_combo.py", line 25, in _get_max_quantity
    return max(max_quantities) if (None not in max_quantities) else None
ValueError: max() iterable argument is empty
```

https://github.com/odoo/odoo/blob/4d3b220b0ec6e718f962979b3f271ea161997322/addons/website_sale_stock/models/product_combo.py#L21-L24
Here, when the user deletes the product, ``self.combo_item_ids`` becomes empty,
resulting in ``max_quantities`` being an empty list ([]),
which causes the above traceback.

sentry-6589160704

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

Forward-Port-Of: odoo/odoo#208766

After a recent change in German EDI, the data exported in CSV from the EC Sales List
can no longer be uploaded because the expected structure has changed

Steps to reproduce (with a DE Company):
- Make an invoice to an EU Partner
- Open EC Sales List
- Export CSV

When uploading the file on the Elster portal it will be rejected with an explicit error message,
saying that we're using an old CSV format now deprecated, and prompts the user to refer to the new specifications

Original message:
Ihre CSV-Datei wurde für eine ältere Version der CSV-Schnittstelle erstellt.
Bitte informieren Sie sich in der Versionstabelle der Importhilfe über die aktuellste Version der Schnittstelle sowie Änderungen.
Sind die Versionsangaben korrekt, prüfen Sie bitte das Encoding Ihrer CSV-Datei. Das zulässige Encoding ist UTF-8.

Sources:
https://www.elster.de/eportal/helpGlobal?themaGlobal=zmdo_import_eop
https://www.datev-community.de/t5/Betriebliches-Rechnungswesen/Import-CSV-Daten-nacvh-Elster-f%C3%BCr-ZM/td-p/480079

opw-4751667
opw-4674533

Forward-Port-Of: odoo/enterprise#85992

**Steps to reproduce:**
- Install Planning app
- Set the type of view to Gantt
- (Create a shift if there is none)
- Click on `Publish` button
- The period end date doesn't take the last day into account (time is 00:00)

**Issue:**
Gantt model default `_buildMetaData` computation behavior was changed multiple times
during previous refactoring:

Previously used:
```
export function computeRange(scale, date) {
    let start = date;
    let end = date;

    if (scale === "week") {
        // startOf("week") does not depend on locale and will always give the
        // "Monday" of the week... (ISO standard)
        const { weekStart } = localization;
        const weekday = start.weekday < weekStart ? weekStart - 7 : weekStart;
        start = start.set({ weekday }).startOf("day");
        end = start.plus({ weeks: 1, days: -1 }).endOf("day");
    } else {
        start = start.startOf(scale);
        end = end.endOf(scale);
    }

    return { start, end };
}
```
Which became:
```
export function getRangeFromDate(rangeId, date) {
    const startDate = localStartOf(date, rangeId);
    const stopDate = startDate.plus({ [rangeId]: 1 }).minus({ day: 1 });
    return { focusDate: date, startDate, stopDate, rangeId };
}
```

**Fix:**
This issue was partially fixed in 18.3, removed my changes and used the
given solution while ensuring the last day is fully taken into account by using:
`adjustedEndDate.endOf('day')`

related commits:
https://github.com/odoo/enterprise/commit/d18639785e622d97102227103d62ddb3a2716be6
https://github.com/odoo/enterprise/commit/c175a848369057cc69596737dcd9d21dd24c9d5c

issue partially fixed with:
https://github.com/odoo/enterprise/commit/d32646024fd2e9aadb0cf4022eeda94296922684

opw-4580458

Forward-Port-Of: odoo/enterprise#85920
Forward-Port-Of: odoo/enterprise#85608