## **Issue**

When a cash basis tax is configured with a payable/receivable
transition account, tax journal items are generated on that account
without a due date.

Since payable/receivable accounts require a due date on journal
items, this leads to a validation error during move creation:

"Any journal item on a payable account must have a due date and vice versa."

## **Steps to reproduce:**

1. Install the Accounting and Inter-Company modules.
2. Create an additional company so that there are a total of two companies, then switch to Company 1.
3. Create a product with a price and assign a tax to it.
4. Navigate to Accounting → Configuration → Settings and enable Cash Basis accounting.
5. Go to Accounting → Configuration → Taxes and open the purchase tax (or the tax assigned to the product).
6. In the Tax Computation section, ensure that Group of Taxes is not selected.
7. Under the Advanced Options tab, set Tax Exigibility to Based on Payment.
8. Set the Cash Basis Transition Account to a payable account.
9. Open Company Settings, select Company 1, go to the Inter-Company Transactions section, and enable Synchronize invoices/bills.
10. Switch to Company 2 and create an invoice using the same product. Select the contact that is the partner of Company 1.
11. Confirm the invoice.

The following error is raised:

"Any journal item on a payable account must have a due date and vice versa."

## **With This Commit:**
Added a domain on the Cash Basis Transition Account field to prevent
users from selecting payable or receivable accounts, avoiding invalid
configurations and runtime validation errors.

opw-6189615

Forward-Port-Of: odoo/odoo#264777
Forward-Port-Of: odoo/odoo#263792

Steps to produce:
---
- Install website_sale module.
- Enable `Comparison Price` from settings.
- Create a product with sales price = 25 and compare price = 25.
- Go to the shop page and search for the product.

Issue:
---
- The strikethrough appears on the compare price (25) even when the compare price equals the sales price.
- The strikethrough should only appear when the compare price is strictly greater than the sales price.

Root cause:
---
- In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal.

Solution:
---
- Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2].

Before:
---
<img width="537" height="98" alt="image" src="https://github.com/user-attachments/assets/a1524f0f-4a59-4daf-ac7d-834604710492" />

After:
---
<img width="538" height="95" alt="image" src="https://github.com/user-attachments/assets/1e32269b-13c0-469b-9d1f-e6d6ced97fdd" />


[1]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834
[2]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346

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

Forward-Port-Of: odoo/odoo#265004
Forward-Port-Of: odoo/odoo#262434

Steps to reproduce:
===================
1. Configure website with at least 1 language installed different from English. ex: English and French.
2. As anonymous user, change wehbsite language and make a donation via the donation snippet.
3. Check the outgoing confirmation email.

=> Email body is rendered in English.

Cause:
======
The donation confirmation email rendered with `self.partner_id.lang`. For anonymous donors, `partner_id` is the website's shared public user partner, so every anonymous donor received the email in whatever language was set on that partner (or English if unset), regardless of the language they were browsing in.

Solution:
=========
`payment.transaction` already has a `partner_lang` field auto-filled from `partner.lang` at creation.
- override it in the `/donation/transaction` controller with `request.env.lang`
when the public partner is used, capturing the request language at donation time (also works later from `_cron_post_process`, which has no request context);
- render `_send_donation_email` using `self.partner_lang` instead of `self.partner_id.lang`.

opw-5875338


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

Forward-Port-Of: odoo/odoo#259351

Version:
--------
- saas-19.1+

Step to reproduce:
----------------------
* Install *sale_management* and *stock* modules.
* Create a Sale Order with at least two order lines.
  * Set different *Customer Lead Time* (it is optional hide by default)
 on each line:
    * Line A: 5 days
    * Line B: 10 days
* Confirm the Sale Order.
* Open the generated Delivery Order.
* Enable the *Deadline* field on stock moves (it is optional hide by default).
* Check the *Deadline* value for each move

issue:
-----
 * Both stock moves have the same *Deadline*, corresponding to the minimum
  lead time (earliest date), instead of their respective values.
 
Root cause:
-----------
1. User confirms a Sale Order with two lines:
     - Line A: customer_lead = 5  → _expected_date() = order_date + 5
     - Line B: customer_lead = 10 → _expected_date() = order_date + 10

2. sale.order.action_confirm()
   └─ Before calling `_action_confirm()`, the method set:
        `order.commitment_date = order.expected_date`
      where `expected_date = min(all line._expected_date()) = order_date + 5`

3. sale.order._action_confirm()
   └─ calls order_line._action_launch_stock_rule()
https://github.com/odoo/odoo/blob/00edcf55380431c454857b2749f2fe4930b1e758/addons/sale_stock/models/sale_order.py#L209

