Versions
--------
- 17.4+

Steps
-----
1. Configure UoM decimal accuracy to be 0 digits;
2. create, confirm a SO;
3. create a downpayment invoice;
4. go back to the SO;
5. modify the product line's price.

Issue
-----
> AssertionError: precision_rounding must be positive, got 0.

Cause
-----
When checking for quantity changes to log on `write`, a fallback rounding value is retrieved using `precision_get`. This returns a `precision_digits` value, but is being used as a `precision_rounding` value, resulting in an error when it is 0.

In previous versions, this fallback value was never used, as `display_type` lines were skipped, and any other line is guaranteed to have a `product_uom.rounding` value.

As of 9aa52dd6418e, the constraint was changed for `is_downpayment` lines not having to be of `display_type` nor require a `product_uom` value, meaning the faulty fallback value now gets used.

Solution
--------
Remove the fallback value, and only log lines with a `product_uom` value.

opw-4566621

Forward-Port-Of: odoo/odoo#205581

**Steps to reproduce:**
- Install l10n_it_edi_ndd
- Switch to an Italian company (e.g. IT Company)
- Create an invoice
- Confirm the invoice
=> Document Type (in "Electronic Invoicing" tab) is computed
- Create a credit note from the invoice
- On credit note wizard, click on "Reverse and Create Invoice"
- Check the created credit note

**Issue:**
The credit note is posted but its Document Type field (l10n_it_document_type) is empty.
l10n_it_document_type should be computed when it doesn't have a value already and the state of the move is "posted".
The credit note will be rejected when sent to SDI because this field is empty.

**Cause:**
In the reverse method, the field is set to False in order to be recomputed.
However, the compute method is triggered when the state changes, but the credit note not is already posted.
Therefore the field will not be recomputed.

**Solution:**
Set the value to False before the creation of the credit note.
So that, the field will be recomputed when posting the credit note.

opw-4689755




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

Forward-Port-Of: odoo/odoo#208654

Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts.
Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions.

Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail.

We revert the recent commit https://github.com/odoo/odoo/commit/a6787552150434d4366e30cbeb6f6d309c2c6cb9 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions.

Forward-Port-Of: odoo/odoo#209960
Forward-Port-Of: odoo/odoo#208876

Another fix is added here:

The domain field passes a new prop allowExpressions to the domain selector. If that prop is false (default true), the within operator is not proposed for selection for date/datetime fields. This is done to prevent users to introduce expressions in their domains when they are not supported.

The _compute_l10n_mx_edi_cfdi_cancel_id method is calling the following search

https://github.com/odoo/enterprise/blob/fd01cf3d57109424725727d7eb40afbe34ef67a9/l10n_mx_edi/models/account_move.py#L685-L691

```python
    move.l10n_mx_edi_cfdi_cancel_id = move.search([
        ('l10n_mx_edi_cfdi_origin', '=like', f'04|{move.l10n_mx_edi_cfdi_uuid}%'),
        ('company_id', '=', move.company_id.id)],
        limit=1,
    )
```

It is generating the following sql query

```sql
    SELECT id
    FROM account_move
    WHERE l10n_mx_edi_cfdi_origin :: text LIKE '04|55555-5555-5555-5555-555%'
        AND company_id = 1
    ORDER BY date DESC, 
        name DESC, 
        invoice_date DESC, 
        id DESC 
    LIMIT 1
```

Running a analyze for a database with ~7M of `account_move` records the result is

```txt
    Limit  (cost=73029.67..137055.68 rows=1 width=26) (actual time=1610.419..1637.035 rows=0 loops=1)
    ->  Incremental Sort  (cost=73029.67..649263.71 rows=9 width=26) (actual time=1600.475..1627.091 rows=0 loops=1)
            Sort Key: date DESC, name DESC, invoice_date DESC, id DESC
            Presorted Key: date
            Full-sort Groups: 1  Sort Method: quicksort  Average Memory: 25kB  Peak Memory: 25kB
            ->  Gather Merge  (cost=1000.46..649263.30 rows=9 width=26) (actual time=1600.466..1627.082 rows=0 loops=1)
                Workers Planned: 2
                Workers Launched: 2
                ->  Parallel Index Scan Backward using account_move__date_index on account_move  (cost=0.43..648262.24 rows=4 width=26) (actual time=1586.469..1586.469 rows=0 loops=3)
                        Filter: (((l10n_mx_edi_cfdi_origin)::text ~~ '04|55555-5555-5555-5555-555%'::text) AND (company_id = 1))
                        Rows Removed by Filter: 2274213
    Planning Time: 0.197 ms
    JIT:
    Functions: 13
    Options: Inlining false, Optimization false, Expressions true, Deforming true
    Timing: Generation 3.044 ms, Inlining 0.000 ms, Optimization 2.327 ms, Emission 34.202 ms, Total 39.574 ms
    Execution Time: 1637.815 ms
```

