Currently an exception is generated when the user submits the custom
website form after following the below steps:

- Install `web_studio`, `website` and `crm`
- Go to the website > Open the website editor > Add a form to the website
- Configure the form as below:
      Action: Click `More models` > select `crm.tead`
      Field: add any custom
- Save the form
- Now an error is generated in the backend when the user submits the form.

The error was caused by submitting a form without a required field, leading
to a `NotNullViolation` during insertion at code line [1]. This was caught as
an `IntegrityError` at code line [2], but since the transaction was not rolled
back (broken transaction), it remained in a failed state. Consequently, a
subsequent operation triggered an `InFailedSqlTransaction` error when
attempting to close the savepoint at code line [3].

This commit will solve the above issue by rolling back the cursor when
the `IntegrityError` error occurs while submitting the form.

[1]: https://github.com/odoo/odoo/blob/c21c481eecf11a2e6e8bb21aa907e0aee870e3da/addons/website/controllers/form.py#L77
[2]: https://github.com/odoo/odoo/blob/c21c481eecf11a2e6e8bb21aa907e0aee870e3da/addons/website/controllers/form.py#L98
[3]: https://github.com/odoo/odoo/blob/c21c481eecf11a2e6e8bb21aa907e0aee870e3da/addons/website/controllers/form.py#L53

Sentry-7260662088,7327198011

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Steps to produce:
---
- Install `website_sale`, `l10n_ca` & `accountant` modules with demo data.
- Switch to a `Canadian (CA) company.`
- Go to Settings and enable` Discounts, Loyalty & Gift Cards`.
- Go to` Website > eCommerce > Loyalty > Discount & Loyalty.`
- Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order.
- Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence).
- Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product.
- Open the website in an incognito window > Add the product to the cart > Apply the discount code.
- In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes.

Issue:
---
- The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST.

Root cause:
---
- When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST.
- After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST.
- In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur.
- In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line.

Fix:
---
- Avoid splitting taxes on the discount line in the sale order.
- Keep the original tax structure intact to prevent duplication after fiscal position changes.

[1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156
[2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296

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

The calendar event for a paid appointment is created from account.move._post() once the invoice is confirmed by the payment transaction. At that point there is no website request, so env.company falls back to the user's default allowed company instead of the company the booking was made on. The attendee invitation mail rendered from the new event then carries that default company's branding in its header and footer rather than the company the customer booked on.

Read the booking's company from the existing record it already carries (its invoice in the direct payment flow, its sale order line in the eCommerce flow added by website_appointment_sale) and re-apply it via with_company when creating the calendar event so the mail layout picks the right company. The lookup is exposed as a hook on calendar.booking so each module can extend it for its own payment record.

Reachable since the feature was added in https://github.com/odoo/enterprise/commit/ce6bc7150457c8f4da331abb359ec99badca5ab3.

Steps to reproduce:
1. In a multi-company environment with two companies A and B, give the staff user access to both with company A as their default.
2. Create a website tied to company B.
3. Activate the Demo payment provider in test mode on both companies.
4. From company B, create an appointment type with an up-front payment, staffed by that user and tied to company B's website.
5. From company B's public website, open the appointment page, pick a slot, fill in the customer info and proceed to payment.
6. Pay via Demo.
7. Open the attendee invitation email in the mail catcher.

=> The email header and footer show company A instead of company B.

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

When computing `qty_to_order` 1-3 extra queries are made by `get_lead_days()`, which can cause performance issues when computing `qty_to_order` for a large number of orderpoints.

This commit aims to prevent these extra queries by returning early if the current product is not associated with a bom. The amount this commit speeds up the compute depends on how many of products passed into `_get_lead_days()` are associated with a bom.

`qty_to_order` is no longer a stored field after this commit: https://github.com/odoo/odoo/pull/159432
This benchmark was done in 18.0 on /stock.warehouse.orderpoint/search_panel_select_range. This call does not trigger the compute on all orderpoints in 17.0 as the field is stored but calling the compute directly on all orderpoints results in the same speed up as seen in 18.0.

| Orderpoints | % of products linked to a bom | Time before | Queries before | Time after | Queries After |
|-------------|-------------------------------|-------------|----------------|------------|---------------|
|         800 | 50%                           | 2.8s        |           1570 | 2.3s       |           818 |
|       8,000 | 0%                            | 28.2s       |         16,698 | 15.3s      |           242 |
|       8,000 | 25%                           | 29.6s       |         16,833 | 19.2s      |          4497 |
|       8,000 | 50%                           | 29.8s       |         16,925 | 23.2s      |          8693 |
|       8,000 | 75%                           | 31.6s       |         16,949 | 27.6s      |         12827 |

Forward-Port-Of: odoo/odoo#262321

Currently, an error occurs when a user selects a shift template on a planning slot.

**Steps to Reproduce:**

 - Install the `Planning` module with demo data.
 - Create a `Resource Time Off` record with `start` and `end date` separated by more than 
  `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week.
 - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create 
   a `new one`, and set the `Working Days` to more than 1 day.
 - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above 
   `shift template`.

`AttributeError: 'bool' object has no attribute 'replace'`

This error occurs because when the user sets the shift template, the compute method runs to 
calculate the start and end datetimes [1]. It computes the end datetime by adding the template 
duration in working days from the given start datetime using the resource working calendar within 
a searchable range of around 1400 days [2]. During this computation, leaves and non-working days 
are skipped [3]. If no valid working interval is found within the searchable range, then it returns 
False [4], which raises the error [5].

This commit ensures that if plan_days returns False, the computation falls back to the previously 
calculated end date.

[1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671

[2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835

[3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537

[4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835

[5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654

sentry-7472958590