Date
...
Element | Value for Example Report | Description |
---|---|---|
Requirements ID | ID401 | |
JIRA Ticket | REP-103 | |
Name of Report |
| The report itself is focused on how the report is going to be used, not about how to get the data. This will also be the name of the JIRA issue. Report Naming Construct
Note: we should create a markdown file for each report that would live in a reports folder on GitHub; it should include original purpose of the report, description of the different queries, links to queries Can also link to report markdown files from the main ldp-analytics markdown file Question: how to keep track of work on things like this in JIRA |
Name(s) of query(ies) | ex.: Count Loans for Locations | The query is how to get the data. Possible naming convention for short names: verb, source data, function or maybe noun, verb, function example: Loans - Count by Location with Material Type Will likely create JIRA issues for all queries, maybe in LDP project; then can link from LDP query issue to report(s) that contain(?) that query Idea from Angela:
|
Short name(s) of query(ies) | ex.: count_loans_locations |
Idea from Angela:
|
Umbrella category for report | Circulation | Group reports by the 5 most used apps of FOLIO that reports will be generated for:
just use umbrella category to organize reports, not to name them (could be the directory structure in LDP GitHub) use tagging (e.g., in GitHub?) to help organize reports, maybe to add original functional area to query |
Additional information that would be useful when browsing reports in, e.g., GitHub:
|
...
Resource Access has additional report requirements
App Interaction: ERM + eUsage + Reporting
The eUsage app would like to include a statistics summary that would require joining data between ERM and eUsage modules. Rather than having the app know how to join its data to another app, should they try to leverage the joins that the LDP is already doing? How might that work?
...