Thursday, July 13, 2023
2 changes
New functionality added to Odoo
Knowledge users can embed a calendar inside an article to show and manage that article’s items by date. The setup dialog lets users choose or create date and color properties, making article item planning easier, while the older Appointment calendar command is removed to avoid confusion.
Original PR description
Purpose -------- Add a new editor command "/item calendar", that allows users to embed a calendar view showing the items of the current article, using the properties of these items to display them in…
Purpose -------- Add a new editor command "/item calendar", that allows users to embed a calendar view showing the items of the current article, using the properties of these items to display them in the calendar. Usual calendar features such as creation, edition of "events" (article items in this case) are working and sets/edits the corresponding item properties. Since the properties are stored in the behaviorProps, these are not available when opening an items list or kanban. Therefore, the calendar view switch button is hidden in this case. The properties are thus also not available when reloading the page. In that case, we show an empty calendar with a warning. When inserting the item calendar, a dialog allows the user to select the properties to use in the item calendar view: - name (string - name of the view) - start date (date/datetime property - mandatory) - end date (date/datetime property - same type as start date property) - color (boolean/selection/many2one property - used to show the items in different colors, randomly) - default scale (calendar scales) The creation of new date or datetime properties is possible from this dialog. If no date/datetime property exists, two default start and stop dates will be created. This dialog can also be used to edit an existing embedded view, by clicking on the edit button of the embedded view manager. The "/calendar" command from Appointment has been removed as it has a similar name and is less convenient than this new command anyways. Task-3239985
Enhancements to existing features
Accounting reports can now be organized into separate sections, making large or legally bundled reports easier to navigate and export. Optional appendices can stay hidden until needed, reducing clutter while still allowing businesses to include required documents when relevant.
Original PR description
** Terminology ** A section is a 'page' of a report. Typically, when opening a report with multiple sections, we display the lines of only one section at a time, and a page switcher appears on top of…
** Terminology **
A section is a 'page' of a report. Typically, when opening a report with multiple sections, we display the lines of only one section at a time, and a page switcher appears on top of the report.
For clarity, we here refer to reports made of sections as 'composite reports'.
** Implementation notes **
Sections are modelled in the same way as group of taxes, by using composite objects. This commit hence introduces a m2m relationship from account.report to account.report. It is therefore possible for a report to be a section of multiple composite reports. Note however that it is not allowed to use composite reports as sections, for the sake of simplicity and comfort of use.
A report cannot both define lines (nor static, not dynamic) and have sections; it wouldn't make sense (which page should these lines be displayed on, then ?).
** Functional use **
This feature allows supporting two new use cases:
1) Report appendices
Some reports (especially tax reports) define additional parts that can or must be provided with them depending on business conditions. We don't want to always display those in Odoo, as most people will not need then, or only one of them. The solution for that is achieved by the use of sections : each of these documents is a section of its own, and we make use of a new 'active' field on account.report to hide the optional sections by default. When opening a composite report with inactive sections, a '+' button is shown in the section switcher to allow displaying and enabling them. This way, users can easily configure what they want without being invaded by tons of unneeded options.
2) Grouping existing reports
It is sometimes useful to group multiple standard reports into a single document. It is sometimes even legally required to submit them together (like the 'liasse fiscale' in France, grouping BS and P&L). This can now easily be done by defining a new composite report using each of those reports as a section. Any non-composite report can be a section of any number of composite reports, allowing full flexibility on that side.
** Filters and export buttons management **
When displaying a composite report:
- the filters displayed correspond to the one of the active section
- the export buttons displayed are the ones from the composite report
- the fields defining option filters on the composite report are never used (and not displayed in its form view)
** Preloading and Caching **
This commit comes with big changes on the Javascript side and the way it calls the server. When opening a composite report, the sections are loaded asynchronously one after the other, without blocking the user interface. A cache is maintained with all the loaded data from the sections and previoulsy opened variants. When the user changes a filter, the cache is invalidated accordingly for all reports supporting it. This allows a way more seemless navigation, thanks to the reduction of the perceived loading time.
** Default file export behavior for composite reports **
- pdf: Each section one after the other ; starting on a new page.
- xlsx: Each section is a distinct sheet within the resulting file.
** New warning API **
The preloading & caching mechanism requires the get_options() and get_report_informations() functions to be decoupled and called separately from js. Because of that, it is not possible anymore to modify the options dictionary while generating the content of the report to add new warning keys to be used in custom templates to display some kind of banner on the report, like we did in several places. To solve that, we introduce a new way to define warnings, not requiring any custom template to be used on the report (instead, the warning template is directly called from the standard code). This is essentially achieved by adding a parameter to _get_lines and the engine functions, in the form of a dictionary that can be modified during the report's computation to enable warnings dynamically. This parameter is optional, allowing to skip warning generation in case we don't want it.
Task 3098971