Make option to allow/not allow running reports off Shared Templates

[Jennifer Bruch]

PaILS is on 3.3.6

Many library consortiums try to have some level of official Shared Reports for use by the libraries in its group.

However, the ability to run a report off a shared template has resulted in many convoluted solutions to updating/changing/removing outdated templates.

It would be nice if there were some options to simplify this problem.

Such as:
Settings to Allow/Not Allow running reports off a Shared Template

Ability to Delete a Template even if another user has a report running off it

[Beth Willis (willis-a)]

I agree that it can be difficult to manage and clean-up shared report templates. But, I think the idea behind the shared templates is that anyone with access could use them to run reports. I'm not sure that there is value in sharing if this would not be the case. I also would not advocate allowing templates to be deleted if other users had run reports associated with those templates.

While shared templates can be hard to manage they do, in theory, ensure that all users are getting the same report output and it is easier to update one template than multiple copies of the same template.

[Galen Charlton (gmc)]

If one of the concerns is managing outdated templates, would it be sufficient (or at least a start) to add a deprecation flag to templates? That would be a way to signify that a template shouldn't show up in a folder by default, while still preserving access to the template itself in case there are any reports that have used it.

[Jennifer Bruch (jbruchpails)]

That could be useful if it also showed somehow on the report output. Users who run a recurring report on it and never look at the template again would not see a flag on the template itself.

This means they continue to get an inaccurate output and the template creator cannot delete it, ever! It can be moved to an unshared folder only if there is not a template with the same name, which means people can end up with multiple "Cannot Delete Bad Templates" folders.

[Kyle Constant (trailsconstant)]

I agree that the template creator should be given some options. Introducing controls doesn't automatically restrict access to the template. Cloning is still possible and template creators who want to allow running from a shared template can do so.

[Terran McCanna (tmccanna)]

I like the idea of being able to mark a template as deprecated, as long as it 1) stopped recurring reports based on that template, and 2) prevented new reports from being created from that template.

It would also be nice to have the report output screen indicate that the report an output was based upon has been deprecated.

What if... upon deprecation, the name of the deprecated template had a time stamp added to the title? (eg, "Count of Items by Shelving Location (Deprecated 09-22-2020 5:56PM)"
) That would give it a unique name as well as provide information that would be helpful when getting the inevitable questions from library staff.

[Geoff Sams (gsams)]

If this is reasonable, I'd say Terran's approach is the one that'd work well across different styles of reports sharing. It'd certainly solve some issues for everyone maintaining our reports.

[Carissa Malmgren (cmalm)]

I agree with Terran's suggestion for how to flag deprecated templates.

Would it be possible to add/tweak the email notification for recurring reports to indicate that the report didn't run as scheduled because the template has been deprecated? (e.g. "Recurring report [TEMPLATE NAME] not run at [SCHEDULED TIME] because it has been flagged as deprecated. Please check source folder for updated template.")