4. sale.order.line._action_launch_stock_rule()
   └─ per line: calls line._prepare_procurement_values()

5. sale.order.line._prepare_procurement_values()
   └─ date_deadline = self.order_id.commitment_date or self._expected_date()
      Because commitment_date was force-set in step 2, BOTH lines resolve to
      order_date + 5 instead of their individual values.

https://github.com/odoo/odoo/blob/00edcf55380431c454857b2749f2fe4930b1e758/addons/sale_stock/models/sale_order_line.py#L281

NOTE:
------

This issue originates from changes introduced in task: https://www.odoo.com/odoo/project/966/tasks/4687135
That task aimed to add the Promise Date to Purchase Order Lines and, during 
confirmation, assign it as the expected arrival date.

* This behavior works correctly in Purchase Orders because the Promise Date is
 applied at the purchase order line level and aligned with each 
line’s expected arrival date.  It does not participate in the computation of 
date_deadline.

- In the purchase flow:
The incoming stock move date_deadline is directly derived from each line’s 
expected arrival date.
https://github.com/odoo/odoo/blob/00edcf55380431c454857b2749f2fe4930b1e758/addons/purchase_stock/models/purchase_order_line.py#L308
There is no dependency on a promise date.
As a result, deadlines remain per-line and accurate.

However, in the Sale Order flow, the same approach introduces an issue.

Here:
The Promise Date (commitment_date) exists at the order level, not at line level.
During confirmation, it is set using the minimum of all line expected dates.
The delivery stock move date_deadline depends on this commitment_date.

As a consequence:

Setting a single order-level promise date overrides all per-line expected dates.
All stock moves receive the same (minimum) deadline.

Additionally, this is not aligned with the business logic:

Example:
Line A → lead time = 5 days
Line B → lead time = 10 days
Current behavior sets deadline = min(5, 10) = 5 days for all moves,
which incorrectly forces later deliveries to be scheduled earlier than intended.

Solution:
---------
* Remove the automatic assignment of commitment_date = expected_date in action_confirm().
commitment_date is a user-defined promised delivery date and should not be
 implicitly set during confirmation. By leaving it unset, procurement values
correctly fall back to line._expected_date(), restoring per-line deadline
computation.

---

opw-6106045

Forward-Port-Of: odoo/odoo#258911

The `partner_pages_tree_view` was attempting to modify `activity_ids` field attributes, but this field is added by the mail module in a sibling inheritance branch ([mail.res_partner_view_tree_inherit_mail]), making it unreachable from the [`partnership.view_res_partner_grade_tree`] ancestry chain:
```py
  base.view_partner_tree → partnership.view_res_partner_grade_tree → partner_pages_tree_view
  base.view_partner_tree → mail.res_partner_view_tree_inherit_mail ← activity_ids lives here
```
This caused a ParseError during base module upgrade:
```py
  File "/home/odoo/odoo/odoo/odoo/tools/convert.py", line 639, in _tag_root
    raise ParseError(msg) from None  # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/odoo/odoo/addons/base/views/res_partner_views.xml:13
Error while parsing or validating view:
Element '<field name="activity_ids">' cannot be located in parent view
View error context:
{'file': '/home/odoo/odoo/odoo/odoo/addons/base/views/res_partner_views.xml',
 'line': 1,
 'name': 'Partner Pages List',
 'view': ir.ui.view(2148,),
 'view.model': 'res.partner',
 'view.parent': ir.ui.view(2108,),
 'xmlid': 'website_crm_partner_assign.partner_pages_tree_view'}
```

**Steps to reproduce:**
- In a v19.1 db install `website_crm_partner_assign`
- Go to apps and search base module and click upgrade

**Fix:**
Make the partner view from partnership inherit from the one defined in mail instead of the one defined in base. 

opw-6186684

[mail.res_partner_view_tree_inherit_mail]: https://github.com/odoo/odoo/blob/saas-19.3/addons/mail/views/res_partner_views.xml#L58C21-L67
[`partnership.view_res_partner_grade_tree`]: https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/partnership/views/res_partner_views.xml#L48-L57





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

Forward-Port-Of: odoo/odoo#264639

**Steps to reproduce:**
1. Install Time Off
2. Go to Accrual Plans and create a new plan with a milestone
3. Set frequency to Weekly and choose a day other than Monday (e.g., Tuesday)
4. Save and check the displayed weekday in the accrual plan level

**Issue:**
The displayed weekday is incorrect (e.g., shows Monday instead of Tuesday).

