[Adoption of Owl v3.0.0-alpha.42] in Odoo codebase introduced timing
differences when mounting a new App (sub-)root. This timing difference could
cause a crash when mounting an embedded component in a html field, if the main
App switched view away from the field where embedded components were waiting for
their root to prepare, the root host wouldn't be in the DOM anymore, but the
code would still try to mount these components.

To avoid the issue, this commit makes use of `onBeforeComplete` to abort a
pending mount if the owner instance (Component, editor plugin, ...) was
destroyed before the mount could be initiated. This is the best strategy to
silently ignore crashes caused by premature destruction of an ancestor while
still keeping errors thrown when the host was removed from the DOM for other
reasons that may need investigation. Aborting when the host is disconnected is
the best strategy to avoid the crash entirely, but then we might miss those
other reasons.

[Adoption of Owl v3.0.0-alpha.42]: https://github.com/odoo/odoo/commit/acb95b28ab807b37ee86b381b555e38fae36ae93

runbot-944116

Forward-Port-Of: odoo/odoo#284206

### Issue:
The mega menu position is inconsistent between the two "Sub Menus"
options.

With "On Click", the mega menu opens below the navbar, which is its
default position. With "On Hover", it opens directly below the mega menu
toggle, making it visually misaligned with the "On Click" behavior.

### Reason:
The different positioning for "On Hover" was intentional. If the mega
menu were placed in its default position, the gap between the toggle and
the mega menu would cause the cursor to briefly leave both elements
while moving between them, unintentionally closing the mega menu. To
prevent this, the mega menu was positioned directly below the toggle,
removing that gap.

### Fix:
Restore the mega menu to its default position for "On Hover" to match
the "On Click" behavior.

To prevent the original issue of the mega menu closing while the cursor
travels from the toggle to the mega menu, introduce an invisible hover
bridge. The bridge is implemented as a pseudo-element of the mega menu
toggle, ensuring the cursor never leaves the hover area while crossing
the gap.

For header templates, such as "Menu - Sales 1" and "Menu - Sales 4", the
hover bridge overlaps interactive content in the navbar. To avoid this,
position the mega menu below the menus container instead of below the
navbar for these specific headers in both "Sub Menus" options.

This results in a consistent mega menu position while preventing
unintentional menu closure during cursor movement.

