Wishlist: Reporter Copy Statistics View

Bug #1672346 reported by Chris Sharp on 2017-03-13
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

While attempting to create reports for a third-party collection development service, I learned that there is currently not a way to retreive various statistics in a single report.

Branch implementing a copy statistics reports view on the way.

Changed in evergreen:
importance: Undecided → Wishlist
assignee: nobody → Chris Sharp (chrissharp123)
tags: added: reports
Changed in evergreen:
milestone: none → 2.next
Mike Rylander (mrylander) wrote :

Chris, are you still working on this?

Chris Sharp (chrissharp123) wrote :

Sorry for the delay. Branch here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1672346_reporter_copy_statistics_view

I added it to the example.reporter-extension.sql file since it depends on a table in extend_reporter, which is not installed by default. I'm open to alternative suggestions to how to deal with that issue.

Changed in evergreen:
assignee: Chris Sharp (chrissharp123) → nobody
tags: added: pullrequest
Dan Wells (dbw2) on 2018-02-13
Changed in evergreen:
milestone: 3.next → 3.1-beta
Dan Wells (dbw2) wrote :

Gave this a quick look, and just noting the provided branch still needs an upgrade script.

Chris Sharp (chrissharp123) wrote :

Dan,

I had intentionally not created an upgrade script because I understood that not all Evergreen implementations apply this script to their systems. Should we assume otherwise? PINES uses the reporter sources available in the file and we just re-run the example.reporter-extension.sql file when we need to update things.

If the consensus is that we should assume these sources to be "core" Evergreen, I'm happy to include an upgrade script.

See bug 1050384 for related discussion.

Chris

Dan Wells (dbw2) wrote :

Chris, thanks for the context, especially the other bug. Now that I understand that that file is all views, I can see the logic in not creating an upgrade script, but we do need some other mechanism then to keep folks at least aware of changes. This would have similarities to the latent plans to improve in-DB function changes by reapplying those en masse at upgrade time (or whenever needed).

I agree with the consensus on the other bug that it doesn't make sense to half-support (and half-enable via the IDL) these views. We should put some heads together (maybe at the Hackfest?), and if some reports can be fully "de-PINESed", then let's enable those outright, but if others cannot, let's provide those fully separate and disabled OOTB. That's my initial take, anyway.

Finally, being solely DB views, and being already in an odd state, I think straightening this out could still come pre-RC if there is energy behind it.

Changed in evergreen:
milestone: 3.1-beta → 3.1-rc
Changed in evergreen:
milestone: 3.1-rc → 3.next
Jane Sandberg (sandbej) on 2018-06-20
tags: added: needsreleasenote
Dan Wells (dbw2) on 2019-02-06
Changed in evergreen:
milestone: 3.next → 3.3-beta1
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.next
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers