**Description**
Opening the Budget Report from any budget record times out on databases
with significant data volume. The request to
`budget.report/formatted_read_grouping_sets` consistently times out,
making the Budget Report completely unusable.

**Root cause:**
`budget.report` is an SQL view that consists of 5 UNION ALL branches.
When the list view loads, the ORM translates the `budget_analytic_id`
domain into a WHERE clause on the outer query wrapping the full UNION
ALL subquery. PostgreSQL cannot push this filter through a UNION ALL as
it's a hard optimization barrier. It must fully materialize the subquery
regardless of which budget is being viewed.

**Fix:**
Override _search on budget.report to extract budget_analytic_id and
budget_line_id conditions from the incoming domain using the Domain API.
budget_line_id is rewritten as Domain('id', op, value) so _to_sql()
correctly emits bl.id in the raw SQL. The resulting domain is injected
in context under budget_line_domain and read in _get_bl_query,
_get_aal_query (base module), and _get_pol_query (purchase module) to
filter budget_line rows inside each branch's LEFT JOIN ON clause.
This also removes the budget_report_budget_line_ids context key from
budget_line._compute_all, unifying both filters under one mechanism.

---

On customer DB (568k `account_analytic_line`, 27k `budget_line`,
116k confirmed `purchase_order_line`, 114k posted vendor bill lines
with purchase link):

| Budget | Before | After |
|---|---|---|
| 8 lines, 730d span | timeout | 2.27s |
| 14 lines | timeout | 2.39s |
| 14 lines, 1095d span | timeout | 1.63s |

- Before: https://explain.dalibo.com/plan/ehed5eb8de251426
- After: https://explain.dalibo.com/plan/db8aef35cag9hg6f

opw-6098047

Forward-Port-Of: odoo/enterprise#120707
Forward-Port-Of: odoo/enterprise#114692

Steps to reproduce:
------------------------------------------------
1. Install Event module
2. Create a multi day event
3. Create one attendee for the event
4. Change the event dates
5. Go to attendee and Click on Send by Email

Observation:
------------------------------------------------
The event start date displayed in the email body is not updated after the event dates are modified.

Issue:
------------------------------------------------
In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58

However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields
https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f

* `event_begin_date` is made stored for cohort view grouping
* However, the base compute method only depends on `event_id` and `event_slot_id`
https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180
* When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`)
* Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work
* Stored computed fields only recalculate when their explicit dependencies change

Solution:
------------------------------------------------
* Corrected the dependencies of `_compute_event_begin_date` to recompute
value on changing the date of the event

opw-6284576

Forward-Port-Of: odoo/enterprise#120184

Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article.

Steps to reproduce:
1. Install `accountant_knowledge`.
2. Create and open a new audit report.
3. Delete all content from article (the root).
4. Click the "Load a Template" button in the helper.

=> Crash with `AssertionError: Invalid falsy real id.`

The issue occurs because the method responsible for loading the annex to display (see: `get_suggested_templates`) expects at least one record in the recordset. When the article has no parent, the recordset is empty, causing the method to fail.

Before attempting to load a template, we will check whether the article has a parent article. If no parent exists, no template will be provided to the template picker. In that case, the picker will display a helper message indicating that no article template is available to load.

Task [link](https://www.odoo.com/odoo/project.task/6333859)
Task-6333859

Forward-Port-Of: odoo/enterprise#121807

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

task-6215466

Forward-Port-Of: odoo/enterprise#124567
Forward-Port-Of: odoo/enterprise#122313

Steps to produce:
---
- Install the `sales` module.
- Create a product and `enable track inventory.`
- Log in as user with only view access rights in products and also have the sales access rights.
- Create a sale order containing product and confirm it.

Issue:
---
-  An access error is raised during order confirmation.

Root cause:
---
- In [commit], to handle inventory tracking, the `qty_available` field
was moved to `product.product`. Unlike before, this value is increased
or decreased depending on the operation performed.

- As a consequence, creating or updating a sale order triggers a write
to this `qty_available` field on the related product. This
write happens under the current user's permissions, so users who
only have read access to products (but can create/edit sale orders)
hit an `AccessError`, since they lack write access on
`product.product`.


Solution:
---
- Use `sudo()` when accessing the required product quantity information
  to ensure the operation can be completed without requiring additional product
  access rights.

The same issue also occurs when confirming a purchase order.

[commit]: https://github.com/odoo/odoo/commit/ca96992919b11105da44238c3e522f8eec4a740b

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

Forward-Port-Of: odoo/odoo#276563
Forward-Port-Of: odoo/odoo#270067

Version:
---------
- 19.0+

Steps to Reproduce:
-----------------------
1. Install sale_management, purchase, stock modules.
2. Create a storable product with Tracking: By Lot,
3. Create two Purchase Orders, each for 10 units.
   Receive PO-1 → 10 units with tagged as lot-1
   Receive PO-2 → 10 units with tagged as lot-2
4. Create two Sale Orders:
   SO-1 → deliver 2 units from lot-1 (validate)
   SO-2 → deliver 4 units from lot-2 (validate)
5. Open Inventory > Reporting > Stock,
   click "Total Value", then check the "Remaining Quantity" column

Issue:
-------
Observed : remaining_qty = 10 for lot-2 receipt, 4 for lot-1 receipt
Expected : remaining_qty = 8 for lot-1 receipt (10−2), 6 for lot-2 receipt (10−4)

Cause:
--------
When the "Remaining Quantity" column is computed, the following call
chain executes:

  stock.move._compute_remaining_qty()
    → calls product.product._get_remaining_moves()
        → calls product._run_fifo_get_stack()   ← HERE is the problem

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L372

`_get_remaining_moves` calls `_run_fifo_get_stack()` with NO lot
argument. Inside `_run_fifo_get_stack`, because no lot is given, it
computes the stack size from the TOTAL product qty across all lots:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L583

  fifo_stack_size = 14   (10 received lot-1 + 10 received lot-2
                          − 2 delivered lot-1 − 4 delivered lot-2)

It then builds a domain to find incoming moves with NO lot filter:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L607

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L614-L618

  ```Domain: [('is_in', '=', True), ('product_id', '=', X)]
  ↳ returns both receipts ordered:
      [lot-2 receipt (10 qty), lot-1 receipt (10 qty)]

