**Step to reproduce:**
- install "l10n_es_edi_verifactu_pos"
- setup "ePOS printer" for a pos
- open pos and settle a order below 400$
- notice we get l10n_es_edi_verifactu_qr_code in our receipt
- click on "Print receipt"
- repeat above steps for one more order

**Observation:**
- when we print the second order receipt, the QR still points to 1 order invoice

**Issue:**
- [getCacheKey](https://github.com/odoo/odoo/blob/0cee3350df09b06af77c879f0eba74bf6a8dd2c9/addons/point_of_sale/static/src/app/utils/html-to-image.js#L351C10-L355
) was trimming query strings when generating cache keys. URLs like:
`  http://localhost:9000/report/barcode/?barcode_type=QR&value=... `
were reduced to:
`  http://localhost:9000/report/barcode/`

- As a result, different QR code requests shared the same cache key. Subsequent requests reused the previously cached image instead of fetching a new one, producing incorrect QR codes for different orders.

**Solution:**
Add an `includeQueryParams` flag to `resourceToDataURL` so the full URL, including query parameters, is used as the cache key when needed. This ensures unique QR code URLs are cached and fetched correctly.

opw-5455807


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

Forward-Port-Of: odoo/odoo#251139

How to reproduce :
- Create a product
- Create an attribute with a value set to "free text"
- Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name
- Put Dropship as the route for the product to create a PO on a SO confirmation
- Create a SO with that product
- Confirm the SO and go to the PO
- Change the vendor in the SO

The problem :
The Vendor Code and/or Vendor Name does not change correctly in the product description

Why :
The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user.

This logic is pretty broken because the code that generate the description when going from a PO to a SO and the code that generate the description when changing the PO partner are different. This makes it so the current description is almost never found in the list of default descriptions.

It looks tempting to try to "resynchronize" those part of the code so the description generation is the same in both cases. This would be done by overriding the _get_product_purchase_description method in the purchase_stock module and using the product_description_variants field. Sadly, this does not work because it conflicts with the purchase_product_matrix module and its own override of that method.

The fix that I implemented checks that the Vendor Code and Name are the right one every time the description is computed following a change.

opw-5888233

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

Forward-Port-Of: odoo/odoo#256665
Forward-Port-Of: odoo/odoo#247330

`has_published_products` was previously computed recursively. For recursive fields, the ORM disables prefetch optimizations.

In 3ffca1961cb1671e7028dd4dceca82d2e74a2e21, the computation switched to `_read_group` to avoid loading all published products into cache and prevent memory issues. However, this introduced an N+1 pattern when evaluating:
```python
categories.filtered(lambda categ: categ.has_published_products)
```

As a result, query count became dependent on the number of active categories, which broke SQL performance tests when demo data were installed.

This commit updates the computation again to avoid recursion and restore ORM prefetch optimizations, making the number of queries independent of the number of active categories.

This commit also removes redundant checks already enforced by ORM `ir.rule`. For example, the following pattern evaluates `has_published_products` three times: once in the user domain, once in the access rule domain added by `search`, and once in the filter.
    
```python
domain = [("has_published_products", "=", True)]
categs = self.env["product.public.category"].search(domain)
categs.filtered("has_published_products")
```

runbot-234948

Forward-Port-Of: odoo/odoo#256664
Forward-Port-Of: odoo/odoo#256415

**Steps to reproduce:**
- Install Mail Marketing app
- Change user language to a RTL language (such as Arabic)
- Create a marketing campaign with RTL content
- Send it
- Mail received changes from RTL to LTR

**Issue:**
Conversion doesn't take into account the current
language direction anymore when creating the inline
styling. This keeps the mails in the default format ('ltr').

Previously the inline conversion was using the `/portal/static/src/scss/portal.scss`
to set the html body text direction using the `rtlcss` library:
```css
 // Frontend general
body {
    // Set frontend direction that will be flipped with
    // rtlcss for right-to-left text direction.
    direction: ltr;
}
```
It was used during the inline conversion in a `CSSStyleRule`
after loading the doc sheets, and added with the `.o_layout` selector:
```js
if (selector === "body") {
    // The top element of a mailing has the class
    // 'o_layout'. Give it the body's styles so they can
    // trickle down.
    cssRules.push({
        selector: ".o_layout",
        rawRule: subRule,
        specificity: 1,
    });
}
```
But recent refactor reworked the styling assets used by
this process, which removed this behavior.

