Cnidarity is a specialized content management system (CMS) designed specifically for academic and scientific research. It helps researchers organize, store, and manage research data across various scientific disciplines.

How do you pronounce Cnidarity?

Cnidarity is pronounced 'NI-DAIR-ity'. It is a proprietary brand name for our research data management platform.

Is Cnidarity the same as Cnidaria?

No, Cnidarity and Cnidaria are completely different. Cnidarity is our research data management platform brand name. Cnidaria refers to a phylum of invertebrate animals including jellyfish, sea anemones, and corals. The names are spelled and pronounced differently.

How is Cnidarity different from other CMS platforms?

Unlike general-purpose CMS platforms, Cnidarity is built specifically for academic research needs with features for data modeling, research collaboration, and scientific data management.

What types of research can Cnidarity support?

Cnidarity supports all academic research fields with flexible data modeling capabilities that adapt to any scientific discipline's unique requirements.

User Roles & Permissions

Name: Cnidarity
Rating: 4.8 (23 reviews)
Author: Cnidarity

Understanding authorization and access control in the platform

Introduction

Cnidarity implements a comprehensive permissions system to ensure secure collaboration across your research projects. The platform manages access control at two primary levels:

Workspace Level: Controls who can access a workspace and determine who can create or manage projects.
Project Level: Provides fine-grained control over what actions users can perform within specific projects.

This hierarchical approach ensures that research teams can collaborate efficiently while maintaining data integrity and security.

Users must first be members of a workspace before they can be added to any projects within that workspace.

Workspace Roles

At the workspace level, there are two distinct roles with clearly defined permissions:

Each workspace has exactly one owner who has full administrative control:

Create new projects within the workspace
Invite users to the workspace
Remove users from the workspace
Edit workspace details and settings
Manage workspace subscription and billing
Delete the workspace

The workspace owner automatically has full access to all projects within the workspace, regardless of whether they've been explicitly added to those projects.

All other users invited to a workspace are considered guests with limited permissions:

View the workspace
Access projects they've been specifically invited to
Cannot create new projects
Cannot invite other users to the workspace
Cannot modify workspace settings

Workspace guests can only access projects they've been explicitly added to, with permissions defined by their project-level role.

Only the workspace owner can create new projects or invite users to the workspace. This ensures centralized control over workspace resources and membership.

Project Roles

At the project level, user permissions are more granular, allowing for precise control over access to research data. Workspace members can be assigned one of three project roles:

Project Administrators have comprehensive control over the project:

Create, modify, and delete data models
Create, modify, and delete attributes
Create, modify, and delete model relationships
Create, modify, and delete records (data entries)
Manage project settings
Add users to the project
Change user roles within the project

Project Admins can add users from the same workspace to the project, but cannot invite external users to the workspace.

Regular Users can work with data but cannot modify project structure:

Create, modify, and delete records (data entries)
View models and attributes
Cannot modify models or attributes
Cannot modify relationships
Cannot change project settings
Cannot manage users

Regular Users are ideal for team members who need to input and edit research data but shouldn't alter the underlying data structure.

View Only users have read-only access to project data:

View records and their data
Cannot create, modify, or delete any records
Cannot create, modify, or delete models
Cannot create, modify, or delete attributes
Cannot create, modify, or delete relationships

View Only access is appropriate for stakeholders who need to see research data but shouldn't make any changes.

All user roles in a project (other than the Workspace Owner) are bound by the permissions of their assigned role. For example, a Project Admin cannot perform actions that are restricted to the Workspace Owner, such as deleting the workspace or inviting new users to the workspace.

Role Privileges Comparison

The following table provides a detailed comparison of permissions for each role in the platform:

Permission	Workspace Owner	Workspace Guest	Project Admin	Regular User	View Only
Workspace Level
View Workspace	✅	✅	✅	✅	✅
Edit Workspace	✅	❌	❌	❌	❌
Delete Workspace	✅	❌	❌	❌	❌
Create Projects	✅	❌	❌	❌	❌
Invite Workspace Users	✅	❌	❌	❌	❌
Remove Workspace Users	✅	❌	❌	❌	❌
Project Level
Create Models	✅	❌	✅	❌	❌
Update Models	✅	❌	✅	❌	❌
Delete Models	✅	❌	✅	❌	❌
Create Attributes	✅	❌	✅	❌	❌
Update Attributes	✅	❌	✅	❌	❌
Create Records	✅	❌	✅	✅	❌
Update Records	✅	❌	✅	✅	❌
Delete Records	✅	❌	✅	✅	❌
View Records	✅	❌	✅	✅	✅
Manage Project Users	✅	❌	✅	❌	❌
Update Project Settings	✅	❌	✅	❌	❌

Note that Workspace Guests have no inherent project permissions. They gain access to projects only when explicitly assigned a project role (Admin, Regular, or View Only).

This permission structure ensures that workspace owners maintain control over the overall research environment, while project-level roles provide the flexibility needed for different types of collaboration within specific research projects.

Best Practices

Follow these recommendations for effective user role management in your research platform:

Use the Principle of Least Privilege

Always assign users the minimum level of access they need to perform their tasks. This reduces the risk of accidental data modification or deletion.

Plan Your Role Structure

Before inviting team members, plan out what roles they should have in each project. Consider their responsibilities, technical expertise, and need for access to sensitive data.

Limit Project Admins

Restrict Project Admin roles to team members who need to manage the project structure. Too many admins can lead to uncoordinated changes in your data models.

Use View Only for External Stakeholders

For stakeholders who need to see research progress but shouldn't modify data (like funding agencies or external reviewers), the View Only role is ideal.

Regularly Review Access

Periodically review who has access to your workspaces and projects, and at what permission levels. Remove users who no longer need access and adjust roles as team responsibilities change.

Train Users on Their Permissions

Ensure your team members understand what they can and cannot do with their assigned roles. This prevents frustration and reduces support requests when they encounter permission restrictions.

For large research teams, consider creating a documentation reference that outlines which team members have what level of access to different projects, along with the rationale for each assignment.

Previous Invitations NextActivity Tracking