PostgreSQL query stats from production returns the following top 1 slow query

```txt
Total Time  Average Time   Calls
4,981 min   1,351 ms       221,238
    SELECT "account_move"."id"
    FROM "account_move"
    WHERE (("account_move"."l10n_mx_edi_cfdi_origin"::text LIKE $1)
            AND ("account_move"."company_id" = $2))
            AND (("account_move"."company_id" IN ($3)) OR "account_move"."company_id" IS NULL)
    ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC
    LIMIT $4
```

Creating the following index

```sql
    CREATE INDEX account_move_l10n_mx_edi_cfdi_origin_index
        ON account_move (l10n_mx_edi_cfdi_origin)
        WHERE l10n_mx_edi_cfdi_origin IS NOT NULL
```

Similar to define the field `account_move.l10n_mx_edi_cfdi_origin(index='btree_not_null')`

The same query analyze result is

```txt
    Limit  (cost=4.49..4.49 rows=1 width=26) (actual time=0.018..0.018 rows=0 loops=1)
    ->  Sort  (cost=4.49..4.51 rows=9 width=26) (actual time=0.017..0.017 rows=0 loops=1)
            Sort Key: date DESC, name DESC, invoice_date DESC, id DESC
            Sort Method: quicksort  Memory: 25kB
            ->  Index Scan using account_move_l10n_mx_edi_cfdi_origin_index on account_move  (cost=0.42..4.44 rows=9 width=26) (actual time=0.011..0.012 rows=0 loops=1)
                Index Cond: (((l10n_mx_edi_cfdi_origin)::text >= '04|55555-5555-5555-5555-555'::text) AND ((l10n_mx_edi_cfdi_origin)::text < '04|55555-5555-5555-5555-556'::text))
                Filter: (((l10n_mx_edi_cfdi_origin)::text ~~ '04|55555-5555-5555-5555-555%'::text) AND (company_id = 1))
    Planning Time: 0.147 ms
    Execution Time: 0.036 ms
```

It is ~9k times faster

Forward-Port-Of: odoo/enterprise#85427

Steps to reproduce:
(thanks to TBS for investigating + writing the test)

1. Have a MX company with Quadrum or SwSapien
2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN`
3. Create a USD invoice for `13220.00 USD` and send CFDI
4. Reconcile transaction and invoice
5. Click "Update payments" on the invoice => CRP20211

Looks like it comes from this rounding difference

Rate is computed by odoo using
`305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD`

PAC verify the amount paid using
`13220.0 USD * 23.082262 MXN/USD = 305147.50 MXN` which is not `305147.51 MXN`

Solution:
There is no solution by adapting the rate:
- quadrum restricts the rate to 6 decimals;
- rounding the rate differently (e.g. to `23.082263`) would not help because `13220.0 USD * 23.082263 MXN/USD = 305147.52 MXN` which again is not `305147.51 MXN`.

So, the only solution that I can think of is to adapt the amount in company currency so that it is exactly
`round(amount_in_payment_curr / rate_rounded_to_6_decimals)`, i.e. in the example, change it to `305147.50 MXN`.

In tests, both Quadrum and SwSapien seem to accept this.

We don't perform the modification for Solucion Factible (the other PAC).

opw-4222310

Forward-Port-Of: odoo/enterprise#85602
Forward-Port-Of: odoo/enterprise#83499

## Version:
17.0+

## Issue:
Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal.

## Steps to reproduce:
Ensure Stripe is well configured in `Test Mode` with `Credentials`; Create a new Sale Order with `Monthly Cleaning` as `Quotation Template` for any customer:
- Under `Other Info` tab, change the `Subscription` `Start Date` for a date at least 2 days before current date;
- Confirm and create regular invoice:
  - Set `Invoice Date` to the same date as the subscription;
  - Confirm and go to the invoice's preview and start payment process:
    - Use a new card for payment;
    - Check `Save my payment details` checkbox and pay.

## Cause:
The Stripe mandate needs to be filled with a start date at least equal to yesterday (https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-mandate_options-start_date). Subscription app sets the start date to the SO's `start_date` via https://github.com/odoo/enterprise/blob/5642ad28919081a44bb47c0d936aa51980178d09/sale_subscription/models/payment_transaction.py#L51-L52. The values are retrieved by `_stripe_prepare_mandate_options()` via https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L206 and sent to Stipe under a new structure given by https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L209-L220

## Fix:
Initial suggestion made in the `payment_stripe` module (https://github.com/odoo/odoo/pull/207451), but later moved to the origin of the issue. As of 2025-05-12, Stripe seems to have fixed the issue, but this patch is still applied as a safety measure.

opw-4654142

Forward-Port-Of: odoo/enterprise#85554
Forward-Port-Of: odoo/enterprise#85314