FOLIO Reporting developers and Reporting SIG members are encouraged to use this new page to share test data cases they have entered into FOLIO reference environments to keep us all aware of what data to expect when we test our queries.
New Report Clusters are added on a regular basis, so it is important to make sure your institution is reviewing these clusters and ranking them to establish report development priorities. If you rank reports for your institution, please follow the instructions below. If someone else ranks, please pass this information along to that person so your institution's vote can be included.
Action =>> Please review Reporting SIG-All Report Clusters (64 issues) in JIRA and RANK each report cluster for your institution (R1-R5)
For reporting, institutions only need to rank the UXPROD Report Cluster JIRA issues. All reporting requirements, which are captured in REP-XXX issues, roll up to the UXPROD Report Clusters. Report clusters cover one or more report (REP-XXX issue) requirements.
Updates and Query Demonstrations from Various Reporting Related Groups and Efforts
Community & Coordination, Reporting Subgroup Leads
Project updates
Reporting development is using small subgroups to address priorities and complete work on report queries. Each week, these groups will share reports/queries with the Reporting SIG. Reporting development team leads are encouraged to enter a summary of their work group activities below.
Reporting SIG Documentation Subgroup
Had a good discussion about how to push through on our first draft of documentation
Will finish first draft by May 14, and then sometime during the week of May 17 will be sharing the documentation to the SIG for review
Context
Over the next few months, Reporting SIG Documentation Subgroup will be helping to build end-user documentation for https://docs.folio.org/docs/ (much will be linking to existing documentation over on GitHub)
Last Tuesday, we worked on the recommendations for LDP Marc. This discussion brought up an interesting find in relation to how FOLIO Quickmarc and FOLIO Data Import update the json file for the marc srs record on update. For Quickmarc, there is a matching or masking identifier called matched_id that is related to the real UUID for the different versions of the marc srs; a new UUID is assigned when the marc srs record is edited and saved. This is not the case for Data Import. The group has forwarded questions to Ann-Marie Breaux who is the PO for Data Import to explain the administrative metadata in the json file for the marc srs and how the FOLIO apps Quickmarc and Data Import act on this file at the time of the creation and update (or edit) of marc srs records. Today, Ann-Marie Breaux, PO For Data Import, posted notes on the administrative metadata in the json file for MARC SRS records, Data Import FAQ.
If you have general comments and questions about LDP Marc, please add them to this spreadsheet. The original spreadsheet of use cases submitted to Nassib can be found in this document.
For general report development, the working group uses thisspreadsheetto track JIRA issues, priority, and reports needed. However, because many institutions are going live, we would like to focus on completing the following:
external statistics reports (e.g., ACRL) typically require running queries from different functional reporting areas
these reports will be captured in JIRA under one UXPROD-XXXX report cluster issue, then the descriptions will point to each of the queries required to run them on the folio-analytics repository
institutions will need to rank each of these 8 new UXPROD-XXXX report cluster issues
each reporting development team will take responsibility for the queries in their area for the external statistics clusters
Reporting Rollout Plans from different implementing Institutions
Sharon / Angela / others
Cornell (Sharon)
Duke (Angela
Demo of MARC queries
Angela? Jen?
Topics for Future Meetings
All
SRS MARC database structure: might it be worth separating control fields from data fields so fixed fields can be indexed differently from free text fields, maybe would reduce self joins on the table
could include in proposal, coordinate with Jennifer