Improving User Permissions in Specify 7 (community feedback requested!)

New Feature Requests
1

This topic was touched upon in the Open Discussion on Associated Media Management in Specify 7 - #3 by Grant meeting (specifically @cefuchs @HeatherC @NielsKlazenga @cwthomp @mcruz shared opinions), but @alexis.beck and I were discussing it again recently and decided to post a formal feature request for some updates to permission structures.
The permissions system in Specify influences both what logged-in users can do, and also what the public can see and interact with in public-facing databases with an Enable anonymous/guest access in Specify 7 or other public guest user configured. So improvements to this system would benefit both curation and publishing.

There are 3 main things we want to see with regard to user permissions and user access to data in Specify:

  1. Hide records and attachments from view by certain user “roles”.

  • For example: Limiting read permission for “Public Access” user role on CO records identified as certain taxa (like protected species) or from certain locations (like protected/secret wildlife areas) could be accomplished by a simple checkbox, and indeed this field existed in 6 with isPublicfor attachments, and embargoStartDate in CO records.

  • One complication is that blocking a record from view is not the same thing as obscuring sensitive data. Ideally, we should be able to obscure/block certain fields from view for certain user groups while leaving the rest of the record available. See Feature 3 below.

  • Closed issue on GitHub here seems to indicate this is no longer a feature in the pipeline for development, but many many institutions want this, per the Media Management discussion.

  1. Hide records from view by certain user “roles” for a set period of time
  • “Embargoing” records or specific data after accession/cataloging until publication is one major use case. There are already schema fields for this (embargoReason, embargoReleaseDate, etc.), but they are non-functional, or at least only serve as fields that can be used in things like automated RSS export queries to limit pushing certain records to aggregators.
  1. Allow configuring record-level and field-level permissions for create, read, update, and delete operations on records for users with specific role.
  • This is touched on in GitHub here
  • Currently, user permissions are all-or-nothing by table. If a user has edit permissions on a table, they can edit any field in any record in the entire table. Allowing customization makes it easier to control who can see (and change) what. Potential downside risk is that the added complexity could make it harder to administer users and set up permissions.
  • One way to accomplish some of this functionality for users without workbench/batch edit privileges if we had Feature 1 implemented would be by making forms conditionally render certain fields based on user role, or perhaps more simply, allowing alternate viewdefs for forms based on user role. Currently, forms do not render fields when a user does not have read access on the relevant table, which is a desired behavior.

Any other members of the community are encouraged to comment and chime in! And if you think any of these changes would be helpful, please comment and say so :slight_smile:

1 Like