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, GGCE uses ACLs to manage specific actions.

Secured actions

A SecuredAction represents a functional area or module within the system, such as Passport Data, Inventory, or Taxonomy. It is the primary mechanism for configuring access to GGCE and serves as the object in the ACL system. Permissions, such as read, write, and delete, are assigned to users or roles for a specific SecuredAction.

Hierarchy and inheritance

The system uses a hierarchy to manage permissions:

• Global actions: A SecuredAction with no associated site defines a global permission.
• Site-specific actions: A SecuredAction 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:

Action	Description
PassportData	Accession passport data
Acquisition	Accession acquisition data
AccessionAttachment	Attachments associated with accessions
SourceDescriptor	Accession source descriptors
AccessionDOI	Digital Object Identifiers (DOI) for accessions
InventoryData	Inventory data
InventoryAttachment	Attachments associated with inventory
InventoryGroup	Inventory groups
InventoryDOI	DOIs for inventory
Invitro	In-vitro data and management
ViabilityTest	Viability testing data
CropTrait	Crop trait definitions
CropTraitObservation	Observations of crop traits
Crop	Crop data
Taxonomy	Taxonomy and classification data
Request	Material requests
RequestItem	Individual items within a request
GeographyData	Geographic and location data
Materiel	Materiel data
MethodData	Method data and protocols
CooperatorData	Cooperator information
GenesysRequests	Requests via Genesys
GenesysUpload	Data uploads to Genesys
Citations	Bibliographic citations
Location	Location reservations and management
Pathogen	Pathogen data
Symptom	Symptom data
SystemAction	General system-level actions

Management

Administrators with the GROUP_ADMINS authority manage these mappings. While site-specific mappings can be created or removed, the core action definitions are driven by the SecurityAction enum in the backend.

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.

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

Enforcement

The user interface controls the visibility of tools and menu items based on the user's roles and permissions. The API enforces these permissions 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 SecuredAction. 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 SecuredAction 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 at /admin
• Typically, they also have the USER role and the SecuredAction permissions required to manage system data.