Date
...
Time | Item | Who | Description | Goals/Info/notes |
---|---|---|---|---|
2min | Administrivia |
| ||
30Min | Additional staff slip tokens for requesters | |||
15Min | Cleaning up patron notice features | Darcy Branchini |
Meeting Notes
Additional staff slip tokens for requesters - Brooks
...
What would be ideal is if we could make it possible to add flow logic to template text via an extension on Mustache. Might be easier than adding tokens one-by-one, especially for more complicated ones like effective name, and would give users a lot of power.
More info: https://handlebarsjs.com/
Another option is to make all data available to users to be a token. Would require changing the UI. Would need to indicate what kind of token you want, for instance, otherwise it would be too many things being thrown at you all at once. Responsibility for describing available data could reside with module owners, which is how permissions work now.
NEXT STEPS: Darcy will create features which capture all desired new tokens as a short-term solution, and also features which capture the possible more adaptable/sustainable long-term solutions proposed at this meeting.
Cleaning up patron notice features - Darcy
UXPROD-1627: Do we still need this now that this information is available through the Circ log app? Consensus: what would be even better than this is an accordion in the User record which includes the most recent n transactions involving the user pulled from the Circ log. Individual loans are another place where it would be useful to include this info. Would be similar to work being done in Inventory app to include Acquisitions info there. NEXT STEPS: Darcy will remove feature UXPROD-1627 but add a new feature which captures the Circ log suggestion described above.
UXPROD-2382: Capturing "health" of patron notices can be accomplished via API. What can't is the visual element described in the feature. But if we were going to invest effort into developing this functionality, why wouldn't we want to extend it to include other areas of FOLIO? Counter-argument: maybe this could be proof of concept for a bigger feature? Seems more like admin-level functionality as opposed to user-level, and thus might be out of scope for the SIG. Hosting partners like EBSCO and Index Data have their own solutions for this. Question: could said partners add whatever they have built to FOLIO's code? Maybe not, since it's environment-specific.
UXPROD-932: FOLIO doesn't actually SEND notices, but rather passes them off to an external system to be sent. What might be more useful is a common interface that these systems could interact with. Basically, FOLIO would be defining an API for systems to call with this information. NEXT STEPS: Darcy will revise the feature accordingly.
Meeting Outcomes
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Reasoning | Link to supporting materials | Comments |
---|---|---|---|---|---|---|
e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision |
| e.g. mock-up, JIRA issue | |