[FOLIO-577] SPIKE: Needs for Notes Feature Created: 27/Apr/17  Updated: 12/Nov/18  Resolved: 28/Nov/17

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Niels Erik Nielsen
Resolution: Done Votes: 0
Labels: sprint13
Remaining Estimate: Not Specified
Time Spent: 1 day, 15 minutes
Original estimate: Not Specified

Sprint:

 Description   

Purpose: Consider and document thoughts on front and back-end needs for the Notes feature. Any thoughts on how big this is would also be valuable. As mentioned, we might be able to get away with a simpler way to capture notes for v1 but we'd rather do it per Filip's requirements, if possible.

Reference materials:

  • STCOM-59 Closed describes the specific requirements for a first iteration of this feature
  • LIBAPP-122 Closed describes Filip's long-term vision for this feature

[Draft: Needs for Notes feature, https://docs.google.com/document/d/1D_yuzkZc8b3NnvxFmJ2Pj9lKQDDJh66eJyTP58_HnnQ/edit]



 Comments   
Comment by Mike Taylor [ 27/Apr/17 ]

First thoughts on back-end storage:

1. Notes should not be stored in a facility related to an application module such as Users or Items – otherwise many different back-end modules would need to be changed to support notes. Instead, there should be a back-end module that many different UI module can use for CRUDding their notes.
2. That back-end module could be its own specialised mod-notes; or perhaps the notes could reasonably be squeezed into mod-config. Are there any other options?
3. Different applications will use slightly different logical schemas for their notes (e.g. notes in Users will have a "can the user see this note about himself?" bit, while notes in Items will not). But the differences will probably be small enough that a single physical (JSON) schema will suffice for all modules to share.
4. The heart of that schema will be just {{{ note(text), notatedObjectId(UUID), noteMaker(userId), noteDatestamp(dateTime) }}}. Other fields used by only a few modules, such as userIsAllowedToSeeNote can also be added.

Sound about right?

Comment by Heikki Levanto [ 27/Apr/17 ]

I agree that the notes should not be embedded in users and other modules using them. It might be best to make them first class citizens, with a back-end module of their own.

I would hesitate with fields like "userIsAllowedToSeeNote". I would rather have an open-ended list of tags that each notes-using app can define for itself. That way, we don't have to change the notes structure at all when the poetry-club app wants to add a "forMembersOnly" tag in their notes.

Comment by Mike Taylor [ 27/Apr/17 ]

Yes, that is better. (So long as our mechanisms can handle a field extensions of type

listof struct { fieldName(string), fieldValue(string) }
Comment by Niels Erik Nielsen [ 27/Apr/17 ]
For now

The note JSON structure in first comment would likely suffice for a ui module to display notes for its records.

But at least one additional identifier will be necessary for a notes app to find the record that the UUID refers to.

(Or, we would need a registry of UUID->API-endpoint references, but we would not go there I'm sure, not just for the sake of a notes app at least).

The structure should also have a PK of its own of course, but guess that's implicit.

For later

Additional structures would be needed for Filip's ideas for "triggers", "tagging", "visibility", "unread notes", but that kind of information would likely live outside of the basic note JSON structure as discussed here.

I don't know if there potentially also could be requirements that a note should be editable, that it should keep a history, or that multiple users should be able to contribute to a note. I don't immediately see thoughts on that it in the UX jiras.

Comment by Mike Taylor [ 27/Apr/17 ]

Ah, right: you mean that the note would need a "what kind of object this note is attached to" field. Right: so that it knows whether to search for the annotated object in mod-users or mod-inventory.

Agree that, for this purpose at least, a system-wide UUID->type mapping would be unnecessary and inelegant.

And yes, of course the note would need its own PK, but that is uninteresting

Comment by Charlotte Whitt [ 27/Apr/17 ]

"I don't know if there potentially also could be requirements that a note should be editable, that it should keep a history, or that multiple users should be able to contribute to a note. I don't immediately see thoughts on that it in the UX jiras."

... yes (some/all?) notes should be editable and keep a track history.

I have started a Google doc where I will gather relevant requirements about Notes in e.g. the FOLIO 2018 Release doc, and misc. discussed with the SIGs -
see https://docs.google.com/document/d/1D_yuzkZc8b3NnvxFmJ2Pj9lKQDDJh66eJyTP58_HnnQ/edit (Please note the document is Work-in-progress)

Comment by Mike Taylor [ 27/Apr/17 ]

Things like editability of notes with version history seem rather esoteric for an MVP. Is this stuff included in the MVP? If not, I think we should ignore it: we have a great deal to do already.

Comment by Charlotte Whitt [ 27/Apr/17 ]

Yes, like Niels wrote: FOR LATER

Comment by Niels Erik Nielsen [ 27/Apr/17 ]

All right, Charlotte, in that case we may decide to have a data structure with an array of note editions from the outset (to hopefully reduce the need for data restructuring later), and then for the MVP only use the first array entry for any given note.

Comment by Niels Erik Nielsen [ 13/Nov/17 ]

Cate Boerema Can we close this?

Heikki and others may have long moved beyond it.

Generated at Thu Feb 08 23:06:49 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.