task-[6116253](https://www.odoo.com/odoo/all-tasks/6116253)

Co-authored-by: Arib Ansari <<aans@odoo.com>>



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

Step To Reproduce:
- install `sale_management` and `website_sale_collect` and POS with demo
- go to shop page, add a product -> checkout 
- Use `Pick Up in Store` feature and `Pay on site` payment method -> confirm
- notice a Sale order is created for this
- Open POS, try to fulfill the linked SO, by clicking on `Quotation/Order`
 
 Observation:
- The SO is  not visible in the list view

Cause:
-  clicking on `Quotation/Order` initiates a search with domain  `["amount_unpaid", ">", 0]`
https://github.com/odoo/odoo/blob/21e3b547e486951421e39733c19a8a2d54361e00/addons/pos_sale/static/src/app/components/screens/product_screen/control_buttons/control_buttons.js#L16

-  `amount_unpaid` depends on `amount_paid` which is sum of all transaction in ("authorized", "done") state
https://github.com/odoo/odoo/blob/21e3b547e486951421e39733c19a8a2d54361e00/addons/sale/models/sale_order.py#L913-L916

- after commit [1],  transactions with payment method  of type `postpaid`  are considered as `done` (`Pay on site` is  postpaid)

https://github.com/odoo/odoo/blob/21e3b547e486951421e39733c19a8a2d54361e00/addons/website_sale_collect/models/payment_method.py#L9-L14

https://github.com/odoo/odoo/blob/21e3b547e486951421e39733c19a8a2d54361e00/addons/payment_custom/models/payment_transaction.py#L40-L41
- this makes `amount_paid ` to be full  order amount and  `amount_unpaid = 0` for the order and search fails in pos
[1] https://github.com/odoo/odoo/commit/9d01784fa9980fb9e4989e6e4e9f35909665e6ca

Fix:
- Fix the compute of `amount_unpaid` and do not count transactions amount from 
postpaid payment method

Note: issue occurs for POS only, hence, we avoid changing anything from sale side
while keeping changes to minimum


opw-6424288

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

Forward-Port-Of: odoo/odoo#280864

Steps to produce:
---
- Install `sale_management` and `sale_loyalty` module without demo.
- From sales > products > discounts & loyalty, create new loyalty card program and save.
- Now create new product of 100$.
- Create a user which have sales rights as `user: own documents only`.
- With that user, create new sale order with product and confirm.
- Try to cancel the order.

Issue:
---
- It shows the access error: 
```py
You are not allowed to delete 'Sale Order Coupon Points - Keeps track of how a
 sale order impacts a coupon' (sale.order.coupon.points) records.

This operation is allowed for the following groups:
	- Sales/Administrator

Contact your administrator to request access if necessary.
```

Root cause:
---
- Users with the `Sales: Own Documents Only` access right only have read permissions ([1]). When they cancel a Sales Order, the `_action_cancel` method attempts to clean up the temporary pending points allocated to the order by calling `self.coupon_point_ids.unlink()`. Because this call is executed without elevated privileges, the system blocks the deletion and raises an Access Error

Solution:
---
- Added `.sudo()` to the `unlink()` call for `coupon_point_ids` in the `_action_cancel` method. This ensures the pending point records are cleaned up with the necessary elevated privileges.

[1]https://github.com/odoo/odoo/blob/23af2b443735c6d3a2f64e44f9ea5da45638b052/addons/sale_loyalty/security/ir.model.access.csv#L16

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

Forward-Port-Of: odoo/odoo#284122
Forward-Port-Of: odoo/odoo#281477

**Setup**

* Increase the debounce time of `debouncedSynchronizeLocalDataInIndexedDB` to **5 seconds** to reproduce the issue deterministically.
* Configure a restaurant with **Self Ordering** enabled (`QR Menu + Ordering`).
* Configure **Mollie** as the **only** online payment method.

**Reproduction**

1. Place a **takeout** order through the mobile menu.
2. Select a pickup time, enter the required customer information (including a mobile number), and proceed to the payment page.
3. Verify from the backend that the draft order contains the expected data (customer/partner and `preset_time`).
4. Press the browser **Back** button to return from the payment page.
5. Check the draft order in the backend again.
[video](https://drive.google.com/file/d/1kNWpYuo79mYMV3eMelwJ5IDFeWUc7zsD/view)


**Observed result**

* The draft order loses its previously synced information. In particular, the **partner/customer** data (and other synced fields such as `preset_time`) are removed.

**Expected result**

* Returning from the payment page should not modify the draft order. All previously synced data should remain intact.

**Cause**
- When there's only a single payment method, it's [auto-selected](https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/pos_self_order/static/src/app/pages/payment_page/payment_page.js#L21-L22) and `checkAndOpenPaymentPage` immediately opens the payment page via[ window.open()](https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/pos_online_payment_self_order/static/src/app/pages/payment_page/payment_page.js#L35).
- The order's local data is saved to IndexedDB on a 300ms debounce. If the redirect fires before that debounce completes, the save is cancelled, leaving IndexedDB out of sync with the in-memory order

**Fix**
  - Before opening the payment URL, explicitly flush the order to IndexedDB using
  the `synchronizeLocalDataInIndexedDB`, ensuring the local data is persisted
  before the page navigates away.


opw-6231478

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

Forward-Port-Of: odoo/odoo#283800
Forward-Port-Of: odoo/odoo#272724

Payslips in Belgium must be printed in two languages (DMFA location and employee). However, the translation didn't seem to work as intended and there was an awkward mix of languages across both reports and views.

While printed reports showed the payslip lines correctly translated, their labels and title stayed in the employee's language, and worked days reflected the active user's language. In backend views, the title used the employee's language, the lines used the DMFA language, and worked days used the active user's language.

This behavior was caused by context language overriding and how the names were handled:
- The XML report templates explicitly forced the language context to the employee's language, bypassing the Python logic that already set the correct environment language before rendering the templates. This is why the static text of the report stayed in the employee's language.
- The `name` fields on `hr.payslip.line` and `hr.payslip.worked_days` acted as editable virtual related fields fetching a string from `salary_rule_id` or `work_entry_type_id`, with additional logic. Fields like that cannot be translated directly, and they were not being recomputed when the environment language changed (impossible for a stored field anyway). As a result, they were locked in the language they were first created in.
- In Python, the language context was manually forced during line evaluation to the employee's language (or DMFA language in Belgium) specifically to populate those stored `line.name` fields upon creation. Combined with how the `name` field was defined, this locked the strings shown in backend views to that initial DMFA language.
- To translate lines in reports despite those locked values, the XML templates used a workaround: checking if the slip was translated to print the translatable `line.salary_rule_id.name` instead of `line.name`. This explains why the payslip lines were the only part of the report that was translated correctly.
- The payslip's `name` field was also a stored computed field that explicitly forced the employee's language both when translating the title string and when formatting period dates.

Besides fixing the translations on printed reports, we decided it makes more sense for backend views to have everything in the active environment language. To fix this consistently across both views and reports, this commit applies the following changes:
- Removed context language overrides from all report templates.
- Removed the helper method forcing language context during computation.
- Introduced a `custom_name` field on `hr.payslip.line` and `hr.payslip.worked_days`.
- Made the `name` fields on `hr.payslip.line` and `hr.payslip.worked_days` non-stored computed fields depending on context language. They now return `custom_name` if set, or dynamically recompute the translated default string. The inverse method saves manual user edits to `custom_name`.
- Cleaned up the reports to simply print the `name` field of each payslip line, removing the fallback workaround logic.
- Updated the payslip's `name` field compute method (and date formatting helpers) to rely and depend on `self.env.lang` instead of the employee's language. Made this `name` field non-stored as well: storing it was useless since it was not editable in the form view (only `title` is), and would have prevented recomputation based on environment language changes.
- Adapted the rest of the code, including half-day management in Belgium by adding a new `l10n_display_half_day` field to properly compute the name like before.
- Deleted every assignment for the `name` fields that are now unstored.

See odoo/upgrade#11092

Task-6432137

**Steps to reproduce:**
* Install the **l10n_co_dian** module.
* Go to **Settings** and, under **Colombian Electronic Invoicing**:
  * Disable **Testing Mode**.
  * Enable **DIAN Demo**.
* Create a vendor bill with a tax and confirm it.
* Click **Acknowledge Reception**.
* Click **Receive Goods**.
* Click **Accept**.
* From the gear menu, click **Print → Invoice PDF**.

**Observed behavior:**
* A server error is raised:
```
lxml.etree.XMLSyntaxError: Start tag expected, '<' not found, line 1, column 1
```
* The PDF cannot be generated.

**Cause (two-step):**
1. **ZIP not unwrapped:** The original code called `etree.fromstring(self.l10n_co_dian_attachment_id.raw)` directly for all move types. For vendor bills (`in_invoice`) the attachment is stored as a ZIP file, so `raw` is compressed binary data — not XML. Passing it to `etree.fromstring` directly produces the `XMLSyntaxError` above.
2. **AttachedDocument wrapper not unwrapped:** Once the ZIP is correctly decompressed with `xml_utils._unzip`, the resulting XML is an `AttachedDocument` wrapper, not a plain `Invoice`. The actual invoice XML is embedded as CDATA inside `cac:Attachment/cac:ExternalReference/cbc:Description`. `_get_qr_code_value` expects the inner document and searches for nodes like `cac:AccountingSupplierParty`, `cac:LegalMonetaryTotal`, and `sts:QRCode` — none of which exist on the outer wrapper, so the QR code was blank or the method crashed.

**Fix:**
* In `_l10n_co_dian_get_invoice_report_qr_code_value`, for vendor bills (`in_invoice`/`in_refund` without support document), unzip the attachment and immediately attempt to extract the inner invoice XML from `cbc:Description` using `findtext('.//{*}Description')` (lxml namespace wildcard). If the node is present, parse its text as the actual document; otherwise fall back to the unzipped bytes directly.

**Note:**
* A unit test for the `AttachedDocument` unwrapping path was not added because the test would require a zipped fixture file (the vendor bill attachment is stored as a ZIP) which is not appropriate to commit.
* A regression test was added in `test_accept_by_customer`: after the full commercial event flow the method is called inside a `try/except etree.XMLSyntaxError` block so that any XML parse failure surfaces as a proper test *failure* rather than an unhandled test *error*.

opw-6417422

Forward-Port-Of: odoo/enterprise#128908
Forward-Port-Of: odoo/enterprise#126463