Accounting reports can now support custom grouping labels that are not tied to a standard business record. This helps teams create clearer specialized report lines, such as opening balance rows, while still allowing relevant drill-down actions where needed.

This commit adds the possibility to set string grouping keys in custom engines. These groupings won't be linked to a model and requires custom handling via a post_processor. Another feature added is a custom caret_builder that enable us to add custom caret identifiers to a specific grouping_key

This update makes it simpler to customize accounting report screens by letting custom components reuse the original layout automatically. It reduces the setup needed for tailored reporting views, helping implementations adapt reports with less duplication and maintenance.

This improvement allows to use a custom component override without defining a template. The custom component will take the template of the component it extends by default.

This update replaces an older way of switching records between active and archived states with the newer standard approach across several Odoo apps. The change helps keep behavior consistent and easier to maintain, with minimal direct impact for everyday users.

odoo/odoo#183691
odoo/documentation#11261

task-3983933

Appointment setup screens are easier to use with clearer field labels for questions and answers. Opening linked resources in a dialog helps users review or edit them without leaving the appointment form.

This commit makes the following changes to the appointment.type form views
- The form view will open as a dialog when we click on the resources filled in the resource_ids field.
- Change the label of `question_required ` and `answer_ids` fields.

Task-4256018

Large spreadsheets now load much faster by avoiding unnecessary server-side processing of already prepared data. This reduces waiting time for users opening spreadsheet documents and lowers server resource usage, especially for very large files.

Server-side load time for a 16.7Mb spreadsheet:

**before: 606ms**  (`join_spreadsheet_session`)
**after: 83ms** (-86%!) (new `/spreadsheet/data/<...>` controller)

Previously, `join_spreadsheet_session` returned a combination of:

- The full spreadsheet snapshot (JSON file on the filestore)
- Pending revision data (also serialized JSON, stored in a Char field)
- Additional metadata

These were combined into a Python dict and re-serialized into JSON for the response. This process is inefficient as it involved unnecessary parsing and re-serialization of already serialized JSON data.

With this commit, we handcraft the json response body, avoiding the need for parsing and re-serializing large json objects, resulting in significant performance improvements in both CPU and memory.

To have control of the response body, we now have to use an http controller instead of an RPC method.

We could also have sent the raw/serialized data from `join_spreadsheet_session` but then it would be serialized json over json which has several drawbacks:
- reduces client-side debuggability
- introduce a lot of additional escape characters (e.g. `\"`)
- the client would need to explicitly parse the nested json

With this solution, the client receives a clean, valid json content type

Alternative idea: we could stream the snapshot file directly from the file store to be even more efficient. But then we would need to load the additional metadata and revisions with another http request. As those two requests would not be executed as part of the same transaction, it would come with its own share of issues.

The Field Service “My Tasks” kanban view now shows task dates in the same format as other task menus, such as “All Tasks.” This makes scheduling information easier to compare and reduces confusion for users switching between views.

Currently, the date of tasks in kanban view of 'My Tasks' menu is only showing the start date of the task. But we would like to use the same display as in other menus (e.g. 'All Tasks') to remain consistent.

task-4193529

This change updates how list views are built behind the scenes so they use a shared row component. It should make future maintenance easier and help keep list behavior consistent across Odoo, with little direct impact on day-to-day users.

wip

Before this commit it was very difficult to change the logic of the CODA file parsing, if not copy-pasting `_parse_bank_statement_file` method in `account.journal`. Forward-Port-Of: odoo/enterprise#72302 Forward-Port-Of: odoo/enterprise#72169

Before this commit it was very difficult to change the logic of the CODA file parsing, if not copy-pasting `_parse_bank_statement_file` method in `account.journal`.

Forward-Port-Of: odoo/enterprise#72302
Forward-Port-Of: odoo/enterprise#72169

After https://github.com/odoo/odoo/commit/ca5dc74def3760bbd08b81c2f723392c444dc677 the demo loading is not done by default. It should be set explicitly in the demo data. task-no Forward-Port-Of: odoo/enterprise#72454 Forward-Port-Of: odoo/enterprise#72122

