Date
...
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Comments | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision | |||||||||
Permissions | N/A |
| ||||||||||
Notes
May 27 will be cancelled, May 30 will be cancelled unless we hear otherwise (up to Emma Boetcher)
Angela Zoss assessment team at Duke and reporting SIG
update on reporting SIG
Reporting SIG master spreadsheet - all current entries have been transferred to JIRA
Master spreadsheet now frozen and new reports being added directly to JIRA
REP is for all reporting tickets, tags are also helpful to filter, functional area for Resource Access as well
happy to keep collecting reports
work is now transitioning to create prototype reports using the data warehouse
data warehouse is under development in parallel with FOLIO, relational database, starting with high priority reports in JIRA
locating and identifying data elements, once mapped out, pushed to developers
developers build structures into data warehouse, postResql dB
only including data elements that are needed and don't retain info that isn't useful, good privacy practice, but intention is to eventually have pretty much everything in the LDP (Library Data Platform)
developers build test data to run and test reports
protyping group build SQL queries to retrieve data that users would want - stored in github for now
benefit of SQL and reSQL is a variety of tools are possible to use, including MSAccess, etc.
API documentation: https://dev.folio.org/reference/api/
finding gaps, such as renewals, where it's not possible to run the report based on data being stored
hard coding essential reports with explicit SQL query
right now copy and paste SQL from github into whatever you use and then rely on SQL guru
first line of defense to reach out to the person who built SQL query
Reporting SIG potential discussion of building a reporting interface
documentation as to how to connect MSAccess, tablaeu, etc. and other tools to the LDP
long term would love to see one or more instituations to go all in on open source tool to build reports
DWB has serious concerns about assumption that LDP will be a snapshot overnight with 12-24 hours behind, eventually to be able to push that out more frequently
dependent on a streaming messaging service that got pushed back in development/tabled
folio apps won't necessarily retain a full history of all record changes, whereas the LDP should (except when decisions are made for privacy purposes)
Andrea believes we are missing a number of vital reports, such as fines and fees stuff, show me all people who are blocked for x, y, or z and we need to review as a SIG
Are all in app reports included in the master spreadsheet, given that they require live data?
label "appreport" lets you look for in app reports in jira
Carsten - data aggregation layers?
LDP is supposed to be fairly performant but data aggregation may well be helpful to optimize and developer may have it on his radar
Cate re teams and permissions
teams and permissions-could you lock down things like bills owned by law library by team rather than specific permissions
or ability to update particular fields
Andrea feels may not be worth the overhead of maintaining the lists
workflow app could also be included, such as which teams could edit workflows, etc.
will start with Acquisitions
users will be able to be assigned to multiple teams
need ability to view who is on what team, who all has been given a particular permission set, and ability to remove them or add them - Cate will add this to the backlog
Carsten-Teams might be able to solve difficult privacy issues. We have several institutions where personell works "across" libraries...
basic CRUD permissions are there
several apps we have granular permissions (like Users)
several apps have all-or-nothing permissions and will need to be broken down into more granular permissions
you can assign specific permissions or create permission sets and assign them
user interface is not good, stories in place to refine and improve interface
what do we still need?
lots of action-based permissions including overrides, canceling requests, etc.
blocked on the architecture of how to achieve this, FOLIO does not support it yet so we need that functionality in place
teams
field restrictions such as within the user record
permissions within settings to let users view settings but not edit any of them
DWB all settings view and all settings edit would be ok
Andrea all settings edit would not be acceptable to technical services staff at Duke
Sean re locations and circ rules
needs a little time to discuss possible inconsistencies in presentation of location data attributes in circ rules
by and large you would expect to use codes when building circ rules, but maybe names also need to appear at the location level
does name/code vs code/name matter since they are reversed on circ rules vs item record
type-ahead works for both code and label
there is now a multi-select in circ rules is useful and then you need a "done" button
Cheryl-what does the "set location anchor" do? It lets you set a circ policy for multiple locations regardless of above hierarchy (so you can set something for microforms across all locations or set the anchor to lock it within the hierarchy
leave location details to a later discussion in the build