|
Restricting access to some user data
|
@Amelia Sutton
| The data that should be restricted: Fees/Fines Email Birthdate Telephone number Address University ID
All of these, except for University ID, can be easily hidden. Fees/Fines: Address: When a user makes a request, the Address shows up in the Delivery Preference field. Should we ask for the Address to be restricted in the Requests app? We decided no. That’s already restricted by permissions to access Requests.
Should we ask for the whole “Contact Information” accordion in the Use record to be hidden if a user doesn’t have permission to view it? We decided yes. Nearly all of the sensitive user data is in that accordion. University ID This was a little more difficult to define, because the User record doesn’t have a “University ID” field. In most cases, the University ID is in the External System ID field. In one case, at a University library, a student’s University ID is a universal ID for nearly all things on campus. The barcode is based on the University ID barcode, with an easily-deduced pattern. If a user using Checkout doesn’t use a barcode as an input, the borrower’s user using Checkout doesn’t use a barcode as an input, the borrower’s barcode does come up when the borrower is found. We would need to further clarify the definition of a University ID if we want to ask to restrict it. Some University IDs are in a Custom Field. We decided not to ask for permissions around viewing Custom Fields.
The conclusion |