Steps to print the check:
1. Ensure l10n_us_check_printing is installed
2. Set the check layout to Print Check (Middle) - US in the settings
3. Create a PO and a bill from it.
4. Create a payment for the bill using checks as your payment method
5. Click Print Check on the payment

The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number.
Before the fix, the checks printed the vendor's name in the stubs, and the date alignment in the (middle) format overlapped with the check number.

After the fix, the checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas.

opw-4557006
opw-4738359
odoo PR: https://github.com/odoo/odoo/pull/208357

Forward-Port-Of: odoo/enterprise#85578
Forward-Port-Of: odoo/enterprise#84644

Issue 1:
===
Steps to reproduce:
-------
- Install `pos_restaurant`.
- Open a restaurant session and the preparation display.
- Open any table and add two combo items.
- Press the order button and go to the preparation display.

Issue:
-------
- The combo items do not appear, and the stage cannot be changed.

Cause:
-------
- The combo parent order line does not have an `id`.
- Since there are two combo parents, the `t-foreach` encounters multiple lines with the same `undefined` id.

Fix:
-------
- Use `orderline_index` instead of `orderline.id`..

Issue 2:
===
Steps to reproduce:
-------
- Install `pos_restaurant`.
- Open a restaurant session and the preparation display.
- Open any table and add an order line.
- Press the order button so the line appears in the preparation display.
- Remove the line and press order again to cancel it.
- Go to the preparation display.
- Click on the cancelled order line.
- A traceback appears.

Issue:
-------
- You are unable to strike out the cancelled order line.

Cause:
-------
- When all quantities of a prep line are cancelled, there are no corresponding `pos_order_line_id` available.
- The code attempts to compute `order_completion_seconds` using `max()` on an empty list, which raises a `ValueError`.

Fix:
-------
- Added a guard condition to ensure `completion_time` is only computed when there is `pos_order_line_id`.
- This prevents calling `max()` on an empty sequence and avoids the traceback when clicking cancelled lines in the preparation display.

Task: 4800284

Forward-Port-Of: odoo/enterprise#85698

## 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#85813
Forward-Port-Of: odoo/enterprise#85314

When user quickly presses the ``Enter`` key multiple times to record a timesheet,
A traceback will appear.

Steps to reproduce the error:
- Go to Timesheets > My Timesheets
- Now, Quickly press the ``Enter`` key multiple times to record a timesheet

Traceback:
```
ValueError: Expected singleton: timer.timer(1, 2)
  File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 433, in action_start_new_timesheet_timer
    timesheet.action_timer_start()
  File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 460, in action_timer_start
    super().action_timer_start()
  File "home/odoo/src/enterprise/18.0/timer/models/timer_mixin.py", line 86, in action_timer_start
    self._stop_timer_in_progress()
  File "home/odoo/src/enterprise/18.0/timer/models/timer_mixin.py", line 140, in _stop_timer_in_progress
    model = self.env[timer.res_model].browse(timer.res_id)
  File "odoo/fields.py", line 1228, in __get__
    record.ensure_one()
  File "odoo/models.py", line 6196, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

https://github.com/odoo/enterprise/blob/58348c5f9276e5cb4397f0f73d23b41f5a454868/timer/models/timer_mixin.py#L128-L131 When a user quickly presses the ``Enter`` key,
``timer`` will have multiple records,
So, It will lead to the above traceback.

sentry-6557099219

Forward-Port-Of: odoo/enterprise#73984

Purpose
=======
Fix the missing action buttons when:
- uploading files
- doing a select all using CTRL+A

Specification
=============
The showActions method is responsible for the display of the different action buttons.
The actions are currently shown only if the right panel doesn't have any previewed document and no focused document or a focused document which is selected.

When uploading files, the uploaded documents are selected but there is no focused document meaning the action buttons are hidden. Fixing that by focusing the first uploaded document when all the uploaded documents have been selected.

When selecting all the documents using CTRL+A, the records are also selected but there could be no focused document or it could be out of the selection meaning the action buttons are hidden. Fixing the issue by making sure that, in those cases, the focused document is the first of the selection.

related commit: odoo/enterprise@d6d3d3fd07c6174bd8c5a84a420876415f2b271a

Task-4737797

Forward-Port-Of: odoo/enterprise#84513

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/8213c0e66 [REL] 18.0.29 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1c0365d55 [PERF] range: faster reference parsing [Task: 4771804](https://www.odoo.com/odoo/2328/tasks/4771804)
https://github.com/odoo/o-spreadsheet/commit/24e0b5a9a [PERF] coordinate: faster xc parsing [Task: 4771804](https://www.odoo.com/odoo/2328/tasks/4771804)
https://github.com/odoo/o-spreadsheet/commit/85faffbba [FIX] pivot: add `invalid` indicator for wrong calculated measure [Task: 4724069](https://www.odoo.com/odoo/2328/tasks/4724069)
https://github.com/odoo/o-spreadsheet/commit/14b2d89ba [FIX] standalone composer: localize content [Task: 4724069](https://www.odoo.com/odoo/2328/tasks/4724069)
https://github.com/odoo/o-spreadsheet/commit/ae307391b [IMP] tests: add additional jest matchers [Task: 4724069](https://www.odoo.com/odoo/2328/tasks/4724069)
https://github.com/odoo/o-spreadsheet/commit/2600d6804 [FIX] evaluation: fix issue when writing formula on spilled data [Task: 4757650](https://www.odoo.com/odoo/2328/tasks/4757650)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Issue
=====
In the test `test_stock_landed_costs_lots`, there is this `assertRecordValues`:

```python
self.assertRecordValues(lc.stock_valuation_layer_ids.sorted('product_id'), [
    {'lot_id': lot_product_b[0].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[0].id, 'quantity': 0, 'value': 1.5},
    {'lot_id': lot_product_b[1].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[1].id, 'quantity': 0, 'value': 1.5},
    {'lot_id': lot_product_a[0].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[0].id, 'quantity': 0, 'value': 1},
    {'lot_id': lot_product_a[1].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[1].id, 'quantity': 0, 'value': 1},
    {'lot_id': lot_product_a[2].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[2].id, 'quantity': 0, 'value': 1},
])
```
This issue is sometime the records order is not the expected one.

Cause of the issue
==================

By doing `recordset.sorted('product_id')`, it will sort the records by compare their `product_id` records, using the python built-in `sorted`. The built-in `sorted` function simply check if record A is lower than record B, using the < operation. But in Odoo, comparing two recordsets is equal than comparing their ids as a `set`:
```python
def __lt__(self, other):
    try:
        if self._name == other._name:
            return set(self._ids) < set(other._ids)
    except AttributeError:
        pass
    return NotImplemented