After https://github.com/odoo/odoo/commit/ca5dc74def3760bbd08b81c2f723392c444dc677 the demo loading is not done by default.
It should be set explicitly in the demo data.

task-no

Forward-Port-Of: odoo/enterprise#72454
Forward-Port-Of: odoo/enterprise#72122

In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Community PR: odoo/odoo#157362 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/enterprise#72484 Forward-Port-Of: odoo/enterprise#58487

In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags.

Community PR: odoo/odoo#157362
Task link: https://www.odoo.com/web#model=project.task&id=3794536
task-3794536

Forward-Port-Of: odoo/enterprise#72484
Forward-Port-Of: odoo/enterprise#58487

The span padding is taking too much place and prevent to click on the input above. So we set the correct class to avoid issues. Forward-Port-Of: odoo/enterprise#72573

The span padding is taking too much place and prevent to click on the input above.

So we set the correct class to avoid issues.

Forward-Port-Of: odoo/enterprise#72573

After [this refactoring] a regression occurred. Where previously the "XML" and "Copy to Documents" buttons were disabled when we didn't have the whole hierarchy of a company with its branches selected, it is not anymore. This commit fixes that. [task-4260501](https://www.odoo.com/odoo/all-tasks/4260501) [this refactoring]: https://github.com/odoo/enterprise/commit/1ea5dc3227913826a205b164c19e4771babc3326 Forward-Port-Of: odoo/enterprise#72465

After [this refactoring] a regression occurred. Where previously the "XML" and "Copy to Documents" buttons were disabled when we didn't have the whole hierarchy of a company with its branches selected, it is not anymore.

This commit fixes that.