**Cause:**
Previously, the weekday value was directly displayed using: https://github.com/odoo/odoo/blob/b40184ab371f7a4708621ecf7f25b4e2daaae38d/addons/hr_holidays/views/hr_leave_accrual_views.xml#L212-L214 so no conversion was involved.

Now, the value is processed using Luxon. However, the week_day field stores values from 0 (Monday) to 6 (Sunday), while Luxon expects ISO weekday numbers from 1 (Monday) to 7 (Sunday). This mismatch causes an off-by-one error during conversion.
https://github.com/odoo/odoo/blob/1b3d0a3c2f794324f8b230a9ae19f097454e3bdd/addons/hr_holidays/models/hr_leave_accrual_plan_level.py#L54-L62

**Solution:**
Adjust the value before passing it to Luxon by adding +1 to match ISO format.

opw-6112614




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

Forward-Port-Of: odoo/odoo#259054

**Steps to reproduce in runbot:**
1. Install hr_holidays_attendance.
2. Create an employee with a contract start date (e.g., April 1st).
3. Set the timezone(for both user and emp working schedule) to Europe/Brussels.
4. Create an attendance record (e.g., April 15th).
5. Go to Reporting > Time Off Ledger and remove all filters.
 -> Attendance is correctly shown for all dates from April 1st
6. Create a public holiday on April 16th starting at 00:00.
7. Check the Time Off Ledger again.

**Issue:**
The attendance entry for April 15th disappears after adding the public holiday.

**Cause:**
Calendar leave datetime fields (date_from/date_to) are stored in UTC but compared against attendance dates without converting to the employee's resource calendar timezone, causing date boundaries to shift and records to be incorrectly excluded.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L133-L144

**Solution:**
Convert calendar leave datetimes to the employee timezone before casting to date, ensuring comparisons reflect the correct local boundaries.

**NOTE:**
This issue is mainly reproducible on runbot since its server timezone is
GMT. On local machines configured with UTC, the stored datetime values
already align with the expected conversions, so the date shift does not occur.


opw-6118043




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

Forward-Port-Of: odoo/odoo#262179

Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result:

1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings.
2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself.

Solution
-----
For the first problem, there are a couple things to keep in mind:
- the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer
- products can be added and removed from the picking after the SO has been confirmed
- actual delivery cost can change between invoice date and actual delivery date
- picking can be split into multiple packages at the user's discretion

Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders.

-----
Ticket:
opw-6013387

Forward-Port-Of: odoo/enterprise#117115
Forward-Port-Of: odoo/enterprise#111304

# How to reproduce
- Create 2 MO's A & B, both having the same product_id & bom_id
- Split MO A into two MO's A1 & A2
- Merge MO's A1 & B

# The issue
MO A2 no longer has a production group (visible via Studio).
If the user tries to partially produce the MO and create a backorder, a traceback popup appears with :

"ValueError: max() iterable argument is empty"

# Cause
The traceback is triggered because we use the `max()` function on `self.production_group_id.production_ids` when creating the backorder, but `production_ids` is an empty recordset since `production_group_id` is also empty.

https://github.com/odoo/odoo/blob/0d8eaeeb971f2f670aebb1b72ed03f4a2d5e0105/addons/mrp/models/mrp_production.py#L1936

The production group is empty because when merging two MO's we delete it without paying attention to other remaining links.

https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/mrp/models/mrp_production.py#L2555

Note : the production groups were introduced by this commit (https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a)

# Proposed solution
When merging, we unlink the original MO's from their production group.
Then, we check every altered production group : if they are not linked to any MO anymore, we delete them.

opw-6055376

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

Forward-Port-Of: odoo/odoo#256600

### Description of the issue/feature this PR addresses: 
**Issue**: During KSeF authentication, some foreign qualified certificates causes a crash with error _"Failed to authenticate with XAdES: 400 Client Error: Bad Request for url: https://api.ksef.mf.gov.pl/v2/auth/xades-signature"_ This is due to Odoo not handling different `SubjectIdentifierType`

**Solution**: Implement a try/except block to safely check for the NIP in the certificate's subject string, defaulting the identifier type to `certificateFingerprint` when the NIP is missing or a ValueError is caught.

### Current behavior before PR:
The `SubjectIdentifierType` is hardcoded as `certificateSubject`, and does not handle `certificateFingerprint` at all. This causes there to be an error when trying to authenticate with the KSeF server using XAdES signature.

### Desired behavior after PR is merged:

