Login uniqueness is enforced by a `UNIQUE (login)` constraint that Postgres compares byte for byte, so signing up with foo@example.com and then Foo@example.com produces two separate accounts pointing at the same real mailbox.
https://github.com/odoo/odoo/blob/66a6c16551041543b5addfe846f15e769b4e9afe/odoo/addons/base/models/res_users.py#L274

Even if the DB constraint did catch an exact-case duplicate and `_signup_create_user` re-raised it as a `SignupError`, the controller's friendly "already registered" branch only triggers when the duplicate lookup finds a row, and that lookup goes through `_get_login_domain` with an exact `=` operator. Case variants would fall into the generic "Could not create a new account" branch instead.
https://github.com/odoo/odoo/blob/66a6c16551041543b5addfe846f15e769b4e9afe/addons/auth_signup/controllers/main.py#L68-L75
https://github.com/odoo/odoo/blob/66a6c16551041543b5addfe846f15e769b4e9afe/odoo/addons/base/models/res_users.py#L749-L750

`_signup_create_user` now refuses creation when a user with the same email already exists, applying to both b2c free signup and token-based invitations. It raises `UserError` directly so the controller's `except UserError` surfaces the message without a redundant lookup. The check uses `_get_email_domain`, whose base implementation is switched from `=` to `=ilike` over a value escaped via `tools.escape_psql` so `%` and `_` are matched literally rather than as wildcards. Its only existing caller is `reset_password`, which already wants case-insensitive matching.

Steps to reproduce:
1. In Settings, set Customer Account to "Free sign up" and save.
2. Log out, then on the login page click "Don't have an account?".
3. Register with foo@example.com.
4. Log out again and click "Don't have an account?".
5. Register with Foo@example.com.

=> Two distinct user accounts are created for the same mailbox.

opw-6199441

Forward-Port-Of: odoo/odoo#273071
Forward-Port-Of: odoo/odoo#263864

Before this commit, when using discuss in mobile, actions in bottom sheet were too small and hard to click.

Steps to reproduce:
- open a conversation in discuss with a message
- click on "..." or long-press the message

This comes from changes in spreadsheet_dashboard were some CSS rules that were meant to impact only bottom sheet of spreadsheet_dashboard were actually impacting all the bottom sheets [1], including discuss actions.

This commit fixes the issue by putting a specific class on the bottom sheet menu in spreadsheet_dashboard, so that the CSS rule can be made specific to spreadsheet_dashboard and not affect other bottom sheets like the ones used in Discuss app.

[1]: https://github.com/odoo/odoo/pull/239190

Before
<img width="657" height="524" alt="Screenshot 2026-07-10 at 14 18 38" src="https://github.com/user-attachments/assets/6e4cd083-3d4c-4c38-af89-93819e6eb1a8" />

After
<img width="656" height="527" alt="Screenshot 2026-07-10 at 14 18 25" src="https://github.com/user-attachments/assets/48e66648-7f5e-4e42-8a64-b85499aceb97" />

Use case
--------

A recurring sale order, is automatically invoiced. The transaction is postprocessed and crash with this traceback

```
File "/home/odoo/src/enterprise/saas-19.2/sale_subscription/models/sale_order.py", line 1881, in _handle_automatic_invoices
invoice._post()
File "/home/odoo/src/custom/private/openerp_enterprise/models/subscription_assignation.py", line 439, in _post
posted_moves = super()._post(soft=soft)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/custom/private/openerp_enterprise/models/account.py", line 193, in _post
posted = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/hr_payroll_expense/models/account_move.py", line 21, in _post
res = super()._post(soft=soft) # Posting will automatically reconcile same-account-same-matching lines
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/l10n_in_reports/models/account_move.py", line 135, in _post
to_post = super()._post(soft=soft)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/account_loans/models/account_move.py", line 20, in _post
posted = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/sale_subscription/models/account_move.py", line 21, in _post
posted_moves = super()._post(soft=soft)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/account_invoice_extract/models/account_invoice.py", line 235, in _post
posted = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/account_asset/models/account_move.py", line 130, in _post
posted = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_it_edi/models/account_move.py", line 360, in _post
return super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_in_edi/models/account_move.py", line 156, in _post
res = super()._post(soft=soft)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/account_peppol_response/models/account_move.py", line 42, in _post
res = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/sale/models/account_move.py", line 149, in _post
invoice.js_assign_outstanding_line(line.id)
File "/home/odoo/src/enterprise/saas-19.2/account_accountant/models/account_move.py", line 589, in js_assign_outstanding_line
super().js_assign_outstanding_line(line_id)
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move.py", line 6430, in js_assign_outstanding_line
return lines.reconcile()
^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move_line.py", line 3324, in reconcile
return self._reconcile_plan([self])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move_line.py", line 2978, in _reconcile_plan
plan_list, all_amls = self._optimize_reconciliation_plan(reconciliation_plan)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move_line.py", line 2940, in _optimize_reconciliation_plan
amls._check_amls_exigibility_for_reconciliation(shadowed_aml_values=shadowed_aml_values)
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move_line.py", line 2832, in _check_amls_exigibility_for_reconciliation
raise UserError(_("You can not reconcile cancelled entries."))

You can not reconcile cancelled entries.
```

