Project lists now include a budget spent field, making it easier for teams to see budget consumption at a glance. This helps managers monitor project financial progress without opening each project individually.

Purpose of the PR is to do the generic improvements for project.

So in this PR did the following changes:
- add the field budget spent in project list view.

task - 3178057

This change removes an old mail utility file after moving its remaining email parsing function to the newer shared location. It helps keep the codebase cleaner and reduces reliance on deprecated components, with no expected direct impact for end users.

This commit moves parseEmail() to `@mail/utils/common/format.js` and deletes deprecated file `@mail/js/utils.js`.

The other functions are already implemented by newer utils file `@mail/utils/common/format.js`

Odoo PR:  [#144155](https://github.com/odoo/odoo/pull/144155)

The Belgian POS black box module was updated to use the same dialog experience as other POS modules. This is an internal modernization that should make future maintenance easier while keeping cashier workflows consistent.

In this commit we adapt the `pos_black_box` module to use the `dialog_service`, as the rest of the pos modules

Task 3613484

Purpose ======= This is breaking the hr.employee.public prefetching Forward-Port-Of: odoo/enterprise#51048

Purpose
=======

This is breaking the hr.employee.public prefetching

Forward-Port-Of: odoo/enterprise#51048

[PERF] mail: faster load of discuss at init messaging - Messaging menu was slow when there are many mail failures - Discuss app is slow whenever there are many pinned threads - Initial page load was slow when pinned threads were group chats with hundreds of members All these performance issue come from aggressively eager call to reactive callbacks, which `onChange()` and `compute()` were relying on. This commits fixes the performance issue with: - Update cycle in `@mail/record`,

[PERF] mail: faster load of discuss at init messaging

- Messaging menu was slow when there are many mail failures
- Discuss app is slow whenever there are many pinned threads
- Initial page load was slow when pinned threads were group chats
  with hundreds of members

All these performance issue come from aggressively eager call
to reactive callbacks, which `onChange()` and `compute()` were
relying on.

This commits fixes the performance issue with:
- Update cycle in `@mail/record`, which calls eager computed fields
  and onChange at the end of an update transaction in discuss models,
  so that computation is called only once rather than many times
  (while only the later value matter)
- Add support for lazy computed fields (which they are by default),
  so that computed fields are only computed when needed.
- Add support for sorted many fields, which also follow the update
  cycle and eager/lazy mode of field. This makes sorting operation
  on many fields efficient and preserves eventual correctness of
  expected order of items in these relational fields.

With module `contacts` installed and populate `--size="medium"`,
init_messaging and mail_failures took 12sec. for Mitchell Admin.
With this commit, this has been reduced to 1sec.

https://github.com/odoo/odoo/pull/143382

Forward-Port-Of: odoo/enterprise#51410

Description of the issue/feature this PR addresses: Several fixes and updates for the not yet complete Austrian Localization, started to prepare in Valencia on the OCA Code Sprint. Should be merged and is dependent on https://github.com/odoo/odoo/pull/134959 Info: @wt-io-it Forward-Port-Of: odoo/enterprise#50806 Forward-Port-Of: odoo/enterprise#47198

Description of the issue/feature this PR addresses:
Several fixes and updates for the not yet complete Austrian Localization, started to prepare in Valencia on the OCA Code Sprint.

Should be merged and is dependent on https://github.com/odoo/odoo/pull/134959

Info: @wt-io-it

Forward-Port-Of: odoo/enterprise#50806
Forward-Port-Of: odoo/enterprise#47198

Prior to this commit, attempting to invoice a paid order in the POS Restaurant module would result in an error due to 'selectedOrder' being undefined. This issue was observed when trying to process the invoicing of an already paid order. This commit resolves the issue by ensuring that the order is passed as a prop to the AddInfoPopup. opw-3590978 Forward-Port-Of: odoo/enterprise#51433 Forward-Port-Of: odoo/enterprise#50818

Prior to this commit, attempting to invoice a paid order in the POS Restaurant module would result in an error due to 'selectedOrder' being undefined. This issue was observed when trying to process the invoicing of an already paid order.

This commit resolves the issue by ensuring that the order is passed as a prop to the AddInfoPopup.

opw-3590978

Forward-Port-Of: odoo/enterprise#51433
Forward-Port-Of: odoo/enterprise#50818

**Before this PR:** -Message character limits are visible after posting a message on Twitter. -There is no space between globe icon and text in the posts by accounts section. **After this PR:** -Message character limits will be hidden after posting a message on Twitter. -Space will be added between text and globe icon in the posts by accounts section. **Task**-3459739 Forward-Port-Of: odoo/enterprise#49033

**Before this PR:**
-Message character limits are visible after posting a message on Twitter. 
-There is no space between globe icon and text in the posts by accounts section.

**After this PR:**
-Message character limits will be hidden after posting a message on Twitter. 
-Space will be added between text and globe icon in the posts by accounts section.

**Task**-3459739

Forward-Port-Of: odoo/enterprise#49033

# Context A recent bugfix PR (https://github.com/odoo/enterprise/pull/50621) added a new function `_get_email_reply_to` in aims to correctly fetch an approriate reply-to email address if it was setup in the email template used for the followup messages. But inadvertently it introduced and unexpected behavior: if the email template has no reply-to set, the function returns `False`. In that scenario, when the final email gets prepared for sending out, calling `IrMailServer.build_email` and rep

# Context
A recent bugfix PR (https://github.com/odoo/enterprise/pull/50621) added a new function `_get_email_reply_to` in aims to correctly fetch an approriate reply-to email address if it was setup in the email template used for the followup messages.

But inadvertently it introduced and unexpected behavior: if the email template has no reply-to set, the function returns `False`. In that scenario, when the final email gets prepared for sending out, calling `IrMailServer.build_email` and reply-to is `False`, it falls back to the the `email_from` encoded in the email.

So in pratice, instead of using the default catchall email address, it will use the same email for the `From` and `Reply-To` email headers.

This is an issue, since replying to the followup email will not correctly reroute the incoming email to the correct model (res.partner in this case).

# How to reproduce:
1) Make sure that the default template for the followup emails has no reply-to set up (should be the case on a fresh database).
Set up a system parameter for `Key -> mail.catchall.domain` with example
`Value -> mycompany.example.com`
2) Go to Accounting > Customers > Follow-up Reports 
3) Select a record
4) Click the "Follow Up" button which will open up the wizard. Let's assume that contact uses "partner@email.com" as email address and that current internal user uses "user@internal.com"
5) Send out email with default values