The sign_authentication_challenge method will now safely evaluate the subject string. It assigns `certificateSubject` only if the NIP is verified to be in the subject string. If the NIP is absent or a ValueError occurs during parsing, the system safely falls back to using `certificateFingerprint`. This prevents tracebacks and ensures the correct XML payload is sent to the KSeF server.

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

Forward-Port-Of: odoo/odoo#264851

### Description of the issue/feature this PR addresses:

The business premises label on Croatian invoices can legitimately contain alphanumeric characters (e.g., "v1"), as noted in the field's tooltip.

However, the regex pattern inside `_get_l10n_hr_fiscalization_number` used to extract the sequence parts strictly expected digits (`\d+`) for the premises label segment. Because of this, if an invoice was generated with an alphanumeric sequence like `INV-2026-0001/v1/1`, the regex failed to match and returned `False`, leading to a traceback when the system attempted to process the fiscalization number.

This commit updates the regex to correctly accept alphanumeric characters for the premises label, ensuring the sequence parses successfully.

opw-6129009

### Steps to reproduce:

- Settings > Users & Companies > Companies > New > set Address country to Croatia
- Select the newly created Croatian company
- Apps > Activate l10n_hr_edi module
- Accounting > Configuration > Accounting > Journals > click Sales journal > change “Business premises label” to “v1”
- Contacts > New > set Address country to Croatia
- Accounting > Customers > Invoices > New > select the newly created contact and choose any product > Confirm

### Current behavior before PR:

Traceback error when attempting to confirm an invoice when both the company and the customer have their country code set to 'HR'. This is because `_get_l10n_hr_fiscalization_number` does not accept alphabet characters in the premises label section of the regex.

### Desired behavior after PR is merged:

- No traceback error when confirming the invoice
- `_get_l10n_hr_fiscalization_number` correctly parses the fiscalization number

Forward-Port-Of: odoo/odoo#263650

Overview
------

When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up.

How to Reproduce
------

1. Open the Email Marketing app
2. Create a new mailing (or you can use an existing one that has some clicks) and send it
3. Make a click in the email from the recipient's side
4. Open the link tracker `click` related to that mailing (select the mailing → `Link Trackers` stat button → click on a link → `Clicks` stat button)
5. Make a search based on the Link (short_url) field

Expected Behavior
------

Return the list of links that matches the entered search query.

Current Behavior
------

Odoo Server Error.

Cause & Solution
------

The cause of this error is that the `shor_url` field is a computed, non-stored, field, and hence, we cannot directly make a search on it. So, either we make the `short_url` a stored field, which is not so efficient, or we create our own custom `_search_..` method.

Task-6131693

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

Forward-Port-Of: odoo/odoo#265059
Forward-Port-Of: odoo/odoo#260146

Issue:
------
`l10n_br.address_form_fields` inherits from `portal.address_form_fields` but targets a `<select>` element that was moved to `portal_address_extended.address_extended_form_fields` in [saas~19.2].

Traceback:
----------
```py
Error while parsing or validating view:

Element '<xpath expr="//select[@name=&#39;city_id&#39;]/option[not(@value=&#39;&#39;)]">' cannot be located in parent view
```

Steps to reproduce:
-------------------
1. Install `l10n_br` in v19
2. Upgrade to v19.2
3. Upgrade the `l10n_br` module →  Traceback

Root cause:
-----------
The view is adapting an element owned by a sibling view, making the inheritance hierarchy conceptually wrong and fragile.

Solution:
---------
Update the `inherit_id` of `l10n_br.address_form_fields` to `portal_address_extended.address_extended_form_fields` so it correctly inherits from the view that owns the targeted element.

opw: [6125901]

[saas~19.2]: https://github.com/odoo/odoo/commit/026c6f9f2a388ee509a135c53e38f5bb3d08ff73
[6125901]: https://www.odoo.com/odoo/70/tasks/6125901?debug=1

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

Currently an error occurs when the user removes the Source Entity Id Type on Super Contributions.

**Steps to Reproduce:**
 - Install `l10n_au_hr_payroll_account` with demo data.
 - Switch to an `Australian` company.
 - Go to `Payroll` > `Reporting` > `Australia` > `Super Contributions`.
 - Open an existing record or create a new one.
 - Remove the `Source Entity Id Type` value and click anywhere.

`ValueError: Compute method failed to assign l10n_au.super.stream(<NewId origin=1>,).source_entity_id`

After [change] in the selection field behavior, when the user removes the Source Entity Id 
Type, the compute method is triggered to compute the Source Entity ID. However, the 
condition in the compute method is not match, so no value is assigned. As a result, 
the method fails and raises an error.

This commit ensures that if the condition is not match, the Source Entity ID is explicitly 
set to False.