Because an old transaction: state = 'reconciled' but is_reconciled is false get attached to the new invoice. The the tx.payment_id.move_id was cancelled by the accounting team, and the invoice was reconcilled directly with the bank statement.

So we end up with a cancelled move that block any further invoice for this subscription.

Solution
--------

According to accounting team, the move_id of the payment is always posted except if there is some manual intervention. We make sure we link only transaction with payment with posted moved

opw-6368231

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#275445
Forward-Port-Of: odoo/odoo#274764

**Steps to reproduce:**

1. Install the **Attendance** app in saas-19.2 with demo data.
2. Log in as a user who has **Administrator** rights in the Attendance app but no access rights in the Employees app.
3. Go to **Attendance → Configuration → Overtime Rulesets**.
4. Open any overtime ruleset.

An `AccessError` is raised:

```
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 3373,
in check_access
    raise result[1]()
 odoo.exceptions.AccessError: You are not allowed to access
'Employee Record' (hr.version) records.

This operation is allowed for the following groups:
	- Employees/Administrator
	- Employees/Officer: Manage all employees

Contact your administrator to request access if necessary.
```
**Issue:**

A new feature introduced an employee count stat button on `hr.attendance.overtime.ruleset` in [v19.2](https://github.com/odoo/odoo/pull/236555/changes).

Users who have administer right in Attendance app but do not have access to Employee records trigger an access error when opening the ruleset.

**Solution:**

The fix restricts the visibility of the [Stat button ](https://github.com/odoo/odoo/blob/7c6f31d730304bca3f6c996800e76d1e40ce4adf/addons/hr_attendance/views/hr_attendance_overtime_rule_views.xml#L114)to users with the required Employee groups, preventing the access error while keeping the feature available for authorized users.

opw- 6358550
upg- 4449776


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

#### Issue:
When a credit note is renamed so that it sorts before the related invoices,
the lot assigned on invoice previews can become incorrect. Already posted
invoices can appear to consume the first lot again.

Example:
A sale order is delivered in 2 batches: 10 units from SN01, then 10 units
from SN02. Invoice 1 correctly shows SN01 and Invoice 2 correctly shows
SN02. If Invoice 1 is refunded, re-invoiced, and the credit note is then
renamed so it sorts before the invoices, Invoice 2 can incorrectly switch
back to SN01.

#### Steps to reproduce:
- Enable "Display Lots & Serial Numbers on Invoices".
- Create a sale order for 20 units of a tracked product.
- Deliver 10 units from the first lot/serial number and 10 units from a second one in a backorder.
- Create and post 2 invoices, one for each delivery.
- Create and post a credit note for the first invoice.
- Create and post a new invoice for 10 units.
- Reset the credit note to draft, rename it so that it sorts before the invoices, then repost it.
- Check the lot previews on the invoices.

#### Root Cause:
_get_invoiced_lot_values() orders invoice lines with move_name, which is
mutable, then computes the previously invoiced quantities from that order.
When a refund is renamed so it sorts before the invoices, the set of
"previous" invoice lines changes. On top of that, reversed invoices are
filtered out too broadly, even when their reversing move should not yet
impact the current invoice chronology.

#### Fix:
Order invoice lines with immutable move ids instead of move_name, and only
ignore reversed invoices once their reversing move is also before the
current invoice in the effective chronology. This keeps posted invoices
stable while preserving the re-invoice behavior.

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

Forward-Port-Of: odoo/odoo#264776

**Problem:**
When scheduling a message using an email template with custom attachments, those attachments will not have their `res_model` and `res_id` updated to relate to the scheduled message record. This can lead to access errors.

**Cause:**
When composing a message using an email template with attachments, those attachments are created with their `res_model` and `res_id` values corresponding to the mail composer record. However, when scheduling a message, only attachments with no `res_id` value (or a value of 0) are updated to correspond to the scheduled message record. https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mail/wizard/mail_compose_message.py#L1198-L1201
https://github.com/odoo/odoo/blob/30ca89b9e0d3c43d019167ec2de816c263f4bb92/addons/mail/models/mail_scheduled_message.py#L86

**Purpose:**
Modify the `mail.scheduled.message` override of `create` to not require an attachment have no `res_id` value to be properly updated.

**Steps to Reproduce in Runbot:**
1. Add an attachment to an email template.
2. Open a mail composer using that email template, then schedule the message for later.
3. Attempt to view the scheduled message with a different user.

More specific example flow:
1. Add an attachment to the Sales: Send Quotation email template.
2. Create a Quotation and send it with the Send by Email button, selecting Send Later instead of Send.
3. Attempt to view the Quotation with a different user.

opw-6293587

Forward-Port-Of: odoo/odoo#272261

Problem:
When filtering lost leads and grouping them, the lost leads are not counted in the groups' totals.

Steps to Reproduce:
1. Go to CRM
2. Go to Reporting > Leads
3. Select List View
4. Before applying any grouping, check the total number of leads and
make sure there are some closed leads among the leads and that the
applied filter includes the inactive/lost leads
5. Apply any grouping
6. Check how the sum of the groups totals doesn't equal the leads total

Cause:
When reading a group, the domain from the applied filter gets optimized, meaning that the applied rules get simplified logically.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/web/models/models.py#L421
When looking for all leads, we filter by both active and inactive leads, but the optimize method removes both of them since active=TRUE OR active=FALSE = TRUE always. When removed, no filtering on the active field is in the domain now, which leads to the search method returning only active leads (default behaviour of search method when the active field is not set in the domain).

opw-6302388

Forward-Port-Of: odoo/odoo#272390

## Description of the issue/feature this PR addresses:
Turkish accounting applies different exchange rates depending on whether
the company is collecting foreign currency or paying it out. TCMB publishes
both buying and selling rates daily but `currency_rate_live` only keeps
the average, so accountants currently correct the rate by hand on every
invoice and bill.

## Current behavior before PR:
The TCMB daily update stores only the averaged rate on `res.currency.rate`.
Invoices and bills use that same rate, and users have to adjust it
manually per document.

## Desired behavior after PR is merged:
- Both the buying and selling rates are stored on `res.currency.rate`
  next to the average.
- Customer invoices and vendor bills get a Rate Type field, defaulting
  to "buying" for invoices and vendor refunds and to "selling" for bills
  and customer refunds. The user can override before posting.
- The selected rate is written to `invoice_currency_rate`. The lookup
  uses the rate dated the document's date, or the most recent rate
  before it when no rate exists for that exact date.
- Only TR companies with TRY as base currency are affected.

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

Let's consider we have validated the return of our tax report for January and February. Then, we realize we made an error in January, and want to modify this return and resubmit it.

Before this commit, an error message blocked the direct resetting of January's return, because February's had been posted. To be able to reset January, it was necessary to reset all subsequent returns. This was annoying. Such fixes need to happen in many countries (while some other rather make the adjustments in the next period to declare, like Belgium).

This restriction was originally introduced to avoid inconsistencies in case the returns declared from the previously submitted returns. Two features could create such cases:

1) tax amount to recover, which was directly deduced from the closing entry when it contained something to pay

2) carryover, which created external values able to impact the following periods