then walks this list consuming `fifo_stack_size = 14`:
So it take: [move_lot1_receipt(10)]  First Lot

remaining_qty_on_first = min(10, 14) = 10 
after consuming fifo_stack_size →  14−10=4 left → move_lot1 gets 4
```
So back in `_get_remaining_moves`:

  qty_by_move = {
      lot-2 receipt → 10,   ← wrong (should be 6)
      lot-1 receipt →  4,   ← wrong (should be 8)
  }

- The root cause: `_run_fifo_get_stack` is designed for products that
have one shared FIFO stack. For lot-valuated products, each lot is an
independent inventory layer. Running a single combined stack mixes both
lots together, so the deductions (2 from lot-1, 4 from lot-2) are not
attributed to the correct receipt moves — the algorithm just consumes
from the oldest receipts first with no awareness of which lot was
actually delivered.

Fix:
-----
`_run_fifo_get_stack` already accepts a `lot=` argument that:
- sets `fifo_stack_size = lot.product_qty` (correct per-lot qty)
- adds `('move_line_ids.lot_id', 'in', lot.id)` to the domain
  so only the receipts that touched that specific lot are returned
The only missing piece was calling it per lot instead of once globally.

- With the fix, the stack for each lot is built correctly:
  lot-1: fifo_stack_size = 8 → lot-1 receipt remaining_qty = 8  ✓
  lot-2: fifo_stack_size = 6 → lot-2 receipt remaining_qty = 6  ✓

---

opw-6311341

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

Forward-Port-Of: odoo/odoo#276690
Forward-Port-Of: odoo/odoo#272411

[FIX] fleet: fix vendor bill vehicle association bug

Bug reprod: Go to 19.2 or above

    1 - Go to vendor bills.
    2 - Create an invoice line add vehicle.
    3 - Click to vehicle via the link
    4 - You will see fleet model and try to press to some smart buttons, traceback will occur (Odometer, Services...)

Bug cause:

    1 - When we press to smart buttons for Odometer or Services we are going to return_action_to_open function.
    2 - In this function corresponding action's xml id is calculated and we are calling that action and that will load some view.
    3 - self.env.context is passed directly as a context
    4 - In the view_move_form (That include invoice lines, account_id and vehicle_id fields), account_id has a context list_view_ref="account.view_account_list_from_entry"
    5 - This context is passed in self.env.context and that's why it tries to load this list_view when we press to odometer,service smart buttons, which shouldn't be the case.
    6 - In 19.1 this context is not in self.env.context because >=19.2 m2o_cell_with_extra_m2o_fields is used for account_id and account_id and vehicle_id fields are combined in the single cell.
    7 - That's why the context of account_id is passed to the vehicle page as well.

Bug solution:

    1 - In the return_action_to_open function I'm dropping the list_view_ref context and we can load the correct related views about odometer or service or other ones.

task - 6385611

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#276167

**Purpose of this PR:**

Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages.

<img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23-fe60-4a85-b906-bfec6d235ec5" />

Steps to reproduce:

1. Open Voice & Video Settings.
2. Start the Voice detection sensitivity test.
3. Quickly click Stop immediately after clicking Test.
4. It may take a few tries, but eventually the Voice detection sensitivity indicator remains stuck at the last detected level.

> [!NOTE]
>  this is timing-dependent. A tic message must already be in-flight from the worklet thread when `disconnect()` runs, so it won't happen every attempt.

This race condition existed in the `disconnect` callback of `_loadAudioWorkletProcessor` since #66611, but stayed silent until #183969 introduced the Voice detection sensitivity feature in call settings, exposing it.

This PR clears `port.onmessage` before disconnecting so late tic messages can no longer update the Voice detection sensitivity indicator after monitoring has stopped.

Forward-Port-Of: odoo/odoo#275933

**Steps to reproduce:**
- Create a fiscal position T1, with detect automatically
- Create another one T2, without the detect automatically
- When looking at the fiscal positions list, make sure T1 is on top, followed by T2
- Go to the PoS settings, check flexible taxes
- Put T2 as default and in allowed, don't put T1 in allowed
- Go to the PoS, chose a customer
- The fiscal position is T1 even though it's not allowed

**Why the fix:**

Currently, the fiscal position is chosen like this in order:
- A FP specified on the customer's profile
- A FP detected with the detect automatically setting
- The default FP from the PoS settings

When we have a tie, it's the first one in the fiscal positions list that is chosen.

Before this commit, we did not check that the fiscal position was allowed to be used in the PoS, so we just fetched whatever fiscal position fit the best for a given customer and didn't check if we could actually use it.

We now make sure that the fiscal position we try to use is allowed in the current PoS, and if it's not we fall back to the default one.

opw-6032031

Forward-Port-Of: odoo/odoo#276151
Forward-Port-Of: odoo/odoo#271343

Steps to reproduce:
===================
1. Drop an "Events" block on a website page.
2. In edit mode, try selecting the inner text by clicking multiple times.

=> Uncaught client error: TypeError: Cannot read properties of
   undefined (reading 'nodeType').

Root cause:
===========
When a mouse selection crosses an uncrossable element, the selection restriction plugin moves the focus to the deepest position of the element sibling adjacent to the uncrossable one.

When the first selected node is itself an uncrossable element (event cards are `div` elements) that has no previous/next element sibling, `node.previousElementSibling` is null and `tempFocusNode` was never assigned by a previous iteration, so it is undefined. `nodeSize` then reads `nodeType` on undefined and throws.

The plugin only exists from saas-19.3, which is why the issue is not reproducible on earlier versions.

Fix:
====
When there is no sibling to place the focus on, fall back to the boundary just outside the uncrossable node itself (`leftPos` when selecting left to right, `rightPos` when selecting right to left) instead of calling `nodeSize`/`getDeepestPosition` with undefined.

opw-6362955


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

Forward-Port-Of: odoo/odoo#274739

Before this commit:
- When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`.
- In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. 
- In such situations, Odoo incorrectly imports the document as a credit note.

