Odoo Changelog — 2023-12-12

Tuesday, December 12, 2023

5 changes · master

New Features(1)

New functionality added to Odoo

[IMP] account_reports: introduce horizontal split feature

Enterprisemasteraccount_reportsl10n_be_reportsl10n_in_reportsMEDIUM

Balance sheets can now be shown in two side-by-side sections, such as assets on one side and liabilities plus equity on the other. This makes reports more familiar and easier to read for accountants in markets such as India and Belgium, while still allowing users to turn the split view off when needed.

Original PR description

In some countries (like India), accountants are really used to having the BS displayed in two halves, next to each other (assets / liabilites + equity), and we receive a lot of feedbacks from them…

In some countries (like India), accountants are really used to having the BS displayed in two halves, next to each other (assets / liabilites + equity), and we receive a lot of feedbacks from them about changing the layout of the report to have something more intuitive for them.

This PR adds a generic mechanism to allow splitting the lines of a report between two "pages" displayed next to each other. This behavior can be enabled by specifying on the report lines whether they need to go left or right when splitting the report. If any of the account.report.lines of the report defines a value in that field, the report is going to be displayed split by default (lines with no value in that field will be put on the left side by default ; so we always display them all). An item in the extra options filter allows disabling that mode.

For reports using dynamic lines instead of expressions, horizontal split can also be used, by forcing the 'horizontal_split' key into the options through a _custom_options_initializer.

Task 3618056

#balance-sheet#reporting#localization#accounting

Improvements(4)

Enhancements to existing features

[IMP] use recurrence mixin

PR #20384

Enterprisemasterappointmentappointment_crmhr_appraisalindustry_fsmindustry_fsm_reportindustry_fsm_saleplanningproject_forecastproject_timesheet_forecastsale_planningsale_project_forecastMEDIUM

This update standardizes how recurring appointments, appraisals, field service tasks, and planning shifts are handled across Odoo. It keeps existing behavior while using a shared recurrence approach, making future maintenance more reliable and reducing inconsistencies between apps.

Original PR description

TODO

#recurrence#scheduling#appointments#planning

[IMP] sale_temporal: display recurring price in pricelist menu

PR #29363

Enterprisemastersale_subscriptionsale_temporalMEDIUM

Recurring prices can now be viewed and managed directly from the pricelist menu instead of only from individual product forms. The update also improves pricing reliability by recalculating values when pricelist currency changes and preventing errors when updating pricing for multiple products.

Original PR description

Before this commit, the recurring prices were only available from the product
template form view.

taskid: 2886054

#pricelists#recurring pricing#subscriptions

[IMP] helpdesk: improve sla status analysis report in helpdesk

PR #47454

Enterprisemasterhelpdeskhelpdesk_sale_timesheethelpdesk_timesheetMEDIUM

Helpdesk SLA reports now show clearer labels and additional timing measures that match ticket analysis reports. Business users get more useful SLA insights, including average remaining service order hours and cleaner displays that hide zero values where they add noise.

Original PR description

This PR makes the following improvements:
- In pivot view of SLA status analysis report, 'remaining hours on SO' measure will be appear as hh:mm.
- The total 'remaining hours on SO' represents the average number
- hide the value if it is equal to 0 for the following measures: rating, hours to assign, hours to close.
- add same measure as ticket analysis in sla status analysis report.
	- Average hours to Respond
	- Hours to first respond
	- Hours Open
- change 'Close Date' into 'Closing Date' and Create Date into 'Ticket Creation Date' for the both reports in helpdesk.

task-3475472

#helpdesk#sla#reporting#analytics

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

PR #51409

EnterprisemastermaildocumentswhatsappMEDIUM

The Discuss app and messaging menu now load more efficiently when there are many failed messages, pinned conversations, or large group chats. This improves responsiveness for users while keeping compatibility with existing customizations.

Original PR description

- 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…

- 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.

These commits fix 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.

Some fields had to be turned into computed fields to result to performance gains from these improvements. Since computed fields do not trigger `Record.insert()` and `Record.update()` for performance reasons, some fields that were set there had to be turned into computed and sorted fields too. Python formatter had to return data that follow more closely the change of JS models, in order to remove reliance on passing on `Record.insert()` and `Record.update()` which are even less guaranteed by these changes.

Legacy/deprecated fields and formatter data are preserved in order to not break customisations.

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

#performance#discuss#messaging

In some countries (like India), accountants are really used to having the BS displayed in two halves, next to each other (assets / liabilites + equity), and we receive a lot of feedbacks from them about changing the layout of the report to have something more intuitive for them. This PR adds a generic mechanism to allow splitting the lines of a report between two "pages" displayed next to each other. This behavior can be enabled by specifying on the report lines whether they need to go left or right when splitting the report. If any of the account.report.lines of the report defines a value in that field, the report is going to be displayed split by default (lines with no value in that field will be put on the left side by default ; so we always display them all). An item in the extra options filter allows disabling that mode. For reports using dynamic lines instead of expressions, horizontal split can also be used, by forcing the 'horizontal_split' key into the options through a _custom_options_initializer. Task 3618056

This PR makes the following improvements: - In pivot view of SLA status analysis report, 'remaining hours on SO' measure will be appear as hh:mm. - The total 'remaining hours on SO' represents the average number - hide the value if it is equal to 0 for the following measures: rating, hours to assign, hours to close. - add same measure as ticket analysis in sla status analysis report. - Average hours to Respond - Hours to first respond - Hours Open - change 'Close Date' into 'Closing Date' and Create Date into 'Ticket Creation Date' for the both reports in helpdesk. task-3475472

- 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. These commits fix 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. Some fields had to be turned into computed fields to result to performance gains from these improvements. Since computed fields do not trigger `Record.insert()` and `Record.update()` for performance reasons, some fields that were set there had to be turned into computed and sorted fields too. Python formatter had to return data that follow more closely the change of JS models, in order to remove reliance on passing on `Record.insert()` and `Record.update()` which are even less guaranteed by these changes. Legacy/deprecated fields and formatter data are preserved in order to not break customisations. https://github.com/odoo/odoo/pull/143378