[task-4260501](https://www.odoo.com/odoo/all-tasks/4260501)

[this refactoring]: https://github.com/odoo/enterprise/commit/1ea5dc3227913826a205b164c19e4771babc3326

Forward-Port-Of: odoo/enterprise#72465

We solve 2 issues: The first is that we want the user to be able to only reauthorize the actual account that he needs for the journal (and not all of them). The second is that the automatic redirection to reauthorize wasn't working due to the way Odoofin sends the infos. Now, it's sent in the result. task-4216399 Forward-Port-Of: odoo/enterprise#72032

We solve 2 issues:
The first is that we want the user to be able to only reauthorize the actual account 
that he needs for the journal (and not all of them).

The second is that the automatic redirection to reauthorize wasn't working 
due to the way Odoofin sends the infos. Now, it's sent in the result.

task-4216399

Forward-Port-Of: odoo/enterprise#72032

Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly runbot builds (but weirdly not on regular builds, probably due to the timing of stored fields recomputation and constraint validation). Essentially, the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L170 broke. This happe

Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly runbot builds (but weirdly not on regular builds, probably due to the timing of stored fields recomputation and constraint validation).

Essentially, the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L170 broke.

This happened because, when resetting the payment to draft in the test, we triggered this compute function on the account.payment https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_payment.py#L18. This compute function did not reassign the batch_payment_id field, but the ORM still considered it modified, and hence recomputed the payment method of the batch via this compute function https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L69 . Then, this field triggered the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L149.

The test raised then just when initializing the assertRaises, when the stored payment_method_id field of the batch got recomputed. It is possible to force it by flushing at that point, otherwise, it's not exactly deterministic.

The part of the constraint ensuring a draft payment cannot be added to a batch is the problem. The test tries to set one of the payments in the batch back to draft, and if this happens, the batch will end up in a state that is inconsistent with its own constraint. We fix the issue by simply removing it. This check is done again anyway when validating the batch payment. Doing things this way, we ensure the scenario of the test works in every case, whatever crazy recomputations happen in the ORM.

Forward-Port-Of: odoo/enterprise#72388
Forward-Port-Of: odoo/enterprise#71924

…ifferent trees Add a field at the end of the "left" subgroup and remove the "right" subgroup. ```xml <form> <group> <group> <field name="display_name" /> [ADD A FIELD] </group> [ REMOVE THIS GROUP <group> </group> ] </group> </form> ``` Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between. We were left with the inheriting vi

…ifferent trees

Add a field at the end of the "left" subgroup and remove the "right" subgroup.

```xml

<form>

  <group>

    <group>
      <field name="display_name" />
      [ADD A FIELD]
    </group>
[ REMOVE THIS GROUP
    <group>
    </group>
]
  </group>

</form>
```

Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between.
We were left with the inheriting view:
```xml

<xpath expr="[..]/group[2]" position="replace">
  <field name="added_field" />
</xpath>
```

After this commit, this flow works and the two operations are independent.

part of task-4207793

Forward-Port-Of: odoo/enterprise#72373
Forward-Port-Of: odoo/enterprise#71289

**How to reproduce:** - Go to 'Table' demo data - Select Number of people **Technical reason:** When the 'show timezone' is turned off, code is accessing the value of an undefined element, resulting in a traceback. Introduced by: https://github.com/odoo/enterprise/commit/9e38975d3f1e9dc87a3061c06ce9df7cf562949c **After this commit:** The traceback will be resolved. Task-4269449 Forward-Port-Of: odoo/enterprise#72292

**How to reproduce:**
- Go to 'Table' demo data
- Select Number of people

**Technical reason:**
When the 'show timezone' is turned off, code is accessing the value of an undefined element, resulting in a traceback.

Introduced by: https://github.com/odoo/enterprise/commit/9e38975d3f1e9dc87a3061c06ce9df7cf562949c

**After this commit:**
The traceback will be resolved.

Task-4269449

Forward-Port-Of: odoo/enterprise#72292

In the case of an AVS policy change, ac and acc rules do not verify that we are taking the previous amounts of the same policy, those rules are also from the previous version and can be simplified since all the computation is now done in the ACSALARY rule. Forward-Port-Of: odoo/enterprise#72532 Forward-Port-Of: odoo/enterprise#72481

In the case of an AVS policy change, ac and acc rules do not verify that we are taking the previous amounts of the same policy, those rules are also from the previous version and can be simplified since all the computation is now done in the ACSALARY rule.

Forward-Port-Of: odoo/enterprise#72532
Forward-Port-Of: odoo/enterprise#72481

To reproduce: - Open shop floor - Go to Assembly 1 and click on the gear icon on a work order card - Select Move to work center Current behavior: The 'Install App' button is displayed. Expected behavior: The 'Install App' button is only displayed when selecting the workcenters that should be shown in the view, not when moving a work order to another workcenter. Forward-Port-Of: odoo/enterprise#72261

To reproduce:
- Open shop floor
- Go to Assembly 1 and click on the gear icon on a work order card
- Select Move to work center

Current behavior:
The 'Install App' button is displayed.

Expected behavior:
The 'Install App' button is only displayed when selecting the workcenters that should be shown in the view, not when moving a work order to another workcenter.

Forward-Port-Of: odoo/enterprise#72261

For usability; the previous message caused a bit of confusion, and was too technical to actually be understandable. Forward-Port-Of: odoo/enterprise#71900

For usability; the previous message caused a bit of confusion, and was too technical to actually be understandable.

Forward-Port-Of: odoo/enterprise#71900

Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice. Steps to reproduce: 1. Generate 2 invoices 2. Use the option to generate a global invoice (for any period) 3. Go to any of the individual invoices and cancel the CFDI 4. After the cancellation, the option to reset the invoice to draft is not available. With this fix, the "reset to draft" option will be available after cancelling

Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice.

Steps to reproduce:
1. Generate 2 invoices
2. Use the option to generate a global invoice (for any period)
3. Go to any of the individual invoices and cancel the CFDI
4. After the cancellation, the option to reset the invoice to draft is not available.

With this fix, the "reset to draft" option will be available after cancelling a CFDI in a global invoice, allowing users to reset the invoice for further modifications.

Forward-Port-Of: odoo/enterprise#70697

- 17.0 ### Steps to reproduce: - Install sale_timesheet_enterprise. - Select Billing Rate Target and then Billing Rate Leaderboard in settings. - Click on 'Set employee billing time targets'. - Open Mitchell Admin form view and set the value of the Billing Time Target to 150 in the HR Setting tab. - Open 'my timesheet'. - Open the leaderboard, on the right-hand side. - Notice that 'x/150' is displayed for Mitchell admin. - Open Mitchell Admin employee form view. - Set the value of th

- 17.0

### Steps to reproduce:
- Install sale_timesheet_enterprise.
- Select Billing Rate Target and then Billing Rate Leaderboard in settings.
- Click on 'Set employee billing time targets'.
- Open Mitchell Admin form view and set the value of the Billing Time Target to 150 in the HR Setting tab.
- Open 'my timesheet'.
- Open the leaderboard, on the right-hand side.
- Notice that 'x/150' is displayed for Mitchell admin.
- Open Mitchell Admin employee form view.
- Set the value of the Billing Time Target to 100.
- Again open the leaderboard in the timesheet.

### Issue
'x/' is displayed without the new target value.

### Cause
Due to the wrong regular expression for the value.

### Solution
Correct the regular expression.


task-3970348

Forward-Port-Of: odoo/enterprise#66825

To reproduce: - Create MO for 10 units of drawer - Open barcode app - Go to operations > manufacturing Current behavior: Strange layout of the MO card. Expected behavior: Proper layout with qty under the name of the final product. Forward-Port-Of: odoo/enterprise#72267

To reproduce:
- Create MO for 10 units of drawer
- Open barcode app
- Go to operations > manufacturing

Current behavior:
Strange layout of the MO card.

Expected behavior:
Proper layout with qty under the name of the final product.

Forward-Port-Of: odoo/enterprise#72267

Steps to reproduce: - Expenses > New > Mitchell Admin; Paid by employee (to reimburse) - Create report > Submit to Manager > Approve > Report in Next Payslip - Payroll app > Payslips > To Pay > New > Mitchell Admin - Set structure to 'Worker Pay' (Or any other with no expense rule) - Compute sheet > Create draft entry > Journal entry (Draft) button - Post > Traceback The traceback is caused by 'KeyError expense_report_name', this happens because e65511ac69131b048da5d11afd00f3cfe91db474

Steps to reproduce:
- Expenses > New > Mitchell Admin; Paid by employee (to reimburse)
- Create report > Submit to Manager > Approve > Report in Next Payslip
- Payroll app > Payslips > To Pay > New > Mitchell Admin
- Set structure to 'Worker Pay' (Or any other with no expense rule)
- Compute sheet > Create draft entry > Journal entry (Draft) button
- Post > Traceback

The traceback is caused by 'KeyError expense_report_name', this happens because e65511ac69131b048da5d11afd00f3cfe91db474 changed the move creation process to ease reconciliation of expense compensated on the employee's payslip. We would have previously had access to expense_report_name=move.expense_sheet_id.name, which we do not in saas-17.4 and onwards. This causes the traceback when trying to display the error message which still depends on this inaccessible variable.

We instead expect expenses not to be linked when creating payslips with a structure containing no expense rule, and a proper error if the user attempts to add an expense by hand on such a payslip.

opw-4222515

Forward-Port-Of: odoo/enterprise#71541

Before this commit: The information of message sender using email alias was not shown, instead only mail subject with name Odoobot was displayed in chatter. After this commit: The information of sender such as email address, name, subject of email and email body is not displayed in chatter along with the attachment. Task - 4008634 Forward-Port-Of: odoo/enterprise#71717 Forward-Port-Of: odoo/enterprise#66503

Before this commit:
The information of message sender using email alias was not shown, instead only mail subject with name Odoobot was displayed in chatter.

After this commit:
The information of sender such as email address, name, subject of email and email body is not displayed in chatter along with the attachment.

Task - 4008634

Forward-Port-Of: odoo/enterprise#71717
Forward-Port-Of: odoo/enterprise#66503

Exactly the same case as described in: https://github.com/odoo/odoo/pull/183527 (but happen opening the customer display instead of self-order) opw-4233060 Forward-Port-Of: odoo/enterprise#72332 Forward-Port-Of: odoo/enterprise#71860

Exactly the same case as described in:
https://github.com/odoo/odoo/pull/183527
(but happen opening the customer display instead of self-order)

opw-4233060

Forward-Port-Of: odoo/enterprise#72332
Forward-Port-Of: odoo/enterprise#71860

Before this commit, tests were skipped without using self.skipTest which is not a good practice. Moreover, assertAlmostEqual was not properly used in an older version. ssertAlmostEqual should be used to compare amounts but it can be called with place, delta and message. The named argument should be used correctly. See https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual The msg parameter should be explicitely named. Runbots: https://runbot.odoo.com/web

Before this commit, tests were skipped without using self.skipTest which is not a good practice.

Moreover, assertAlmostEqual was not properly used in an older version. ssertAlmostEqual should be used to compare amounts but it can be called with place, delta and message. The named argument should be used correctly.

See https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual

The msg parameter should be explicitely named.

Runbots:
https://runbot.odoo.com/web/#id=102838&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102837&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102836&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102835&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102834&view_type=form&model=runbot.build.error&menu_id=405&cids=1

Forward-Port-Of: odoo/enterprise#72131
Forward-Port-Of: odoo/enterprise#71974

Right now, if all consolidated subscriptions are not invoicable or are free, the recurring invoice cron job fails due to a singleton error We filter the subscriptions and handle them separately Forward-Port-Of: odoo/enterprise#72231 Forward-Port-Of: odoo/enterprise#72086

Right now, if all consolidated subscriptions are not invoicable or are free, the recurring invoice cron job fails due to a singleton error

We filter the subscriptions and handle them separately

Forward-Port-Of: odoo/enterprise#72231
Forward-Port-Of: odoo/enterprise#72086

Steps to reproduce: - Subscriptions app > New > Add 1 line with any recurring product twice - Give both lines different discounts - Confirm > Create Invoice > Confirm > Back to original subscription - Upsell > Lines have the same discount The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Cu

Steps to reproduce:
- Subscriptions app > New > Add 1 line with any recurring product twice
- Give both lines different discounts
- Confirm > Create Invoice > Confirm > Back to original subscription
- Upsell > Lines have the same discount

The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Currently both lines will take the first parent that matches the original order line without taking the discount into consideration.

i.e a monthly recuring order upsold halfway through the month will already have a 50% discount (Because we only invoice half a period) which should be cumulative with the original line's discount.

opw-4081350

Forward-Port-Of: odoo/enterprise#72406
Forward-Port-Of: odoo/enterprise#72192

This commit changes the way we display placeholder options for the CharField when being selected by studio. Previously, it was confusing to edit the dynamic_placeholder option, which needs another option to work properly, and which don't make much sense in most cases. Instead, we choose to support only the recently added placeholder_field option, and to name it Dynamic Placeholder in the sidebar. task-3901821 Forward-Port-Of: odoo/enterprise#72448

This commit changes the way we display placeholder options for the CharField when being selected by studio.

Previously, it was confusing to edit the dynamic_placeholder option, which needs another option to work properly, and which don't make much sense in most cases. Instead, we choose to support only the recently added placeholder_field option, and to name it Dynamic Placeholder in the sidebar.

task-3901821

Forward-Port-Of: odoo/enterprise#72448

This PR will remove the "More Options" button from the calendar event page, because there is a generic web option that performs the same task. **Technical** As we cannot remove the views in the stable version so this PR will just remove the more option button. The rest of the footer and the inherited calendar event view of pos_restaurant_appointment will be removed from the master Task-4246277 Forward-Port-Of: odoo/enterprise#72176

This PR will remove the "More Options" button from the calendar event page, because there is a generic web option that performs the same task.

**Technical**
As we cannot remove the views in the stable version so this PR will just remove the more option button. The rest of the footer and the inherited calendar event view of pos_restaurant_appointment will be removed from the master

Task-4246277

Forward-Port-Of: odoo/enterprise#72176