**Fix:**
Keep style `direction` (instead of `dir` attribute) like
before, to avoid compatibility issues in mail engines.
This is done by reapplying the body rule on the
mass_mailing iframe styling, but it could also be manually
added to the fragment itself using the editor current config
or localization.

related: https://github.com/odoo/odoo/commit/354b8f60dbabcfac690d90bf657592e1347e4f86

opw-5982854

Forward-Port-Of: odoo/odoo#255628

When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created `ir.attachment` through the original RO/replica env.

In a primary/replica setup, replication may not have caught up yet, so the new attachment is not visible on the replica. As a result, readonly `/web/assets/...` requests can fail right after asset regeneration when fetching the freshly generated bundle.

Steps to reproduce:
1. Configure Odoo with a PostgreSQL primary/replica setup.
2. Open a website in edit mode.
3. Trigger an asset regeneration (for example by changing a theme color).
4. Let the resulting readonly `/web/assets/...` request fetch the freshly generated bundle.

Build the response stream from the RW env after regeneration instead of rereading the fresh attachment through the RO/replica env.

opw-6034833

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

Forward-Port-Of: odoo/odoo#255530

The fix introduced in https://github.com/odoo/odoo/pull/216737 can lead to "over-eager" filtering when an external email address matches a localpart (left part) alias in a input email list contains internal emails (aliases to filter) AND external email addresses (should not be filtered).

The `_find_aliases` method is used to identify internal system emails (aliases, bounces, catchalls) to prevent mail loops and ensure correct recipient filtering during notification grouping.

Before this fix, when the `mail.catchall.domain.allowed` system parameter was set, the logic for local-part aliases (where `alias_incoming_local` is True) failed to correctly associate the local part with the allowed domains. This resulted in external email addressed being returned by the system, potentially leading to incorrect notification routing.

We now use a more robust approach:
- Pre-filter local parts based on the allowed domains to reduce DB load.
- Utilize Python Sets for O(1) lookups of static and local aliases
- Explicitly validate the (local_part, domain) combo during the final filtering.

Example Scenario:
- Config: mail.catchall.domain.allowed = "test1.com,test2.com"
- Alias: "info" (alias_incoming_local=True)
- Input: ["info@test1.com", "info@test3.com"]

### Output Before Fix:
["info@test1.com", "info@test3.com"]
(The function failed to recognize info@test3.com as an external alias to be ignored based on the `mail.catchall.domain.allowed` config)

### Output After Fix:
["info@test1.com"]
(Correctly identifies the internal alias tob filtered while ignoring the external one)


OPW-5469264
OPW-5504201

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

Forward-Port-Of: odoo/odoo#244272

## Issue:
When viewing purchase order lines, the system attempts to compute the unit
price for downpayment lines. This results in unintended behavior.

## Cause:
PR https://github.com/odoo/odoo/pull/236669 introduced the `price_unit_product_uom` field 
along with its compute method `_compute_price_unit_product_uom` to manage PO comparison.
Although the compute method correctly skips section and note lines, it does
not exclude downpayment lines. Downpayment lines are identified by the
`is_downpayment` field, which was introduced earlier in PR https://github.com/odoo/odoo/pull/176137.
As a result, the computation is incorrectly applied to downpayment lines.

## With this commit:
The UoM price computation is prevented for purchase order lines where
is_downpayment is set to True. Downpayment lines are now treated
similarly to section and note lines to prevent unintended price recalculations.