[1]- https://github.com/odoo/enterprise/blob/9d523d7aabffda277e1ef734caf2b0e434545dca/l10n_au_hr_payroll_account/models/l10n_au_super_stream.py#L61-L65

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

Forward-Port-Of: odoo/enterprise#115466

When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.

`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.

The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.

The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.

Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown

=> Archived teams appear in the dropdown

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

Forward-Port-Of: odoo/odoo#263283
Forward-Port-Of: odoo/odoo#261300

## Issue
When making a request for quotation for a subcontracted product and returning the delivery "for exchange", the new incoming delivery does not have the correct destination. Instead of having the stock of the user, the destination of the new incoming delivery is the same as its source: the subcontracting location.

<img width="1254" height="257" alt="5479900" src="https://github.com/user-attachments/assets/c7e6d392-8328-4a03-a71e-466e768f448b" />

## Steps to reproduce
1. Install MRP Subcontracting (`mrp_subcontracting`) and Purchase (`purchase`)
2. In Settings, enable *Subcontracting*
3. Create a Product P and a subcontracting BoM with Subcontractor S
4. Create a Request for Quotation
    - Vendor: Subcontractor S
    - Product: Product P (any quantity > 0)
5. Confirm the RFQ, receive the PO, validate the picking
6. On the validated picking, click *Return*, set the quantity of products to return, and click *Return for Exchange*
    - This creates two new pickings, one to return the product(s) we received, and one to receive new products
7. Validate the two new pickings
8. **In Inventory > Reporting > Moves History, the very last `stock.move.line` has the same location in the *From* (`location_id`) and the *To* (`location_dest_id`) columns**

## Cause
The `location_dest_id` of the new `stock.move` is updated in `StockReturnPickingLine._prepare_move_default_values`.

https://github.com/odoo/odoo/blob/fb534f1eadcb8ef74e2ee6fd5b68872dddb978e3/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25

The condition added by https://github.com/odoo/odoo/commit/5404b426aac9 sets the destination of all returned subcontracted moves to the subcontractor location. This is incorrect when using "return for exchange", as in this case, the return move is directed towards the user's stock. In fact, when using "return for exchange", the following pickings are created:

| id | name         | return_id |   |
|:--:|--------------|:---------:|---|
| 1  | WH/IN/00001  |           | Initial RFQ delivery |
| 2  | WH/OUT/00001 |     1     | Return of the initial RFQ delivery |
| 3  | WH/IN/00002  |     2     | New products delivery to replace the initial delivery. The stock.move.line of this stock.picking has a wrong `location_dest_id` |

## Fix
In the context of return for exchanges, the returned item must be directed to the *Subcontracting Location* while the new item must be directed to   the *Stock*. In the `_prepare_move_default_values`, we should only set   the `location_dest_it` to the subcontractor location for outgoing pickings.

opw-5479900

Forward-Port-Of: odoo/odoo#265071
Forward-Port-Of: odoo/odoo#245905

The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs.

`MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id <<10`

This shifts the max aml.id 40 bits to the left.

Example:
Let's say MAX(aml.id) = 1; we will set the other variables to 1, as they often have little impact on the total size of the number.

1 << 20 = 1048576
1048576 | 1 = 1048577
1048577 << 10 = 1099512676352
1099512676352 | 1 = 1099512676353
1099512676353 << 10 = 1152922604119523328

With this format, the highest guaranteed AML ID this query can handle is under 838,861.

The last 10-bit shift is unnecessary and increases the result. If we remove the last shift, the AMD ID this query can handle becomes much higher.

`MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id`

|  | AML Max | RULES.ID Max |RULES.USER_ID Max|
| --------------------- | ------ | ------ |  ------ | 
| Before | 838,861  | 1,048,576 | 1,024 |
| After | 858,993,459 |1,048,576 | 1,024|

opw-6124026

Forward-Port-Of: odoo/enterprise#114711

**Problem:**
When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision.

**Steps to reproduce:**
1. Create a project with an analytic account
2. Create an analytic budget of $10,000 and confirm it
3. Create a revision of that budget for $15,000 and confirm it
4. Create a new project update
5. The update shows "$25,000" as the total budget instead of "$15,000"

**Current behavior:**
The project update displays the sum of all budget revisions ($25,000), regardless of their state.

**Expected behavior:**
Only the active confirmed budget ($15,000) should be used.

**Cause of the issue:**
`_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent.

**Fix:**
Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows.

opw-6128855

Forward-Port-Of: odoo/enterprise#117490
Forward-Port-Of: odoo/enterprise#115285