Field and action based permissions
Field based permissions
Use cases
# | Use case / Feature | Description | Apps | Goals | Added by ... | Priority? |
---|---|---|---|---|---|---|
1 | Specific permission to edit the barcode field on the item | Editing the barcode field should only be possible with specific permission. User should not be able to edit the barcode with edit item permission only. User needs to be able to edit everything except for the barcode. User needs to be able to edit the barcode, but should not be able to edit any other data on the item. If resource is in remote storage, users are not allowed to change the barcode Does not need to be solved via permissions Having the ability to activate edits at the field level in the detail view vs. entering a full edit screen could help avoid errant data entry… | Inventory | Martina Schildt after App Interaction discussion | Nice to have | |
2 | Specific permission to edit source records (quickmarc) | User can have view and edit vs. only view permission on e.g. source record (quickmarc) - there seems to be a JIRA | Inventory | Martina Schildt after App Interaction discussion | ||
3 | Specific permission to mark instances for deletion | Mark an instance in Inventory for deletion will be a specific field that can be selected in edit mode. This field should not be selectable by everyone with edit permission on the instance. | Inventory | |||
4 | Specific permission to add notes to records. | A user that only has view permissions for an app, needs to be able to make a note. Current workaround is to have a person with edit permissions make the note for you. This would probably be needed in most apps, but not all. Split notes from rest of record - make them own object In the item record, there are two types of notes: | Multiple | Important - across apps | ||
5 | Specific permission to edit user custom fields. | A library may want to store information in a custom field on a user record that can be viewed by all, but only editable by some. For example, if a library provides accounts for visiting scholars and wants to list a budget code to be charged if the scholar doesn't return items, this may be viewable by all, but only editable by the library circulation manager. | Users | (OLD ACCOUNT) Erin Nettifee | ||
6 | Specific permission to view field "Birth date", Home address, other personal information. | Not all system users should be able to see the birth date that is recorded in a user record. This information needs to be recorded to confirm that a person is of legal age. Birth date: data accessible to specific people, not everyone differentiate between create, edit and view; view most vulnerable | Users | Martina Schildt | Important - Users app | |
Action based permissions
Use cases
# | Use case / Feature | Description | Apps | Goals | Added by ... | Priority? |
---|---|---|---|---|---|---|
1 | Set renewal priority | Selectors should be able to edit "renewal priority" in Agreements, but nothing else, since they are the ones who decide whether they want to renew an item, but otherwise they should not be allowed to edit. | Agreements | Martina Schildt after App Interaction discussion | ||
2 | Ability to "backdate" a loan | Staff checking items in should be able to check them in, but only select staff should be able to check an item in and change the due date to a time in the past (which could allow a user to avoid fines for an item being overdue or lost.) | Check in | (OLD ACCOUNT) Erin Nettifee | Important Wait for Erin to join |
Use cases solved
# | Use case / Feature | Description | Apps | Goals | Added by ... | Priority? |
---|---|---|---|---|---|---|
1 | Specific permission to see username and pw for platform on organization record | Martina Schildt link JIRA works via API endpoint ongoing discussion in TC on storing this personal information more secretly | Organizations | Martina Schildt after App Interaction discussion | ||
2 | Specific permission to download attached document in LicenseS app | was already built with specific API endpoint | Licenses |