design a backend module for storing notes
Description
Environment
Potential Workaround
relates to
Checklist
hideTestRail: Results
Activity
Heikki Levanto August 1, 2017 at 1:12 PM
Design going in parallel with implementation (https://folio-org.atlassian.net/browse/MODNOTES-1#icft=MODNOTES-1)
Heikki Levanto July 31, 2017 at 1:14 PM
Discussed on our team-1 meeting, and decided to go by the storage link for now, and hope for the UI component being able to fetch its own notes.
Heikki Levanto July 28, 2017 at 2:36 PM
Good question. I can see two ways out: Either the note belongs to /users/12345, and users-bl will fetch the notes too. Or the note belongs to the thing the UI is displaying, users-bl/12345, and the UI is responsible for fetching the notes when it wants to display them. I lean a little towards the latter, but am not at all sure of all the implications.
Marc Johnson July 28, 2017 at 1:58 PM
Ok, I'm going to share my reflection of this, to see if I understand it:
Notes are related to a single record
They are related by a path (relative to the root Okapi URL I'm assuming)
The process a client would go through to find the notes for a record (e.g for an item with ID 12345):
1. Determine a path for a record (presumably based upon a template, e.g. /items/id but might be based upon removing the base): /items/12345
2. Use that path in a CQL request like /notes?query=link=/items/12345 (I haven't escaped this for clarity)
Given that we have representations of records addressable via different paths, e.g. users at /users/12345 or /bl-users/12345, or items /inventory/items/id and /item-storage/items/id which is the canonical path that all notes should be related to?
Heikki Levanto July 28, 2017 at 1:26 PM
Right, using a standard metadata section makes a lot of sense.
As described in https://folio-org.atlassian.net/browse/LIBAPP-188#icft=LIBAPP-188 we need a way to attach "notes" to various records in the system (users, items, etc). In the simplest form "note" is a piece of plain text, eventually it may include things like mentions or tiriggers.
Proposed solution:
1. Specify 'notes' API resources (endpoints) using RAML and JSON Schema.
2. Create a new FOLIO module, mod-notes, that allows for CRUDing note records. mod-notes should be implemented as a standard RMB module
3. Each note record contains a piece of
text,createdDate,updatedDate,creatorIdof the authoring user, and alink(path+UUID) to the record it attaches to3. It should be possible to query notes for a given object (using the full
link, or justpathor just theUUID) and for a given users (usingcreatorIde.g to display all notes by a given user)4. Permissions: standard permissions to Create/Read notes, user-specific permissions (can be modelled as
selfendpoint) to Update/Delete notes created by the current userNote: there user stories talk about the ability to mark notes that the user have read, but we consider this capability to be related to notifications (which are are individual to each user) rather than notes.