Steps to reproduce : [Video](https://drive.google.com/file/d/1JrMN8x-i86QjRfMnaeYu-Jac03iFoJs3/view?usp=drive_link)

OPW - 5930652

Forward-Port-Of: odoo/odoo#249989

[FIX] website_profile, gamification: fix weekly/monthly leaderboards

Prior to this commit, the leaderboard pagination logic was flawed when
filtering by specific time periods (e.g., "This Week" or "This Month").

The system would first retrieve users sorted by their *all-time* global
karma, apply pagination (taking the top X users), and only then calculate
the karma gain for the specific period for those few users.

This caused users with high recent activity but low all-time karma to only
be displayed much later in the page order than they should.

This commit fixes the issue by introducing a pre-search step that
calculates the karma gain for the requested period at the database level.
Pagination is now applied to this specific result set, ensuring users are
correctly ranked by their actual performance during that week or month.

Note: A new method `_get_users_by_tracking_karma_gain` was added to
`res.users` to handle this logic. This approach was chosen to strictly
preserve the signature of existing methods for the stable version.
A distinct refactor to unify these calculation methods is planned for
the master branch.

Steps to reproduce:

- Install the eLearning module.
- Create a few users with different karma_points (more than 25 to have 2 pages).
- Go to /profile/users.
- Group by week.
- Paginate, and you will notice that the order is wrong; the first user on the second page might have more points than users on the first page. Also, when the logged-in user is not on that page, they do not appear at the bottom.

task-5344657
opw-3979785

Forward-Port-Of: odoo/odoo#257210
Forward-Port-Of: odoo/odoo#176626

Currently, the BOE export for `Mod 347` uses incorrect indicators for 
`Substitutive` and `Complementary declarations`.

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`
- Navigate to Accounting > Reporting > Tax Report
- From the smart button, select `Report: Tax Report (Mod 347) (ES)`
- Download the BOE file using the dropdown.
- In the wizard:
  - Enable `Substitutive Declaration` or `Complementary Declaration`
  - Set `Previous Report Number` (e.g., 123456789)
  - Click `Generate BOE`
- Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required)

**Observation:**
AEAT does not recognize 'X' as a valid indicator for substitutive or 
complementary declarations and interprets the file as a standard return.

**Root Cause:**
At [1], the BOE Mod 347 generation writes 'X' for both substitute 
and complementary declarations.

**Fix:**
This commit ensures the file contains correct indicators:
- 'C' for `complementary declarations`
- 'S' for `substitute declarations` 

This aligns Modelo 347 with AEAT specifications and ensures 
consistency with the implementation of Modelo 349 at [2].

Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html

[1]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062

[2]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491

opw-6048711

Forward-Port-Of: odoo/enterprise#112566

### Issue:

The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature.

### Steps to reproduce:

- Have 2 companies: company 1 and company 2
- Set the barcode nomenclature of company 1: default, company 2: GS1
- Incarnate a user allowed in both companies but with default company 1
- With company 2, create a product and set its barcode to 36939282410106
- From the main menu open the barcode app and scan 0136939282410106
#### > No product was found (even thought it is correct in GS1)

### Cause of the issue:

Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 
However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11
As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083
based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722

### Fix:

Setting the company slices the `current_company` in first position of the `allowed_company_ids`:
https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81
which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491
Note that passing the context in the arguments of the `main_menu` JSON  route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f

### Additional Issue:

The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Set the barcode nomenclature to GS1
- Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365
- From the main menu open the barcode app and scan 4133033710074365
#### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination)

opw-5847529

Forward-Port-Of: odoo/enterprise#112478
Forward-Port-Of: odoo/enterprise#111662

Currently, an error occurs when user tries to undo a calendar event.

Steps to replicate:
- Install `appointment` with demo data.
- Navigate to `Appointments > Schedule > Resource Booking`.
- Drag to create a calendar event.
- Reschedule the event to a later time (drag and drop forward).
- Click Undo on the notification that appears.

Error:
`ValueError: Invalid field 'originId' in 'calendar.event'`
`KeyError: 'originId'`

Cause:
- The key `originId` was patched in the `getschedule()` [1] and later when user tried to undo the calendar event, the [fallbackschedule] included the key `originId` and made an [orm] call with it.
- The [line] tries to write the data into the database where `originId` field doesnt exist and causes the error to occur.

Solution:
- Remove the `originId` key from `fallbackdata` before the orm call.

[1]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/appointment/static/src/views/gantt/gantt_renderer.js#L110-L116

[fallbackschedule]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1425

[orm]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1473-L1477

[line]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/models/models.py#L248

sentry-7020359653

Forward-Port-Of: odoo/enterprise#112614
Forward-Port-Of: odoo/enterprise#100570

## Issues
When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears.

Also, recurring plans with their *Company* field set do not appear in the list of recurring plans when adding a line in the *Recurring prices* tab.

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a second company
3. Create a subscription product and set a company in the *Company* field (`company_id`).
4. In the *Recurring prices* tab, add a line (any recurring plan, any price)
5. **An _Invalid Operation_ error appears: _"Uh-oh! You’ve got some company inconsistencies here"_**

For the second issue, after the same 3 first steps:
1. Create a *Recurring Plan* RP with its *Company* field set to the current company
2. On the *Recurring prices* tab of the subscription product, try to add a line with the Recurring plan RP
3. **The Recurring plan RP is missing from the list of available plans.**

## Cause
When adding a line to the *Recurring prices* tab, a new `product.pricelist.item` is created, with no `pricelist_id`. The `ProductPricelistItem._compute_company_id` from `sale_subscription` filters out the items that don't have a `pricelist_id`, which is the case for the line we create. Also, the (potentially new) plan has no `company_id` in most cases.

https://github.com/odoo/enterprise/blob/ccab0c261040ed995d12dca891caae9596bbe1eb/sale_subscription/models/product_pricelist_item.py#L18-L26

By filtering the items with no `pricelist_id`, nothing is passed to the `super()._compute_company_id`, even though it would also handle cases where the item has a `product_tmpl_id`:

https://github.com/odoo/odoo/blob/9c8112d794af1ba84ade8af124967495c2ff8995/addons/product/models/product_pricelist_item.py#L170-L173

opw-5981629
opw-6051978

Forward-Port-Of: odoo/enterprise#109403

Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000.

### **Steps to Reproduce:**
1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 
2) Switch to PK company.
3) Create an employee and a running contract with yearly cost 2,200,001 
4) Create a payslip and compute it from the Salary Computation tab.

### **Observed Behavior:**
'Tax Bracket Yearly' is computed as `122000.24`

### **Expected Behavior:**
'Tax Bracket Yearly' should be `116000.24`

### **Root Cause:**
since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on  [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value.

[official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf)

### **Fix:**
Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket.

**opw-5979265**

Forward-Port-Of: odoo/enterprise#112642
Forward-Port-Of: odoo/enterprise#110939

Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs.

## Steps to replicate:
- Install Inventory
- Go to Settings and enable Multi-Step Routes > Set Warehouse Routes.
- Configure 2 steps for outgoing shipments.
- Go to Inventory and  create a new delivery with
   - **Source Location:** WH/Stock
   - **Product:**  [E-COM10] Pedal Bin with demand 1
- Mark as Todo then Archive the Pedal Bin product.
- Open that delivery in barcode app
- Pencil icon > +1 > Confirm

## Observed behavior:
TypeError: Cannot read properties of undefined (reading 'qty_available')

## Root cause:
After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above.

## Solution:
Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error.

It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button
followed by validation, ensuring consistency.

[commit]:
https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 
[2]-
https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45

opw-5980428

Forward-Port-Of: odoo/enterprise#112616
Forward-Port-Of: odoo/enterprise#109204

A subscription product that has a price of zero on the product form and the price is set on the pricelist instead cannot be added to the cart when the `Prevent Sale of Zero Priced Product` setting is enabled

Steps to reproduce:
1. Install eCommerce and Subscriptions
2. Go to Settings and enable `Prevent Sale of Zero Priced Product`
3. Go to Subscriptions > Products and create a new product "subscription" with Sales Price $0.00 and publish it to the website
4. Go to Subscriptions > Pricelists and edit pricelist "Benelux"
5. In the Recurring Prices tab, create a new entry for product "subscription"  with a Fixed Price of $20.00 and a monthly Recurring Plan
6. Log in as portal user, go to the shop and look for "subscription" (pricelist "Benelux" should be selected)
7. Try to add it to the cart
8. Nothing happens and an error is displayed in the log

Issue:
When we check if a product can be added to the cart https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/controllers/cart.py#L116-L120 we do not use the plan_id specified in kwargs
We reach this code
https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/models/product_product.py#L146-L147 which will prevent the addition of a product in the cart if the option `prevent_zero_price_sale` is enabled and if `_get_contextual_price` returns zero
Calling `_get_contextual_price` tries to find a `product.pricelist.item` by building a domain in `_get_applicable_rules_domain` but calling this method without a plan_id eventually reaches
https://github.com/odoo/enterprise/blob/252c5ab78b51d0d2f06178cf92f0489b4a46958f/sale_subscription/models/product_pricelist.py#L69-L72 which restricts the domain to pricelists that are not subscription plans
Therefore, we cannot find any pricelist that applies to the product and we consider that the product cannot be added to the cart

Solution:
We need to use the plan_id selected by the customer in order to correctly check if a product can be added to the cart.

Use the plan_id in kwargs to update the request context so we can check if a product can be added to the cart according to the plan_id the user has selected. Use this plan_id in `_get_applicable_rules` in order to correctly select the applicable `product.pricelist.item`.

opw-5993614

Forward-Port-Of: odoo/enterprise#111624