=> Case 1) is not true anymore. When an amount needs to be recovered, we just show the balance taking it into account on the following returns, but don't change anything to their closing at all.

=> Case 2) still holds.

So, all we need to put under control is carryover, which is what we do now. If the report doesn't use carryover at all, its returns can all safely be reset, whatever the state of the rest of the return chain.

The `body` field on `whatsapp.message` was defined with `related_sudo=False` with the intent of restricting access to messages from restricted records. However, this was never actually providing any security value because [`mail.message.fetch()`] was overriding it with `self.sudo()` till `v19.1`, meaning the body was always fetched as superuser regardless:
```py
    web_search_read() -> search_fetch()
    -> fields.py _compute_related()
    -> record[self.related_field.name]  # triggers fetch of mail.message.body
    -> models.py _fetch_field()
    -> mail_message.py fetch()
    -> self = self.sudo()  # sudo hack overrides related_sudo=False silently
```
In `v19.2`, the `fetch()` sudo hack was intentionally removed (see commit odoo/odoo@4727f12d274a0b2d7c455363d189565bd8fb2e7a) as access rights are now cached and can be checked without a performance penalty. This exposed the broken `related_sudo=False` which now causes an `AccessError` when trying to read the body of a `whatsapp.message` whose linked `mail.message` points to a document the current user cannot access (e.g. `purchase.order`).

