internal location: add field accessible_by_patrons #1235
Conversation
JakobMiesner
force-pushed
the
feature/hide-call-numbers
branch
2 times, most recently
from
d564e6c to
496e16b
Compare
JakobMiesner
force-pushed
the
feature/hide-call-numbers
branch
from
496e16b to
7e3a17c
Compare
JakobMiesner
force-pushed
the
feature/hide-call-numbers
branch
from
7e3a17c to
5f4818e
Compare
| "identifiers": item.get("identifiers"), | ||
| "internal_location": { | ||
| "name": item.get("internal_location", {}).get("name", ""), | ||
| "accessible_by_patrons": item.get("internal_location", {}).get( |
There was a problem hiding this comment.
after some thinking, I am concerned about how targeted this field's name is.
it fulfils the need, but it is not extensible for the future, and not consistent with how we handle "restrictions" in invenio.
I would rather name it as "restrictions" and make it possibly a list, which gives us more flexibility of implementing more restrictions in the past.
as an example: restrictions: ["librarians"] would mean the location is visible to only librarian, so it does not limit the functionality only to the patron
another example: restrictions: ["archivists"] could mark places only accessible to some personnel who can go into archives, but not the librarians.
It opens a door to cover more use cases, while not being complex in implementation.
There was a problem hiding this comment.
In that case, isn't there maybe an already existing module in invenio for record&group specific permissions?
There was a problem hiding this comment.
yes, there are already existing implementations. One example would be restriction on the document field.
2 participants
closes: CERNDocumentServer/cds-ils#955