This update strengthens automated coverage for CRM lead conversion, merging, and lost-lead workflows. It helps reduce the risk of regressions as future CRM improvements are made, making sales pipeline handling more dependable.

The project overview now gives managers clearer profitability and task status information, including late tasks, overtime tasks, and other project revenues. It also makes sales order details collapsible by default and fixes multi-company employee filtering so reports show the right people data.

1)  Add the following stat buttons on the right of the Tasks one:
- (fa-tasks) Late Tasks: tasks whose deadline is exceeded (do not include tasks that
  don't have a deadline set)
- (fa-tasks) Tasks in Overtime: tasks whose Effective hours are strictly greater than
  their Planned hours (if the latter is stricly greater than 0)

2) Remove the sheet view (should be like financial reports)

3) Add an 'Other Revenues' metric under the Profitability section below 'To Invoice'
- It should represent all the revenues other than from timesheets linked to the analytic
  account of the project.
- Only visible if greater than 0

4) Allow to fold/unfold the details by SO. It should be folded by default.
Note: Although qweb views have a generic mechanism to manage fold and unfold, this standard
behavior is not used here.
It would imply refactoring the entire code preparing the template data (700+ lines of
code which are hard to read). The quick and dirty way is used for now.
(I wish good luck for the dev if it's one day necessary.)

Task 2119567

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

Manufacturing work orders are now planned to avoid unnecessary overlaps between jobs, reducing inefficient task switching on the shop floor. The update also improves schedule conflict detection, required date handling, and work order view usability.

[IMP] mrp: change workorder plan behavior

Before the auto-planning of workorder autorize overlaps between then.
E. g. if a workorder begin in now + 30 min with a duration of 60 minutes
and we try to plan a new workorder now, this one will be plan now
until now + 120 min (30 min + 30 min).
In our case we don't want that this behavior by default,
(because in real case, it is not efficient to work on job A during
30 min, after change to pass to a other job B, and rework on A after
the job B).
But in a other hand, we need to accept overlaps with no-working hours
intervals. Then, rewritte the _plan_workorders method to take
these in account.

[IMP] mrp: improve small details of WO views/model

- Now, the fields date_planned_start and date_planned_finished is
required in views, because it was strongly related to the leave date_to, date_from
which are required.
- Change the name get in case of single WO in MO and replace the dot
by a dash.
- Improve the WO views to be more responsible when it is open from the
gantt view.
- Change name of a Operation in the demo data

[FIX] mrp: truncate millisecond to check overlaps

In some flows, a planned_datetime_start/finished will contains
milliseconds. In these cases, we can detect overlaps/conflicts between
workorders but these conflicts can't be see in the web interface
(because datetime is round when it is display).
Then, change the conflicts computation to remove milliseconds
in search of conflicts.

task-2169447

This update improves how employee appraisals and field service worksheet templates behave when several companies use the same system. It helps ensure users see company-appropriate appraisal information and lets businesses assign worksheet templates to specific companies, reducing mistakes in multi-company operations.

This update fixes an unstable automated test related to Discuss message history. It helps ensure test results are consistent, reducing false failures during development and release validation.

Follow up on 2f3e6e9ea8e8f747f7f5f9210ddc6d147863f40f

The issue is still not fixed. Here is a new attempt.

This update makes Odoo use the same product account lookup method in more places, reducing inconsistencies between accounting, sales, point of sale, and stock flows. It is an internal cleanup that should make financial postings more reliable without changing day-to-day workflows.

**Description of the issue/feature this PR addresses:**
this PR is a refactor.
the product has a new function ``_get_product_accounts``, but this function is not called in all Odoo.

This PR fixes that.

kind regards.

CC : @mart-e 

CC : @OCA/accounting-maintainers

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

This change reverses a previous adjustment that moved mail-related tests to a later installation phase. The reversal is intended to prevent random build failures in automated validation, helping keep development pipelines reliable.

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

This update fixes several business-facing issues across Odoo, including cleaner price list formatting, more consistent payment records after cancellation, and faster accounting setup checks on large databases. It also improves payment testing links, video autoplay behavior, and progress bar editing stability.

Task: https://www.odoo.com/web#id=2154331&action=327&model=project.task&view_type=form&menu_id=4720
Pad: https://pad.odoo.com/p/r.f9c119c6725985b33681500e5119ce69

The Studio app creator has been reworked to align with Odoo's newer interface framework. This keeps the app creation experience reliable as the web client evolves, with related tests updated to support the change.

Used the different Widget>Component and Component>Widget adapters to properly
re-write the app creator action. This refactor includes:
- the app creator (js, xml and tests)
- the web client: adapted new event logic

This pull request adds CodeSource's corporate contributor license agreement documentation and updates related CLA records after a company change. It helps keep Odoo's contribution permissions and legal records accurate.

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

Small fix on the template to ensure the size of the partners's images will never be larger than 128px. Forward-Port-Of: odoo/odoo#43691

Small fix on the template to ensure the size of the partners's
images will never be larger than 128px.

Forward-Port-Of: odoo/odoo#43691

…en city is set, but not city_id 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#43586

…en city is set, but not city_id

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#43586

Task - https://www.odoo.com/web#id=2150471&action=327&model=project.task&view_type=form&menu_id=4720 Pad - https://pad.odoo.com/p/r.c90eef9080287f1d23546775b20a24eb - There will be extra space at bottom while adding a <sheet> in wizard form view. The space should not be shown there. This issue has been fixed by this commit. Forward-Port-Of: odoo/odoo#43833 Forward-Port-Of: odoo/odoo#41619

Task -  https://www.odoo.com/web#id=2150471&action=327&model=project.task&view_type=form&menu_id=4720
Pad -  https://pad.odoo.com/p/r.c90eef9080287f1d23546775b20a24eb

- There will be extra space at bottom while adding a <sheet> in wizard form view. The space should not 
   be shown there.  This issue has been fixed by this commit.

Forward-Port-Of: odoo/odoo#43833
Forward-Port-Of: odoo/odoo#41619

The move snippet arrows where not hiding properly when the target was not movable. task-2180396 Forward-Port-Of: odoo/odoo#43792

The move snippet arrows where not hiding properly when the target was
not movable.

task-2180396

Forward-Port-Of: odoo/odoo#43792

This commit adds a wrapper element around the form view's notebook tabs headers to allow the use of `overflow` and make it scrollable (e.g. on smaller screens) without breaking the tabs' styling (e.g. the bottom border). This commit fixes an issue introduced by odoo/enterprise@e07aafbe6fee9e568274c0e157645925dc1f6878. 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

This commit adds a wrapper element around the form view's notebook
tabs headers to allow the use of `overflow` and make it scrollable (e.g.
on smaller screens) without breaking the tabs' styling (e.g. the bottom
border).