```
In python, the comparaison between two sets compares is a set is a subset of the other one, which means than:
```python
{1} < {2}     # is false
{1} < {2, 1}  # is true
```
So, comparing SVLs by their product won't sort them by their product's id. If we want to do that, we have to explicitly do it by passing a function as the `sorted` `key` argument.

For more information, see:
-https://docs.python.org/3/library/functions.html#sorted -https://docs.python.org/3/reference/expressions.html#comparisons

runbot-build-error: 99086

When manually changing the `discount_date` field to null in an invoice related to a customer with an Early price discount payment term, the customer will face a type error on the website when accessing their invoices.

**Steps to reproduce:**

* Install the accountant module
* Create a new invoice for the current user as a customer (e.g., Mitchel Admin).
* Set `2/7 Net 30` in payment terms and add any product.
* Go to Journal Items and make Discount Date visible if not already visible.
* Under the account field `121000 Account Receivable` remove the discount date
  and confirm the invoice.
* Open portal View (/my) and click on Your Invoices >>> Error occurs.

`TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'`

**Solution:**
We use if else blocks to check if `discount_date` exists for the `days_left calculation`; if it exists,
do the calculation as usual if `discount_date` is in future. Otherwise, set `days_left` to zero and continue the function as usual.

Sentry-6395559503

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

…vailability

### Steps to reproduce:

- In the settings enable "Rental transfers"
- Create a storable product that can be rented put 100 units in stock and add a `Security Time` of 24 hours.
- Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it.
- Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The `preparation_time` (`Security Time`) field is used at the sale order line creation to modify the `reservation_begin` value: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L447-L453 In particular, the `preparation_time` of the product creates a difference between the `order_id.rental_start_date` and the `reservation_begin`. This is porblematic since the `rental_start_date` is used to generate the dates of the deliveries taken into account by the forecast:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L354-L362 but the quantity considered as rented does not and is purely based on the `reservation_begin` of the line:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/product_product.py#L113-L117 In particular, the qunaities are not yet accounted ithe stock forecast by the `virtual_available` value of the product:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L129-L132 But will incorrectly be found and read by the rental forecast: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L133-L140

opw-4552760

This reverts commit d413a9895742594d064084cd6dafbf1f2ec97221.

This fix was decided after https://github.com/odoo/enterprise/pull/74127
that was trying to prevent invoicing users to see accounting features,
when it seemed to be unwanted to have the two property accounts fields
required while having no CoA installed.

