Enhance User Permissions with Role-Based, Record-Level, and Field-Level Controls

[bhumikaguptaa]

The current permission system in Specify is table-based, granting all-or-nothing access to records within a table. This lacks the granularity needed for modern collection management and data publishing. For instance, an institution cannot:

• Effectively hide records or specific fields containing sensitive information (e.g., protected species, sensitive localities) from certain user roles, particularly public guest users.
• Implement a functional time-based embargo on newly cataloged records to delay visibility until publication.
• Grant users permission to edit certain fields in a record without giving them permission to edit all fields in that table.

This limitation affects both internal data curation workflows and the secure publishing of data to the public.

Proposed solution

It can be broken down into three core features:

1. Data-Driven Record & Field Visibility by User Role
   Implement a mechanism to control record and attachment visibility based on the data within the record itself. Allow administrators to create rules that hide or obscure records for specific user roles (e.g., "Public Access") if they meet certain criteria (e.g., Taxon is a protected species, or Locality is within a protected area).

Field-Level Obscurity: Beyond hiding the entire record, provide the ability to obscure or hide specific fields while leaving the rest of the record visible. This is critical for sharing as much data as possible while protecting sensitive details.

Implementation Idea: This could be similar to the isPublic checkbox from Specify 6 but expanded to be rule-based and applicable at both the record and field level.

2. Functional Embargo System
   Activate the existing schema fields (embargoReason, embargoReleaseDate, etc.) to create a functional embargo system. Records with an active embargo (i.e., embargoReleaseDate is in the future) should be hidden from view for specified user roles. Once the release date passes, the record should automatically become visible to those roles without manual intervention.

Use Case: This is essential for researchers and institutions that need to catalog data but delay its public release until a formal publication is out.

3. Granular Field-Level CRUD Permissions
   Allow administrators to configure Create, Read, Update, and Delete (CRUD) permissions at the individual field level for each user role. Instead of giving a user role "update" access to the entire CollectionObject table, an administrator could grant them permission to update Condition and Notes fields but not the CatalogNumber or Determiner fields.

Implementation Idea: This could be managed through the permissions configuration interface.

These enhancements would provide the flexibility and security that are increasingly critical for digital collection management and data sharing.

Reported by

Nate Shoobs, OSU

Link to the discourse post : https://discourse.specifysoftware.org/t/improving-user-permissions-in-specify-7-community-feedback-requested/2893

[grantfitzsimmons]

See #5630 for a potential dupe