**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Journal Entry** in mobile view.
* Add a **Journal Item**, opening it in a form dialog.
* Select a tax in the **Taxes Applied** field.
* Click on the **Save and close** button.

**Observed behavior:**
* The web client crashes with `TypeError: Cannot read properties of undefined (reading 'resId')`.

**Cause:**
* The `autosave_many2many_tags` widget triggers `model.root.save()` immediately when a tag is selected.
* When executing this save from within a transient dialog (common in mobile views), the client fails to correctly handle the record reload/synchronization leading to a crash when accessing `resId`.

**Fix:**
* Replace the autosave widget with the standard `many2many_tags` widget for **Journal Items** for form.
* Tax changes are now kept locally in the dialog and saved only when the user explicitly saves and closes it.

**Note:**
* The crash happens when `autosave_many2many_tags` calls
  `model.root.save()` on a **new** `account.move` from within a dialog.
* In QUnit tests, the mock server (`mockWebSave`) [1](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L627). which creates records [2.](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L1936)
  in-memory and does not trigger form reloads or component destruction.
* As a result, the crash cannot be reproduced in tests.




opw-5497342

Forward-Port-Of: odoo/odoo#246084

_
## Short functional explanation of the error
Let's say a customer has made 2 sales order of 2 different serives: one service is prepaid, the other one is billed based on timesheets. When we create a ticket related to this customer in the helpdesk app, the ticket automatically fills the Sales Order Item field with the prepaid service. If we remove this Sales Order Item, create a timesheet in which we set the Sales Order Item to be the timesheeted service, and press save, the Sales Order Item of the timesheet will disappear.

## Reproduction Steps
1. Create 2 products: one service based on timesheets and one service prepaid. Make sure that they create an empty project on order.
2. Create 2 quotations for the same partner: one that contains the first product you created and a second one containing the second product. Click on confirm.
3. Go to Helpdesk > Configuration > Helpdesk teams. Click on one team and under Track and Bill time, enable both Timesheets and Time Billing.
4. Create a Helpdesk ticket for the team you setup. Under customer, enter the name of the partner in the quotations.
5. Click on the ticket. The quotation related to the prepaid service should appear as the field Sales Order item on the ticket. Remove it, click on the Timesheet tab, and add a line in which, for the Sales Order Item field of the timesheet, you'd enter the quotation for the timesheeted service.
6. Hit save.

## Expected behavior
The quotation entered as Sales Order Item field in the timesheet persists, while the Sales Order Item field of the ticket stays empty.

## Unexpected Behavior
the Sales Order Item field in the timesheet tab disappears.

## Origin of the issue
The field is_so_line_edited was kept at false as the widget used to
update its value wasn't used in the view.

_
opw-5384256

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

When applying a downpayment in POS with tax-included prices, a rounding error of 0.01 cent could occur, preventing invoice creation.

For example, with an 8% tax and a downpayment of exactly 2,117.00:
- Calculation: 2117 ÷ 1.08 = 1960.185 → rounds to 1960.19
- Recalculation: 1960.19 × 1.08 = 2117.005 → rounds to 2117.01
- Result: 0.01 cent discrepancy

Root Cause:
-----------
The issue stems from cascading rounding errors when using 'round_per_line' method with standard product price precision (typically 2 decimals). Each intermediate calculation introduces a small rounding error that accumulates.

Solution:
---------
Apply two specific fixes for downpayment products only:

1. Use higher precision (6 decimals) instead of standard product price precision to maintain accuracy through the calculation chain

2. Force 'round_globally' rounding method instead of 'round_per_line' to ensure rounding happens only once at the final step, not at each intermediate calculation

3. Use raw (unrounded) amounts in tax calculations to preserve full precision until final rounding

opw-5040722

When a user is viewing a page, clicks on the Knowledge Book icon, opens an article, and selects the "Send As Message" button in a Knowledge Clipboard block, the macro system performs several actions: it restores the initial view, opens the full mail composer, and inserts the clipboard block's text at the very end of the editor.

Recent updates introduced automatic inclusion of the user's signature in the email body when the full mail composer is opened. As a result, the clipboard text is inserted after the user signature, which is undesirable because users must manually adjust the message to position the signature correctly.

To insert text before the user signature but after the user text, the clipboard macro will now trigger a "click" event on the button opening the full mail composer and set on that event the text to insert. The chatter will then read that value and insert the text at the right place.

Task-4428445

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

l10n_mx_edi* = l10n_mx_edi, l10n_mx_edi_pos, l10n_mx_edi_extended

**STEP TO REPRODUCE**
1. Create a invoice with:
    - product price = 72.89
    - discount = 10%
    - tax = 16%
