Ability to run scheduled reports on demand

[brendanheywood]

We had a scheduled report, which I needed to to tweak - but you can't see the result of the report as its scheduled to test it. I swapped it back to a normal report so I could test it, but this inadvertently removed the entire stored history of that report without warning.

So I think there are few UX improvements here:

1. when editing a report which is scheduled after you save it then it takes you back to the report index which completely baffled me and I had to dig around code to find out it was because it was scheduled. It would be much better if it took you to back to the view page the same as normal reports.

2. The view page for scheduled reports should have a 'Run now' button

3. When editing the report which is scheduled, it should have a 'Save' and a 'Save and run now' button

4. The time taken to run was not really a factor here, but if needed it could be run as an ad hoc task in the background

5. When I swapped it back to scheduled the history returned (phew!) but it would be better if it never went away in the first place. It would be nicer if any report could optionally have history, like run an an hoc report and then tick another box saying 'Save the results an archive'. Thats probably worth its own issue so I'll cross link it Allow any type of report to store archives of reports and always show the history regardless of type #94

[timhunt]

OK, so there is a usability issue if you change from schedule to on demand. (Work-around: don't do that. If you want both, create two queries.)

However, sometimes we schedule really slow queries for the middle of the night, becuase they put a lot of load on the DB and we don't want them run at busy times.

So, I am not conviced that what you propose is a good solution to the usability issue.

[brendanheywood]

Sure some queries are heavy and so you run them at night, but the vast majority of our scheduled queries are scheduled because we want them scheduled, and not because they are heavy, that is tangential. If we allowed a query to be run on demand, and it is heavy, then that's analogous to the concept of the task api allowing tasks to be run manually from the UI. Just because some tasks happen to be heavy and would timeout isn't a reason all the other ones should suffer from the lack of a useful feature.

If it is a heavy task then nobody is forcing you to run it on demand. And if the last run time > 10 seconds then you can always warn them and and if confirmed queue up an adhoc task instead so it won't timeout.