Best practice forum (Archived)

Reportbuilder API changes in 2.5.2

 
Simon Coggins
Reportbuilder API changes in 2.5.2
by Simon Coggins - Monday, 25 November 2013, 3:37 PM
Group Totara

Below is a list of minor API changes affecting reportbuilder that will be made in the 2.5.2 release (due out later today).

Normally we try to avoid making API changes in point releases (see here for more information why). However these changes are needed to fix some bugs, allow users to generate reports for some of the new 2.5 embedded reports and tidy up some existing code. We had hoped to include them in the 2.5 release but we ran out of time so we've decided to make an exception and include them in 2.5.2.

Note that we've tried to make the changes as backward compatible as possible - unless you've heavily customised or build on top of report builder you should be unaffected. In particular custom report sources and embedded reports should still work without changes.

 

T-11651 reportbuilder: Added schedule id to saved scheduled report filenames to make them unique

  • Renamed send_scheduled_report to reportbuilder_send_scheduled_report. This was done to be consistent with report builder function naming.
  • Renamed create_attachment to reportbuilder_create_attachment and it's parameters were changed (pass in the whole schedule object rather than parts of it). This was done to be consistent with report builder function naming and to provide access to additional schedule properties.
  • Renamed get_directory to reportbuilder_get_export_filename and the scheduleid required parameter was added. This was done to make name of the function match its purpose and to make the generated path/filename unique.

 

T-10928 reportbuilder: Store report params in session

The purpose of this patch was to store report parameters in session variables. This means that they do not have to be passed from one place to another as POST or GET parameters.

  • Added method get_param_value to reportbuilder. This allows an embedded page or report source (say in post_config) to access report parameters (without needing to know how the parameter is specified, stored or retrieved).
  • Added display_redirect_link to reportbuilder. This method can be called by an embedded report, and is always called by a user report, to show the link specified by set_redirect. If a redirect was not specified then nothing is shown.
  • Added needsredirect property and need_redirect method to rb_base_source to allow a report source to signal that a redirect needs to occur, rather than displaying the report data to the user.
  • Added set_data and unset_data methods to rb_filter_type so that filters control their own setting and clearing of data.
  • Scheduling of "All data" is not possible when a report specifies a redirect url. Only saved searches can be scheduled in this case.
  • The Save button for report filters will always be displayed when a report has required parameters. This allows users to create a saved search containing all data which can then be scheduled.


T-10928 reportbuilder: Add post_config_restrictions and fix course visibility in report

  • Added _post_config_restrictions property, get_post_config_restrictions method and set_post_config_restrictions method to reportbuilder. These allow a report source to specify a where clause which can further restrict the report data.
  • Added get_field to reportbuilder. Use this function to get the sql field name of existing columns when constructing sql where clauses to be passed to set_post_config_restrictions.
  • The course report source was changed to only return courses which are visible to the user that the report is for.


T-10928 reportbuilder: Allow post_config to trigger actions which are performed later

The purpose of this patch was to allow a report source to specify an additional action that should be performed only when the report data would be displayed to a user. To do this, the pre_display_actions, set_redirect, and (in a patch above) needs_redirect methods were added. Since pre_display_actions is not called during report setup, report caching, testing, etc, it is safe to signal a pre-display action under any condition, since it will not be activated when it could cause interference.

  • Added pre_display_actions method to report source which by default will cause a redirect when indicated, or can be overridden.
  • Added set_redirect method used to specify the destination and (optionally) message when the pre_display_actions method causes a redirect.
  • Added method handle_pre_display_actions in reportbuilder. An embedded report page can optionally call this to activate a pre-display action that may have been specified earlier. This is always called in user reports. [For example, the Appraisal Detail and Goal Summary embedded reports handle missing parameters themselves, but missing parameters in user reports based on their report sources will trigger redirect via handle_pre_display_actions.]
  • Added scheduleable property to report source which allows it to specify that reports created with this source cannot be scheduled.


T-10928 reportbuilder: Refactor clearfilters param so that it can be reused in all reports

  • Passing "clearfilters=1" to an embedded or user report will cause all user filters to be cleared.