This commit fixes an issue introduced by odoo/enterprise@e07aafbe6fee9e568274c0e157645925dc1f6878.

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#43818

Purpose ======= Clean the context to get rid of residual default_* keys that could cause issues afterward during the mail.message generation. Example: 'default_parent_id' would refer to the parent_id of the current record that was used during its creation, but could refer to wrong parent message id, leading to a traceback in case the related message_id doesn't exist TaskID: 2176445 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behav

Purpose
=======

Clean the context to get rid of residual default_* keys
that could cause issues afterward during the mail.message
generation. Example: 'default_parent_id' would refer to
the parent_id of the current record that was used during
its creation, but could refer to wrong parent message id,
leading to a traceback in case the related message_id
doesn't exist

TaskID: 2176445

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#43649
Forward-Port-Of: odoo/odoo#43405

Description of the issue/feature this PR addresses: The order of the view is gantt,calendar,list but if you come form the saas-12.3 the view_id will remain defined with a calendar view Desired behavior after PR is merged: So we need to erase that value to have the gantt view by default -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#43720

Description of the issue/feature this PR addresses:
The order of the view is gantt,calendar,list but if you come form the saas-12.3 the view_id will remain defined with a calendar view

Desired behavior after PR is merged:

So we need to erase that value to have the gantt view by default



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

Forward-Port-Of: odoo/odoo#43720

### Description of the issue/feature this PR addresses: This kind of companies (because of the AFIP responsibility type) should not have purchase tax defined by default and before this commit we have a default purchase tax named perception with actually is a optional tax that the user could set if needed but should not be set automatically set as default in all the vendor bill lines. This commit remove this default purchase tax when loading the chart of account to avoid this bad behavior.

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

This kind of companies (because of the AFIP responsibility type) should not have purchase tax defined by default and before this commit we have a default purchase tax named perception with actually is a optional tax that the user could set if needed but should not be set automatically set as default in all the vendor bill lines.  This commit remove this default purchase tax when loading the chart of account to avoid this bad behavior.

### Current behavior before PR:

Purchase default tax is set as "Perception IIBB CABA Sufrida" in Monotributista and Exempt companies

