Stop auto run of reports

Progress® Telerik® Reporting Feedback Portal

Create an account Log In

Back to Feed

Request a Feature Report a Bug

Unplanned

Last Updated: 10 May 2024 11:59 by ADMIN

Jai

Created on: 07 Jul 2016 11:41

Type: Feature Request

Stop auto run of reports

If there are parameters which are not mandatory, the reports automatically when loaded. In actual scenarios, there may be a lot of data being processed as the parameters may be empty. Developer should have an option on report level, say, AutoRun as true or false. The developer could decide if report needs to auto run.

Thanks,
Jai

5 comments

ADMIN

Dimitar

Posted on: 10 May 2024 11:59

Hello Steven,

Thank you for the feedback!

We will have it in mind when discussing the implementation of the feature.

Please do not hesitate to share if you have anything else to add.

Regards,
Dimitar
Progress Telerik

Stay tuned by visiting our roadmap and feedback portal pages, enjoy a smooth take-off with our Getting Started resources, or visit the free self-paced technical training at https://learn.telerik.com/.

Steve

Posted on: 03 May 2024 16:30

I also need to implement this as I have been asked to prevent auto run of reports in our report viewer integration.

For what its worth, I agree with numerous points mentioned here and in the forum. It makes sense to be able to set the viewer to always wait for the user to set any required parameters before any processing occurs, as in the vast majority of cases, the user will need this to produce the ouput required at the time. I dont see an issue with a blank report display area next to the rendered parameter editor area - a message can be displayed (maybe even configurable) like in the manner the current invalid/required parameter value one is.

A couple points off the top of my head (hopefully not just repeating things from the forum):

leaving unset/null values as a block to the auto run is only somewhat convenient when there will always be a parameter - on all reports on the system - that the user will want to set and is simple, e.g. a single-value parameter set from a static available values list
having default values set allows a report to have parameters at good starting point, without the values needing to all be useful at runtime
- the user will not have to always set all parameter values - just dates, filters etc. required at the time
- both non-null and null defaults can be set without concern to preventing auto run

ADMIN

Milen | Product Manager @DX

Posted on: 15 Jan 2024 10:14

Hello Matthew,

Thank you for providing more context on this item and confirming the business case. It makes sense so I am bringing up its priority on our internal project management system. Will try to implement it in the first half of 2024. Stay tuned for updates.

Regards,
Milen
Progress Telerik

Matthew

Posted on: 08 Jan 2024 14:05

I have a report with a number of parameters. It is unlikely that the user would want to run the report with no filters applied, since it generates a large report and takes a while to load. It would be nice to be able to stop the report from running immediately, so that the user can enter a filter before it runs a large report that they don't want.

Surely this isn't such a strange request that you cannot understand why someone would want this? We have worked around it by checking in the report query that none of the parameters have been set and returning no data, but it's not the cleanest solution and it requires us to code it into every report rather than it being an out-of-the-box feature.

ADMIN

Milen | Product Manager @DX

Posted on: 15 May 2017 06:37

The workflow is as follows:
The report viewer loads the chosen report. If not all report parameters have valid values, it waits for end user input, otherwise, it triggers report rendering. The purpose of this algorithm is to show the ready report to the end user as soon as possible.
If the default values of a parameter (empty) retrieve too much data, isn't it better to make the parameter mandatory in order to require input?
If still, you need the end user to be able to retrieve all the data, a property on the report viewer level controlling the described algorithm seems more appropriate to me.
Please elaborate.