Is it possible to get a list of parameters for a given report from either the perspective or gateway scope? Or does this have to be known ahead of time?
I was brainstorming ideas for a user interface to allow users to self-manage report schedules specific to them. For example, User A wants to have Report A run at 8AM daily, but user B wants it to run at 7AM Weekly. I don't want to have to open the project and configure schedules every time someone wants to change a schedule or get removed, but I also don't want to manage a bunch of distribution groups or AD roles.
Anyone suggestions? Maybe this isn't worth the headache of configuring and upkeep.
Huh. A quick skim of the javadocs yields no easy angle of attack. Perhaps @KathyApplebaum might weigh in....
We didn't foresee this kind of a use case, but it makes total sense. I'd suggest submitting it to the ideas forum, which will get it in front of the product managers. 
-
Build a table in the database in conjunction with a form in Perspective for users to schedule their reports. Use some sort of limited cron expression that can be easily parsed.
-
Create a scheduled task every hour (or every 15 minutes) that queries the database for matching cron expressions to determine which reports to run.
This feels a little bit like a hack, but I think it might work (at least for a flexible scheduling solution).
Sounds like a fun project.
The scheduling isn't the problem. The problem is presenting the report parameters to the user.
This is the path I was leaning towards, but I was hoping to have it more dynamic and not have to manage the parameter names/types for every report. Granted, this would still be easier than managing schedules per user.
Thanks, I will add it to the ideas.
Add the ideas portal link to this thread when you do.
Wouldn’t the list of needed parameters be known at the time of report development?
Couldn’t a form be developed at the same time with all those same parameter fields?
Would it not be possible to derive all the possible valid parameter values by a query of the underlying report data? Could creating valid parameter values be done by creating views in the database itself?
Clearly I’m not understanding the issue. Seems to me there should be a workaround for most use cases.
The report itself knows the parameters it needs. The designer knows how to get that information to update the props shown on the report viewer. There is no obvious way for a script or custom UI to do similar.
Requiring the developer to duplicate that info in a secondary place is what the OP is trying to avoid. (I would too--it's a nightmare. )