![image](https://user-images.githubusercontent.com/7593953/72750729-5e39ba80-3b9c-11ea-989a-b1932485a1f1.png)

### Desired behavior after PR is merged:

Purchase default tax is set as "Undefined" in Monotributista and Exempt companies

![image](https://user-images.githubusercontent.com/7593953/72750711-567a1600-3b9c-11ea-90ba-3b748105dad5.png)



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

Forward-Port-Of: odoo/odoo#43597

Before this commit, in the list of invoices the customers were displayed using only their names and not the company that they belong. For instance, if 'Brandon Freeman' is part of the 'Azure Interior' company, only his name was shown. Now, the company names is also shown. In our example, the customer will be displayed as : 'Azure Interior, Brandon Freeman'. This behaviour was already the case in version 12. opw-2179722 Forward-Port-Of: odoo/odoo#43808

Before this commit, in the list of invoices the customers were displayed
using only their names and not the company that they belong.

For instance, if 'Brandon Freeman' is part of the 'Azure Interior'
company, only his name was shown.

Now, the company names is also shown. In our example, the customer will
be displayed as : 'Azure Interior, Brandon Freeman'.

This behaviour was already the case in version 12.

opw-2179722

Forward-Port-Of: odoo/odoo#43808

Main ----- For Huge Amount Invoices with small residual being paid and the Invoice and the initial payment which almost paid, the invoice in full can render the reconciliation of the Tax Entry Lines as fully reconciled. And when the small part to be reconciled is tried to be closed a traceback is raised because the line being reconciled in CABA entry is dimmed as reconciled. Conclusion ---------- There are cases where invoices with tiny residuals in multi-currency cannot be processed

Main
-----

For Huge Amount Invoices with small residual being paid and the Invoice and the initial payment which almost paid, the invoice in full can render the reconciliation of the Tax Entry Lines as fully reconciled. And when the small part to be reconciled is tried to be closed a traceback is raised because the line being reconciled in CABA entry is dimmed as reconciled.

Conclusion
----------

There are cases where invoices with tiny residuals in multi-currency cannot be processed and fully paid, because there are CABA entry lines being created and computed as reconciled.

Description
-----------

In case of multi-currency transactions where CABA Journal Entries are involved, there could be
a case where ,in Mexican Localization, so far, a small entry line cannot be reconciled with their counterpart because the previous counterparts are already reconciled. (Though this is still unproved in a lab, i.e. UnitTest, can be seen in the wild, i.e. Customer's Production Instance) 

The following is a hypothetical case yet to be proven. `Yet this has been spotted several times on the wild`

        Test to validate tax effectively receivable

        My company currency is MXN.
        Invoice issued two days ago in USD at a rate => 1MXN = 0.80 USD.
        Booked like:
            Receivable          1450                1160    USD
                Revenue                 1250       -1000    USD
                Taxes to Collect         200        -160    USD (Hypothetical Fully Reconciled with A1)
        Payment issued today in USD at a rate => 1 MXN = 1.25 USD.
        Booked like:
            Bank                 927.99                1159.99    USD
                Receivable               927.99       -1159.99    USD

        And a Tax Cash Basis Entry is generated for the ratio being paid
        Booked like:
            Tax Base Account     800                1000.00    USD (sometimes this base can be rounded up and instead of being 999.99 it ends up as 1000.00 which leads to taxes to be as fully reconciled)
                Tax Base Account         800       -1000.00    USD
            Taxes to Collect     128                 160    USD (Hypothetical Fully Reconciled with A1)
                Taxes to Paid            128        -160    USD

        I will neglect to depict here the FX Journal Entry for Tax to Collect account for the hypothetical reconciliation A1. And any other FX Journal Entries.

        At this moment Invoice has a USD 0.01 residual which on same date will be tried to write-off manually.

            Write-off              0.01                   0.01    USD
                Receivable                 0.01          -0.01    USD

        At this moment Invoice has a USD 0.01 residual which on same date will be tried to write-off manually.
        This small amount will create while running in run-time following CABA Journal Entry:
            Tax Base Account     0.01                0.01    USD (sometimes this base can be rounded up and instead of being 0.00 it ends up as 0.01 which leads to taxes to be created and be tried to reconcile)
                Tax Base Account         0.01       -0.01    USD
            Taxes to Collect     0.01                 0.01    USD (Hypothetical This will be tried to reconcile with the items in Full Reconciliation A1 but raise an error)
                Taxes to Paid            0.01        -0.01    USD


This PR is related to the way reconciliation is performed as shown in https://github.com/odoo/odoo/pull/41512

This is shown to at https://github.com/odoo/odoo/issues/37469

OPW
---
2177558

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

Forward-Port-Of: odoo/odoo#43786
Forward-Port-Of: odoo/odoo#33585

Since the renaming of image fields to image_resolution (image_1920 in our case) slide upload widget is using invalid field. This commit adapt the field name to use the new naming (image_1920) instead. Task id: 2179219 Forward-Port-Of: odoo/odoo#43663

Since the renaming of image fields to image_resolution (image_1920 in our case)
slide upload widget is using invalid field.
This commit adapt the field name to use the new naming (image_1920) instead.

Task id: 2179219

Forward-Port-Of: odoo/odoo#43663

This commit fixes the insert_record override where, after calling super, the visitor is linked a lead with the id got from result, no matter if the model is lead or not. This commit adds the check to apply the link between visitor and lead only if the current model is crm.lead. Task ID: 2179631 Forward-Port-Of: odoo/odoo#43731

This commit fixes the insert_record override where, after calling super,
the visitor is linked a lead with the id got from result, no matter if the
model is lead or not.

This commit adds the check to apply the link between visitor and lead only if
the current model is crm.lead.

Task ID: 2179631

Forward-Port-Of: odoo/odoo#43731

Steps to reproduce: - install accounting - go to accounting > configuration > charts of account - create a chart of account with a code containing leading zero's (ex: 000022) - duplicate the previously created chart of account Previous behavior: leading zero's are not kept trough duplication Current behavior: the new code is padded with leading zero's to keep the same length opw-2172816 Forward-Port-Of: odoo/odoo#43770

Steps to reproduce:
- install accounting
- go to accounting > configuration > charts of account
- create a chart of account with a code containing leading zero's
(ex: 000022)
- duplicate the previously created chart of account

Previous behavior:
leading zero's are not kept trough duplication

Current behavior:
the new code is padded with leading zero's to keep the same length

opw-2172816

Forward-Port-Of: odoo/odoo#43770

The user is able to enter the form view of the BOM and the ECO button is hidden. task_id : 2165656 Forward-Port-Of: odoo/enterprise#7783

The user is able to enter the form view of the BOM and the ECO button is hidden.

task_id : 2165656

Forward-Port-Of: odoo/enterprise#7783

This commit fixes an issue introduced in the commit odoo/enterprise@e07aafbe6fee9e568274c0e157645925dc1f6878 where the notebook's headers container was added only on mobile instead of all the time. This commit removes the code that will be reintroduced in community (in the original _renderTagNotebook method). Forward-Port-Of: odoo/enterprise#7891

This commit fixes an issue introduced in the commit odoo/enterprise@e07aafbe6fee9e568274c0e157645925dc1f6878
where the notebook's headers container was added only on mobile instead
of all the time. This commit removes the code that will be reintroduced
in community (in the original _renderTagNotebook method).

Forward-Port-Of: odoo/enterprise#7891

When the format of structured communication was not recognised, the strctured_com variable was not declared, but returned by the function Forward-Port-Of: odoo/enterprise#7890

When the format of structured communication was not recognised, the
strctured_com variable was not declared, but returned by the function

Forward-Port-Of: odoo/enterprise#7890

### Issue - Install Documents - Switch to Dutch Tags & filters not translated ### Cause We get tags & filters from a SQL query which doesn't take translations into account. ### Solution Replace tags & filter names from the SQL query by translated ones. **OPW-2172798** Forward-Port-Of: odoo/enterprise#7868

### Issue

    - Install Documents
    - Switch to Dutch

    Tags & filters not translated

### Cause

    We get tags & filters from a SQL query which doesn't take
    translations into account.

### Solution

    Replace tags & filter names from the SQL query by translated
    ones.

**OPW-2172798**

Forward-Port-Of: odoo/enterprise#7868

Forward-Port-Of: odoo/enterprise#7882 Forward-Port-Of: odoo/enterprise#7876

Forward-Port-Of: odoo/enterprise#7882
Forward-Port-Of: odoo/enterprise#7876

When `partner_autocomplete` is uninstalled, the partner creation crashes because of the non-existing field `partner_gid`. `partner_autocomplete` doesn't seem to be used for anything else than this in the module, so we don't change the dependencies and do a workaround instead. opw-2169900 Forward-Port-Of: odoo/enterprise#7850

When `partner_autocomplete` is uninstalled, the partner creation crashes
because of the non-existing field `partner_gid`.

`partner_autocomplete` doesn't seem to be used for anything else than
this in the module, so we don't change the dependencies and do a
workaround instead.

opw-2169900

Forward-Port-Of: odoo/enterprise#7850