Email being sent will show:

Before this fix:
`Reply-To: "User" <user@internal.com>`
`To: "Partner" <partner@email.com>`

After this fix:
`Reply-To: "Company" <catchall@mycompany.example.com>`
`To: "Partner" <partner@email.com>`

opw-3605881

Forward-Port-Of: odoo/enterprise#51631
Forward-Port-Of: odoo/enterprise#51577

During the removal of jQuery BBQ library [1], an `Event.getState()` call was unfortunately left. This resulted in a crash when using the device's back button/gesture, which triggers a 'hashchange' event, but only in the mobile apps (iOS and Android). This commit properly converts the related event handling to use the native window.location API. Steps to reproduce: - Open the backend using the mobile app - Go to an app - press the back button/execute the back gesture => error: e.getSt

During the removal of jQuery BBQ library [1], an `Event.getState()` call was unfortunately left.

This resulted in a crash when using the device's back button/gesture, which triggers a 'hashchange' event, but only in the mobile apps (iOS and Android).

This commit properly converts the related event handling to use the native window.location API.

Steps to reproduce:
- Open the backend using the mobile app
- Go to an app
- press the back button/execute the back gesture => error: e.getState is not a function

opw-3602245

[1]: odoo/odoo@507c36883675a45a15485ce5c73aa4557ba23639

Forward-Port-Of: odoo/enterprise#51402

Steps to reproduce: - Install l10n_ec_edi - Create a vendor bill: * Customer: [Ecuadorian contact] (e.g. Instituto Ecuatoriano de Seguridad Social) * Payment Method (SRI): Otros con utilización del sistema financiero * Document Number: [any] * Invoice Lines: 1. Product: [any product] - Price: 100 - Taxes: IVA 12% 2. Product: [no product] - Price: 0 [x] - Taxes: IVA 12% [x] A price of 0 is used to highlight the issue, but the amount doesn't matter - Save and confirm

Steps to reproduce:
- Install l10n_ec_edi
- Create a vendor bill:
  * Customer: [Ecuadorian contact] (e.g. Instituto Ecuatoriano de Seguridad Social)
  * Payment Method (SRI): Otros con utilización del sistema financiero
  * Document Number: [any]
  * Invoice Lines:
    1. Product: [any product] - Price: 100 - Taxes: IVA 12%
    2. Product: [no product] - Price: 0 [x] - Taxes: IVA 12%
    [x] A price of 0 is used to highlight the issue, but the amount doesn't matter
- Save and confirm the invoice
- Click on "ADD WITHHOLD" button
=> The base amount of the withhold lines is not computed correctly.