Access control on `whatsapp.message` is already correctly enforced at the `ir.rule` level:
- Regular users can only see messages they created (`create_uid = user.id`)
- WA Admins can see all messages

We have upgrade requests failing on this issue: TBG-[2765]

[`mail.message.fetch()`]: https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/models/mail_message.py#L812-L819
[2765]: https://upgrade.odoo.com/odoo/tbg/2765?debug=1

Forward-Port-Of: odoo/enterprise#119867

When scanning a package then a package type, from the point of view of the user nothing happend, and in the backend it will created a new package but it will not link it to the products nor will it show any warning.

Steps to reproduce:
-------------------
* Install barcode and stock
* Enable packages in settings
* Open Inventory
* Create a product,
* Create a Package Type -> barcode PACKTYPE,
* Create a Package linked to this package type -> PACK,
* Add at least 2 unit of product to this package,
* Create a delivery for 2 unit of the product,

Open Barcode
* Operation > Delivery orders > your delivery
* Erase the destination package from the first line
* Scan PACK
( don't click on the green line)
* Scan PACKTYPE

**Actual behavior**
create a new package but does not link it to the new products

**Expected behavior**
create a new package and set it as destination package.

Observation:
-------------
When scanning the package (PACK), we will go through ```_processPackage``` -> ```async _processPackage``` where in the end the line is unselected:
https://github.com/odoo/enterprise/blob/39d8a473fe03038ca0494a6a8165e3eb75bd8492/stock_barcode/static/src/models/barcode_picking_model.js#L2090

When we scan our package type (PACKTYPE), we will go to ``` _processPackage``` -> ```_processPackage```->```_processPackageType```  
where we will obtains packagesIds checking that we have a source package:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2123-L2132
and will send us to ```_putPackInPack```:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2133-L2136

Where we will avoid the empty packageIds since we checked on the source package and not the destination package:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2296-L2299
and will call ```action_put_in_pack``` from the packaging model:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2301-L2306

In ```action_put_in_pack``` will create a new packaging and put it as a the new destination package, but since the ```previous_dest_package``` (saved in db) was itself, he will [erase the link](https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_package.py#L354-L363) he just made.

Which means that in our case, we created a package without linking it to anything.

Even if we avoid the function to erase the destination package, since the destination package shown in barcode is the one from move line :
https://github.com/odoo/enterprise/blob/d0d0a3cf4a02bf24cf502b533e494fe7ca155eb3/stock_barcode/static/src/components/line.js#L115-L117
It will not show the new package in barcode


opw-5449729

Forward-Port-Of: odoo/enterprise#120335
Forward-Port-Of: odoo/enterprise#104876

Steps to Reproduce
---
- Create two different working schedules with different public holidays
- Assign employees to specific working schedules
- Set company default working schedule to a different schedule
- Login as employee with specific working schedule
- Navigate to Timesheets app -> My Timesheets
- Observe public holidays and personal time-off displayed in the timesheet grid

Issue
---
- The timesheet grid displays unavailable dates (public holidays, weekends) from the company's default working schedule instead of the employee's assigned working schedule.
- Personal time-off requests are not reflected as unavailable dates in the timesheet grid.

Current Behaviour
---
- Public holidays shown are always from the company's default working schedule, ignoring employee-specific working schedule assignments.
- Employee's approved time-off requests don't appear as unavailable in the timesheet.

Expected Behaviour
---
- Public holidays should display based on the employee's assigned working schedule, with company schedule as fallback only when no specific schedule is assigned.
- Employee's personal time-off requests should appear as unavailable dates.
- This should align with Time Off app behavior.

Fix
---
- Included employee-specific work interval calculation with personal time-off requests.
- Added support for contract-based calendar changes and calendar validity periods.
- Implemented proper fallback when valid intervals are not found.

task-4997080

Forward-Port-Of: odoo/enterprise#123331
Forward-Port-Of: odoo/enterprise#95458

## Issue
When using the *Auto Plan* feature on a planning slot with a Role and a Project set, a resource which operated on the same project will be chosen if available, without taking into account the Role set on the slot.

## Steps to reproduce
1. Install Project Planning (`project_forecast`)
2. In Planning > Configuration > Roles, create two planning roles A and B
    - Role A: Assign a resource R
    - Role B: No resource
3. Open Planning (Schedule by Resource), and go back a few weeks (to prevent overlaps with potential demo data)
4. Create two new slots:
    1. Set Role B and a random Project P, then click Auto Plan: there should be no available resource (because we didn't set any resource for Role B)
    2. Set Role A and the same Project P, then click Auto Plan: it should assign the resource R assigned to Role A
5. After assigning a resource to the slot for Role A, edit the Open Shift for Role B again and click Auto Plan: **it assigns the same resource R, even though that resource is not assigned to Role B.**

## Cause
The `_get_open_shifts_resources` override in `project_forecast` looks for resources that were assigned to slots related to the same project. It does not filter resources based on the requested role.

https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/project_forecast/models/planning_slot.py#L104-L116

This means that resources that are not part of the requested role can be assigned to the slot, as long as the resource operated on another slot for the same project.

opw-6325744

Forward-Port-Of: odoo/enterprise#122813
Forward-Port-Of: odoo/enterprise#122035

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121809
Forward-Port-Of: odoo/enterprise#119525

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Journal entries and create a new one
3. Click Toggle Studio button and go to the view to add the tax_base_amount field to the list of existing fields
4. Add 2 lines (example):
	1. account Product Sales with 1000 dollars credit and 15% tax under Tax column
	2. account Bank with 1000 dollars debit
5. Go to Dashboard > Bank > Click the 3 dots of one random bank matching line and click on Manage Models
6. Go to bank fees and add the 15% tax
7. Go back to bank reconciliation and create a new one of 2000 dollars with label bank fees (it will associate the tax automatically)
8. Go back to Journal Entries, group by Journal and search for the transaction of 2000 sollars for account Bank
9. Problem: see that the Base Amount for the 15% bank fees lines (251000 Tax Received account) is 0. Clicking on Reset to draft button the base amount column is automatically updated but this should happen automatically

### Cause of the issue:
This occurs because the _lines_prepare_tax_line method in account.bank.statement.line fails to map this field in its return dictionary.

### Reason to introduce the fix:
Currently, when applying a reconciliation model with taxes the generated tax lines incorrectly record a tax_base_amount of $0.00. Instead, it should be displayed and calculated.

opw-6220948

Forward-Port-Of: odoo/enterprise#123603
Forward-Port-Of: odoo/enterprise#122139

Steps to reproduce:
1. Install sale_crm and sale_renting_crm
2. Create an opportunity
3. On this opportunity, create two quotations from the `New quotation` button
4. From the opportunity's form view, click on the `Quotation` smart button

Issue:
- The quotations are not visible in the list view

Why?
- In module `sale_renting_crm`, we override the domain to exclude rental quotations.
https://github.com/odoo/enterprise/blob/fda037c62a6661665611fb061718c01aec39ac1b/sale_renting_crm/models/crm_lead.py#L33-L36 But from the saas-19.3 `is_rental_order` field is no longer stored in the DB, It is computed now and filtered through  `_search_is_rental_order`. 
https://github.com/odoo/enterprise/blob/fda037c62a6661665611fb061718c01aec39ac1b/sale_renting/models/sale_order.py#L223-L227 The search method did not properly handle the Boolean search shape used by the ORM, so the quotations were incorrectly filtered out. In our case, we gave the domain `("is_rental_order", "=", False)` but the operator is translated to `not in` and value to `Orderedset([True])` by the domain optimiser

Solution:
- Update `_search_is_rental_order()` to handle the ORM-normalized boolean search correctly for rental and non-rental quotations.

opw-6304696

Forward-Port-Of: odoo/enterprise#120869