Technical reason:
- The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund.

After this commit:
- **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note.
- Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes.

Task-6321262

Forward-Port-Of: odoo/odoo#276307
Forward-Port-Of: odoo/odoo#271829

The translate button next to a translatable field saves the record before opening the translation dialog for its id. Since https://github.com/odoo/odoo/commit/a85ca9679e3855936afc66b034d05d75f672dd26 it saves record.model.root rather than the record itself. When the field belongs to a new record still edited inside an x2many, for example an answer added in the survey question popup, saving the root only saves the parent and the new line keeps no database id. The dialog then opens with the id set to false and calls update_field_translations on it, which builds WHERE id = false and the database rejects it with operator does not exist: integer = boolean.

Such a record gets no id of its own, and after a save and reload there is no reliable way to match the saved line back to the one that was clicked, so the dialog can never open for it. A canTranslate getter in TranslationButton returns false for a new record whose model root is another record, which is exactly a line still edited inside an x2many, and the template only renders the button when it is true. The variant in editable lists, where model.root is a list rather than a record, was handled in https://github.com/odoo/odoo/commit/cb34b318004c3ca9db755d8dbbad429609220df3.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app and create a survey
3. Add a question, then in the Answers tab add a line and type a value
4. Click the EN button next to the answer, fill the second language, and Save