One line with a retention tax seems correct: (it's only correct because the tax amount of the second invoice line is 0.00)
Tax Support: 01 Tax credit for VAT declaration (services and goods other than inventories and fixed assets)
Tax: 10% Retención IVA
Base: 12.00
Amount: 1.20

The second line with a retention tax is not correct:
Tax Support: 01 Tax credit for VAT declaration (services and goods other than inventories and fixed assets)
Tax: 20% Retención IVA
Base: 12.00
Amount: 2.40

Base and Amount of the second line should be 0.
This line doesn't appear if the invoice line without product and a price of 0 is removed.

Cause:
During the computation, the subtotals and tax amounts of each invoice lines are summed and grouped by Tax Support code.
The Base field of the withhold line is then computed from these grouped subtotals or taxes, depending only on the Tax Support code, without taking into account the fact that the withhold tax can be different.
That's why the base amount of the incorrect withhold line is 12 (instead of 0).
As it has the same Tax Support code than the first line, its value is fetched from the sum made for that Tax Support code.

Solution:
The computation of the Base amount of the withhold lines should take into account
the Tax Support code, but also the applied tax.

opw-3478803

Forward-Port-Of: odoo/enterprise#48403

Description of the issue: I am unavailable' button should only be visible in the 'My planning' menu. Desired behavior after PR is merged: Button only visible in My planning menu,it will invisible from other menu. Fix: condition added to button if particular context not found make button invisible task-3280805 Forward-Port-Of: odoo/enterprise#51458 Forward-Port-Of: odoo/enterprise#43365

Description of the issue: I am unavailable' button should only be visible in the
'My planning' menu.

Desired behavior after PR is merged:
Button only visible in My planning menu,it will invisible from other menu.

Fix:
condition added to button if particular context not found make button invisible

task-3280805

Forward-Port-Of: odoo/enterprise#51458
Forward-Port-Of: odoo/enterprise#43365

To be approved for the bookkeeping act, we need to generate reports based on tags instead of account codes. It allows users to link their existing CoA to the one we decide. To do it, they can add the right tags on their own accounts. task-id: 3593634 Forward-Port-Of: odoo/enterprise#50676

To be approved for the bookkeeping act, we need to generate reports
based on tags instead of account codes. It allows users to link
their existing CoA to the one we decide. To do it, they can add the
right tags on their own accounts.

task-id: 3593634

Forward-Port-Of: odoo/enterprise#50676

…ng invcron Before this commit, it was possible to launch the subscription invoice cron when the deferred journal or account was not properly set in the settings. As a result, the invoice was created in draft, the payment request was performed but the invoice was not posted. Then the system was rollback. An email indicating the issue was sent but it was not clear enough. This commit improve the email content and prevent to launch the cron if the deferred revenues are not properly configured.

…ng invcron

Before this commit, it was possible to launch the subscription invoice cron when the deferred journal or account was not properly set in the settings. As a result, the invoice was created in draft, the payment request was performed but the invoice was not posted. Then the system was rollback. An email indicating the issue was sent but it was not clear enough. This commit improve the email content and prevent to launch the cron if the deferred revenues are not properly configured.

opw-ticket: 3565556

Forward-Port-Of: odoo/enterprise#51515
Forward-Port-Of: odoo/enterprise#50897

In this commit we fix _lt with _t. Let's see more informations on https://github.com/odoo/odoo/pull/124157 Forward-Port-Of: odoo/enterprise#51443

In this commit we fix _lt with _t.
Let's see more informations on https://github.com/odoo/odoo/pull/124157

Forward-Port-Of: odoo/enterprise#51443

Steps to reproduce: - Enable the merge on account.account in data cleaning APP (in debug) - Create an invoice with a receivable account = A - Define a lock date after the invoice date - Go to chart of accounts - Select your receivable = A et receivable = B - Action = Merge accounts where B is the MASTER Issue: Upon revisiting the customer invoice: Notice that the journal items have been updated. Solution: We simply prevent ~~the use of a nuclear weapon~~ the merge of `account.ac

Steps to reproduce:

- Enable the merge on account.account in data cleaning APP (in debug)
- Create an invoice with a receivable account = A
- Define a lock  date after the invoice date
- Go to chart of accounts
- Select your receivable = A et receivable = B
- Action = Merge accounts where B is the MASTER

Issue:
Upon revisiting the customer invoice: Notice that the journal items have been updated.

Solution:
We simply prevent ~~the use of a nuclear weapon~~ the merge of `account.account` as there other possibilities less dangerous such as multi-edit + archiving

We also prevent the merge of `res.partner` if this one is used in hashed entries

OC: https://github.com/odoo/odoo/pull/134634
opw-3389157

Forward-Port-Of: odoo/enterprise#51170
Forward-Port-Of: odoo/enterprise#47053