2. Duplicate the invoice until you have 5 of them.
3. Create a global invoice with the 5 invoices, and send it.
4. The invoice will be refused by the EDI due to rounding issue.

This PR is a backport of multiples fixes done in 18.3 in which all rounding errors are fixed.
Each of them iterate upon the previous one, so they are all needed. The most important changes in thoses fixes are:
    - for global invoices, deduce the discount on the base line instead of creating a 'descuento' (to avoid any problem with rounding when combining multiples invoices).
    - changes in how the negative lines are dispatched.
    - using raw values for 'conceptos' and 'impuestos' (5 digit precision) and changing how we compute things to solve rounding issue.

Tests files are modified accordingly, you can launch the tests with the external flag (need to be set in tests/common.py).

Backported PR (non-exhaustive):
https://github.com/odoo/enterprise/pull/92727
https://github.com/odoo/enterprise/pull/99395
https://github.com/odoo/enterprise/pull/90434

opw-5382423

Steps to reproduce:
===================
1- Drop the block tab snippet
2- Inside one of the tab panes, drop a Columns snippet.
3- Select background_color for one of the columns
4- Change tab style to tab

-> The background color of the inner column is overridden.

Cause:
======
When the "Tabs" snippet style is set, a `.card` class is added to its container (See [1])
A generic CSS rule, intended to style these tabs, was targeting any `.card` element with a `.card-body` child. (See [2])

However, the Columns snippet also uses a `.card > .card-body` structure (distinguished by a `data-vxml` attribute). This caused the overly broad tab-styling rule to incorrectly cascade and override the background color of the nested column.

Solution
========
The SCSS selector has been made more specific so that works if `card-body` class doesn't have any parent class with class `card` and has attribute `data-vxml`

[1]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/website/static/src/snippets/s_tabs/options.js#L149
[2]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/web/static/src/scss/bootstrap_review_frontend.scss#L55

opw-5394480

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

The runbot builds are currently failing after the recent merge of commit [1]
due to a triggered documents logger warning.

In commit [1], `cls.attachment_txt` is created with invalid `datas` in
`setUpClass`, which triggers an error and raises a log warning at code
line [2]. We already added `mute_logger` to suppress this log, but it does
not work due to caching behavior in setUpClass.

The `setUp` method of the `TransactionCase` test class attempts to flush all
pending data (see code reference [3]). During this flush, it recomputes the
values of `cls.attachment_txt`, which triggers the same logger warning again.
Since this occurs outside the mute_logger context, the log is not suppressed,
resulting in the runbot failure.

This commit fixes the issue by introducing a helper method to create and
return `attachment_txt` for use in the test methods.

[1]: https://github.com/odoo/enterprise/commit/d4ecf6c75bff3fc29a95c40f86528c6b10870e12
[2]: https://github.com/odoo/enterprise/blob/f3e2de6bae7573ad61429a55ff3769ba7fab58ea/documents/models/documents_document.py#L1355-L1356
[3]: https://github.com/odoo/odoo/blob/8e60084924d390632934b5a9bd82a6954d6484de/odoo/tests/common.py#L1038

runbot-238369

Revert of https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 and
https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8

**Steps to reproduce**
1. Remove the company of the Working Schedule (needs to be done in
a multi-company environment from the UI) used by an employee.
2. Using the company of this employee, create a Public Holiday
(for the employee's schedule or all schedules).

Issues:
- the public holiday doesn't appear in the Time Off dashboard
- when taking a time off on that day, the public holiday is
included in the duration

**Cause**
After the fix in https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 , it will lead
to a search domain for public holidays of `('company_id', 'in', [False])`
when the working schedule has no company, ignoring any public
holidays with a company set. This is especially problematic since the
company of the public holiday is always forced.
https://github.com/odoo/odoo/blob/7bce5f3f95429a4d4ba034a66c350ee2a5868567/addons/resource/models/resource_calendar_leaves.py#L49-L51

**Solution**
Since the intent of the original fix https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8
was to correct an issue related to the computation of some `project.task`
fields calling a resource method (`get_work_duration_data`), we can revert
the fix and later fix the original issue directly in `project`, without
impacting `hr`/`resource` modules.

opw-5496999
opw-5401425

### Issue:
When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date.

### Steps to reproduce:
- Install 'sale_subscription'
- Create a new Subscription with two lines and a tart data several months in the past
- One with a quantity of 1 and a higher price
- The other with a quantity of -1
- It can be the same service product with invoicing based on ordered quantity
- Confirm the Subscription
- Click "Create Invoice" and confirm the invoice
- Back to the Subscription, the next invoice date was not updated.

### Cause:
In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131

So the method will return not return the date in `invoice_dates`.

Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67

### Solution:
The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds.

To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund.

opw-5360930