The issue is, now when having Accounting installed, we can create a user
without having CoA as these two fields are not required anymore, but
we end up with a error message when creating an invoice ('no CoA
installed') although we could be have added accounts manually instead
of installing a CoAi (which is not possible for invoicing user).
In this situation, we should be able to create a contact, and having these
fields required will force the user to create them.

Finally, it is ok to revert the full chain, as the original issue is
fixed by this commit https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0

Forward-Port-Of: odoo/odoo#210344
Forward-Port-Of: odoo/odoo#209832

Versions
--------
- 17.0+

Steps
-----
1. Create a coupon that grants a discount;
2. add a second reward giving free products;
3. use a product tag to turn it into a multiproduct reward;
4. save program, generate coupons, and copy a code;
5. add the free product tag to two or more products;
6. go to eCommerce;
7. add any product to cart and go to checkout;
8. apply coupon code;
9. claim a reward.

Issue
-----
- Claiming a free product results in a traceback.
- Claiming the discount does not apply the discount.

Cause
-----
Commit db3ffae3ef5a5 modified the reward claiming logic to allow for multiproduct rewards, but overlooked the possibility of the program having multiple rewards, multiproduct being one of them.

It therefore passes all of the coupon's rewards to `_apply_reward`, which only expects a single reward.

This is also a consequence of commit 6525d5fba40c, which moved part of the `claim_reward` logic to `pricelist`, without passing which reward was claimed to `pricelist`.

Solution
--------
Add an optional `reward_id` parameter to `pricelist`, letting it know which reward we intend to claim.

opw-4778945

Forward-Port-Of: odoo/odoo#210214
Forward-Port-Of: odoo/odoo#209610

**Description of the issue/feature this PR addresses:**
- The contact-us form allows task creation without a project (project_id = None).
These tasks are assigned to odoobot, have no followers, and no project, making
them inaccessible due to ACL restrictions. 

**steps to reproduce**
1. Install website_form_project.
2. Edit the contact-us form submit button.
3. Set action to 'Create a task' and select 'None' for the project.
4. Save and submit the form.

**Observation**
- Tasks created under such configuration are hidden in the UI and trigger access
errors when trying to open them.

![access error](https://github.com/user-attachments/assets/e5688152-d78b-4628-a0bd-d9f58e2ca442)

Desired behavior after PR is merged:
- Making the project field required, the created tasks will now be accessible/visible

[opw-4664601](https://www.odoo.com/odoo/project/49/tasks/4664601)

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

Forward-Port-Of: odoo/odoo#207871

How to reproduce:

- Install document in v17.0 with demo data
- In the kanban view, upload an image in Marketing folder
- The image is displayed as thumbnail in the kanban card
- Upgrade to saas-17.4
- Open Document and go to marketing folder

There is no thumbnail for the uploaded image.

In v17, _compute_thumbnail_status write a False status when the thumbnail is updated because when it is trigerred the attachment is not yet created. So the thumbnail is present but its status is incorrect. It works in v17 because the status is ignored by the view for images but in v17.4, the status is not ignored and the thumbnail is then not displayed.

This temporary fix allows already migrated user to see thumbnail (as the view could not be modified in stable without an upgrade).

We force the status of the thumbnail to "present" when there is no status for a thumbnail of an image which should cover the case where the status was not updated after the thumbnail creation. We have chosen this solution as the thumbnail will be updated in the upgrade and the URL returns anyway a placeholder image if the image is not present.

We modify some tests to check that the patch is applied. As the kanban test  data includes an image with a False status, the patch turns automatically the status to "present". So instead of having the generic mime type thumbnail, we get the actual thumbnail of the image. We change the assertions accordingly to test the new behavior and test the generic mime type thumbnail in the pdf case of the test "document inspector: document preview".

Task-4642866

Forward-Port-Of: odoo/enterprise#81558

**Steps to reproduce:**
- Install Planning app
- Set the type of view to Gantt
- (Create a shift if there is none)
- Click on `Publish` button
- The period end date doesn't take the last day into account (time is 00:00)

**Issue:**
Gantt model default `_buildMetaData` computation behavior was changed multiple times during previous refactoring:

Previously used:
```
export function computeRange(scale, date) {
    let start = date;
    let end = date;

    if (scale === "week") {
        // startOf("week") does not depend on locale and will always give the
        // "Monday" of the week... (ISO standard)
        const { weekStart } = localization;
        const weekday = start.weekday < weekStart ? weekStart - 7 : weekStart;
        start = start.set({ weekday }).startOf("day");
        end = start.plus({ weeks: 1, days: -1 }).endOf("day");
    } else {
        start = start.startOf(scale);
        end = end.endOf(scale);
    }

    return { start, end };
}
```
Which became:
```
export function getRangeFromDate(rangeId, date) {
    const startDate = localStartOf(date, rangeId);
    const stopDate = startDate.plus({ [rangeId]: 1 }).minus({ day: 1 });
    return { focusDate: date, startDate, stopDate, rangeId };
}
```

**Fix:**
Added `localStartOf` function in the context setup of PlanningGanttModel.

To avoid overwriting current changes for other modules (which could be intended), this was done instead of :
```
export function getRangeFromDate(rangeId, date) {
    const startDate = localStartOf(date, rangeId);
    const stopDate = localEndOf(startDate, rangeId);
    return { focusDate: date, startDate, stopDate, rangeId };
}
```

related commits:
https://github.com/odoo/enterprise/commit/d18639785e622d97102227103d62ddb3a2716be6 https://github.com/odoo/enterprise/commit/c175a848369057cc69596737dcd9d21dd24c9d5c

opw-4580458

Forward-Port-Of: odoo/enterprise#85608