Skip to main content

Permissions

Administrative best practices​

Administrators should create user groups and assign relevant permissions to those groups rather than to individual users. While groups are not specific to any site, the permissions assigned to a group can be site-specific.

For example, to define permissions for a single site, an administrator should create a group (e.g., SITE1_INVITRO) and assign the appropriate permissions only for "Site 1".

Roles​

Role-based access control provides broad access levels to users.

Group and role mapping​

User groups are mapped to roles and authorities.

  • System-level groups typically map to roles with the ROLE_ prefix. For example, the group ADMINS becomes ROLE_ADMINS.
  • Custom groups map to authorities with the GROUP_ prefix. For example, a custom group SITE1_INVITRO becomes GROUP_SITE1_INVITRO.

Every user who successfully logs into the system is automatically assigned the ROLE_USER authority.

Warning: Use caution when assigning permissions to a group containing most users or to ROLE_USER directly, as this affects all authenticated users globally.

Access control lists and fine-grained permissions​

For more precise control, the system uses access-control lists to manage specific actions.

Secured actions​

A secured action represents a functional area or module, such as Passport Data, Inventory, or Taxonomy. It is the primary mechanism for configuring access, and permissions such as read, write, and delete are assigned to users or roles for a specific action.

Hierarchy and inheritance​

The system uses a hierarchy to manage permissions:

  • Global actions: An action with no associated site defines a global permission.
  • Site-specific actions: An action associated with a specific site allows for overriding or extending permissions for that site.
  • Inheritance: Site-specific actions inherit permissions from the corresponding global action.

Functional areas​

The system covers a wide range of actions across different domains:

ActionDescription
PassportDataAccession passport data
AcquisitionAccession acquisition data
AccessionAttachmentAttachments associated with accessions
SourceDescriptorAccession source descriptors
AccessionDOIDigital Object Identifiers (DOI) for accessions
InventoryDataInventory data
InventoryAttachmentAttachments associated with inventory
InventoryGroupInventory groups
InventoryDOIDOIs for inventory
InvitroIn-vitro data and management
ViabilityTestViability testing data
InventoryQualityInventory quality data and the Quality tab on inventory details
CropTraitCrop trait definitions
CropTraitObservationObservations of crop traits
CropCrop data
TaxonomyTaxonomy and classification data
RequestMaterial requests
RequestItemIndividual items within a request
GeographyDataGeographic and location data
MaterielMateriel data
MethodDataMethod data and protocols
CooperatorDataCooperator information
GenesysRequestsRequests via Genesys
GenesysUploadData uploads to Genesys
CitationsBibliographic citations
LocationLocation reservations and management
PathogenPathogen data
SymptomSymptom data
SystemActionGeneral system-level actions

Management​

Administrators with the GROUP_ADMINS authority manage these mappings. Site-specific mappings can be created or removed as needed.

Module-specific permissions​

Permissions are assigned to specific modules to control access to different views and tools.

Inventory​

Access is governed by the InventoryData action.

  • Read: All standard views (Images, Summary, Schedule, Action, Storage, Group, Storage Navigator, Compare Sites, Prepare Multiplication).
  • Write: Adjust and Assign Storage Location.
  • Create: Acquisition, Split, and Harvest.

The Quality tab on the inventory details page is governed by the separate InventoryQuality action. Grant InventoryQuality read or write permission to control who can view or edit quality records independently of general inventory permissions.

In-vitro​

Access is governed by the Invitro action.

  • Read: All standard views.
  • Write: Requires InventoryData write permission for Assign Storage Location.

Accession​

Access is governed by PassportData and GenesysUpload.

  • Read (PassportData): All standard views (MCPD, Images, Summary, Schedule, Action, Source Observations, Source Descriptors).
  • Manage (PassportData): Collecting Missions (Exploration).
  • Manage (GenesysUpload): Genesys Attachments.

Viability​

Access is governed by the ViabilityTest action.

  • Read: Print labels, Results, Actions, and Rules.
  • Write: Observations and Inventory (Start test).
  • Manage: Prepare Order.

Simple modules​

For these modules, access is governed solely by the read permission for the respective action. All internal items are available if the module is accessible:

  • Bibliography (Citations)
  • Taxonomy (Taxonomy)
  • Request (Request)

Role-only modules​

The following modules are gated solely by the USER role:

  • Offline Mode

User and cooperator uniqueness​

When editing system users, the system checks that the selected cooperator is not already assigned to another user. If the cooperator is already linked to a different user, the save is blocked. Choose a different cooperator or resolve the existing assignment before saving.

Enforcement​

The user interface controls the visibility of tools and menu items based on the user's roles and permissions. The same permissions are also checked on the server side to ensure secure access to data and functionality.

User access scenarios​

This section describes what users see in the interface based on their assigned roles and permissions.

Guest​

Users who are not authenticated or have no assigned role:

  • Access to the home page
  • Login and logout options
  • Public resources, such as help documentation

Basic user​

Users with the USER role:

  • Access to the home page
  • Access to offline tools
  • Access to functional modules only if they have the corresponding read permission for that action. For example, they only see "Passport Data" if they have the PassportData permission.

Specialist​

Users with the USER role and specific action permissions:

  • A tailored set of modules based on their action permissions. For example, a user with only InventoryData and Invitro permissions will only see those two menu items.

Administrator​

Users with the ADMINISTRATOR role:

  • Full access to the administrator panel
  • Typically, they also have the USER role and the permissions required to manage system data.