[FOLIO-738] design a backend module for storing notes Created: 24/Jul/17 Updated: 12/Nov/18 Resolved: 07/Aug/17 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Jakub Skoczen | Assignee: | Heikki Levanto |
| Resolution: | Done | Votes: | 0 |
| Labels: | core, sprint19 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 1 day, 3 hours | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||
| Sprint: | |||||||||||||||||
| Description |
|
As described in
Proposed solution: 1. Specify 'notes' API resources (endpoints) using RAML and JSON Schema. Note: 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. |
| Comments |
| Comment by Heikki Levanto [ 26/Jul/17 ] |
|
Some small comments about not to do, at least yet.
Some comments on the access permissions
|
| Comment by Heikki Levanto [ 28/Jul/17 ] |
|
A note object should contain
There seems to be no need to store the ID of the referred object, we can use truncation query on the link field (link endswith /12345). If needed for indexing and performance, it can be added later, and hidden from the user. |
| Comment by Heikki Levanto [ 28/Jul/17 ] |
|
The API should be fairly regular CRUD API with endpoints
Selecting what notes to get is done by the usual cql querying |
| Comment by Jakub Skoczen [ 28/Jul/17 ] |
|
Heikki, it's worth noting that we are working on a generic meta-data section for thing like createdDate and createdBy, see:
|
| Comment by Heikki Levanto [ 28/Jul/17 ] |
|
Right, using a standard metadata section makes a lot of sense. |
| Comment by Marc Johnson [ 28/Jul/17 ] |
|
Ok, I'm going to share my reflection of this, to see if I understand it:
The process a client would go through to find the notes for a record (e.g for an item with ID 12345): 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? |
| Comment by Heikki Levanto [ 28/Jul/17 ] |
|
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. |
| Comment by Heikki Levanto [ 31/Jul/17 ] |
|
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. |
| Comment by Heikki Levanto [ 01/Aug/17 ] |
|
Design going in parallel with implementation (
|