=> RPC error operator does not exist: integer = boolean from WHERE id = false

Ticket [link](https://www.odoo.com/odoo/project.task/6260427)
opw-6260427

Forward-Port-Of: odoo/odoo#275401
Forward-Port-Of: odoo/odoo#267781

### Steps to Reproduce:

- Insert text in the editor and select it.
- Open the font size dropdown from the toolbar and select a font size.
- Once editor focus returns to the editable area, type any character.
- Observe that the editor throws a traceback.

### Purpose of this PR:

- When selecting text & changing its font size or font family, typing character deletes selection and empties the formatting element. The editor converts this empty element to a pending format intent, but it previously discarded the format's parameters (like class names, sizes, or font-family names). When editor later tried to apply format to newly typed character, it crashed because properties were undefined.

### Solution:

- Implements a `getProps` method on font-size and font-family format specs to extract their properties before deletion.
- Updates `convertEmptyFormatToPendingIntent` to save these properties.
- Makes `addStyle` robust against empty properties using optional chaining.

task-6377076

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

When the pos_discount module is installed while a session is open (the typical case: the user enables "Global Discounts" in the PoS settings while the PoS is running), `_default_discount_value_on_module_install` skipped the configs having a non-closed session (or any rescue session, even a closed one). Those configs ended up with the Global Discount feature enabled but no `discount_product_id`, and opening the PoS then raised "A discount product is needed to use the Global Discount feature." with no way to recover other than manually re-saving the PoS settings.

The skip was introduced in 13.0 by 4c4adf472453 because, at the time, `pos.config.write()` refused any modification while a session was open, which made the module installation crash. That blanket restriction has since been narrowed to a few specific fields (`module_pos_restaurant`, `payment_method_ids`, `active`), so writing `discount_product_id` on a config with an open session is now perfectly valid.

Remove the obsolete exclusion so that all configs get the default discount product at install time, regardless of their session state.

opw-6385274

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

Forward-Port-Of: odoo/odoo#276537

**Steps to reproduce:**

- Make a product with a category
- In the category, make the inventory valuation to automated
- Set the income and expense account
- Set a cost for the product
- Make a fiscal position and set it as default for the PoS
- In the Account Mapping tab, map the income and expense to two other accounts
- Go to the PoS
- Make a sale for that product, without invoice
- Close the session and in the backend check the session
- Check the journal entries
- The income account has been mapped to the fiscal position's
- The outcome account stayed the same as in the category's

**Why the fix:**

When we invoice an order, the income and expense accounts are immediately updated, in a different place than if it has not been invoiced.

At the session's closure, we update the accounts for every order that hasn't been invoiced. In this flow, the account mapping defined on the fiscal position was not applied, so we took the one defined on the product's category.
The income account was already mapped as we need to do it earlier than the session closure, so it had already been set as the right one before our flow. For the expense account, we only need it at this specific time, so we can map it as the session's closure.

We now map the account depending on the fiscal position if we are able to find one, otherwise, we use the category's default as we did before.

opw-6171677

Forward-Port-Of: odoo/odoo#276715
Forward-Port-Of: odoo/odoo#266700

Steps to reproduce:
- Create a promotions program with a rule granting 1 point per currency unit spent (minimum 2 items and 50.00 spent) and a reward "10% discount on the cheapest product" for 1 point
- Open a PoS session and add 2 products to trigger the program
- Keep adding products to the order

Issue:
A new "10% on the cheapest product" line is added for every product added. In eCommerce and Sales the discount is only applied once.

Cause:
The rule grants far more points than the reward costs, so the reward remains claimable after being applied. The auto-claim loop of `updateRewards` therefore re-applies it on every order change, stacking one discount line per change. The already-applied check in `getClaimableRewards` only covered 'coupons' programs, while `_get_claimable_rewards` in sale_loyalty also skips discount rewards already present on the order lines.

Solution:
When auto-claiming, skip discount rewards that are already applied on the order, unless they belong to a payment program (ewallet, gift card). The reward can still be claimed manually several times through the Reward button by spending more points.

opw-6380421

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

Forward-Port-Of: odoo/odoo#276300

Steps to reproduce:
- Create a partner without pincode
- Create a picking and Challan for that partner
- Click print

Will result in the following traceback-
```py
Traceback (most recent call last):
  File "<1103>", line 710, in template_l10n_in_ewaybill_report_ewaybill_1103
  File "<1103>", line 692, in template_l10n_in_ewaybill_report_ewaybill_1103_content
  File "<1103>", line 674, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_0
  File "<1103>", line 86, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_1
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 727, in _ewaybill_generate_direct_json
    **self._prepare_ewaybill_base_json_payload(),
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 289, in _prepare_ewaybill_base_json_payload
    ewaybill_json = super()._prepare_ewaybill_base_json_payload()
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 669, in _prepare_ewaybill_base_json_payload
    **prepare_details(
      ^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 641, in prepare_details
    f"{place}{key}": fun(partner, place) if key == "StateCode" else fun(partner)
                                                                    ^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 674, in <lambda>
    "Pincode": lambda p: int(p.zip) if p.country_id.code == "IN" else 999999,
                         ^^^^^^^^^^
ValueError: invalid literal for int() with base 10: ''
```
In this commit, we resolve the traceback


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

Forward-Port-Of: odoo/odoo#276180

**Description of the problem**
The age verification popup snippet (`s_age_verification_popup`) does not work properly when dropped into the `#product_details` element of a product page. In particular, the popup is rendered below the blurred background and cannot be interacted with (it should be rendered above the blur instead).

**How to reproduce**
1. Open a product page.
2. Drop `s_age_verification_popup` into the product details.
3. The popup is rendered below the blurred background.

**Why the problem happens**
The `s_age_verification_popup` snippet applies the blur effect to the `#wrapwrap` element. The popup is expected to be rendered above the blur thanks to its `z-index`.
However, `z-index` only applies within the same stacking context. A child element cannot be rendered above elements outside its parent's stacking context, regardless of how high its own `z-index` is. Since `#product_details` has a defined `z-index`, it creates a stacking context. As a result, the popup, which is a child of `#product_details`, is rendered below the blur element.

**Fix**
This commit adds an SCSS rule to `#product_details` so that it no longer creates a stacking context when it contains an open age verification popup. To prevent the stacking context from being created, `z-index` is set to `auto` and `position` to `relative`.

task-6358990

Forward-Port-Of: odoo/odoo#275368

When a push subscription is renewed by the browser (typically every few days), the pushsubscriptionchange event fires and the service worker attempts to re-register the new subscription endpoint via register_devices(). However, the VAPID public key was missing from the request kwargs.

The server-side register_devices() always validates the VAPID key first and raises InvalidVapidError when it is absent. This caused the renewed subscription to never be saved in the database, silently breaking push notifications after the first subscription renewal.

Fix by extracting the applicationServerKey from the new subscription's options and encoding it as a base64url string (without padding) — matching the existing logic in webclient.js _arrayBufferToBase64().

Description of the issue/feature this PR addresses:

Current behavior before PR: Subscriptions don't get renewed causing push notifications to stop eventually.

Desired behavior after PR is merged: Subscriptions get renewed successfully.


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

Forward-Port-Of: odoo/odoo#276085
Forward-Port-Of: odoo/odoo#275217

The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself.

Steps to reproduce:
- Enable Sale Credit Limit in the settings of My Company (San Francisco)
- Set a Credit Limit of 100 on a customer, e.g. Deco Addict
- Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected
- Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies
- Open the same quotation again => The warning banner is gone, although neither the quotation nor the
   customer changed

The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one.

Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company.

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

Forward-Port-Of: odoo/odoo#276917
Forward-Port-Of: odoo/odoo#276308

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

Task [link](https://www.odoo.com/odoo/project.task/6215466)
task-6215466

Forward-Port-Of: odoo/odoo#276763
Forward-Port-Of: odoo/odoo#273129