Permission Levels Reference

This reference guide details the permission levels in Catalio’s sharing system and how they determine what users can do with shared resources.

Permission Hierarchy Overview

Catalio uses a hierarchical permission model where higher permissions include all capabilities of lower permissions:

Owner
  ↓ (includes all Editor permissions)
Editor
  ↓ (includes all Viewer permissions)
Viewer

Permission Levels Explained

Viewer

Access Level: Read-only

Viewers can see resources but cannot modify them. This is the most restrictive permission level for shared access.

What Viewers Can Do:

• View resource content and details
• See attached use cases and test cases
• View comments and history
• Export or print resources (where supported)
• Navigate through linked resources

What Viewers Cannot Do:

• Edit or update any resource content
• Delete resources
• Change sharing settings
• Add or remove team access
• Modify visibility settings
• Create child resources (use cases, test cases)

Best Used For:

• Stakeholders who need visibility without edit rights
• QA teams reviewing requirements before testing
• Executives needing overview access
• External auditors or compliance reviewers

Editor

Access Level: View and Modify

Editors have full read and write access to resources, but cannot manage ownership or delete.

What Editors Can Do:

• Everything Viewers can do
• Edit resource content and metadata
• Update status and priority
• Add and modify use cases
• Add and modify test cases
• Create linked resources
• Record test results
• Add comments and annotations
• Change resource visibility settings
• Add teams with viewer or editor access

What Editors Cannot Do:

• Delete the resource permanently
• Transfer ownership to another user
• Grant admin or owner permissions
• Remove the owner’s access

Best Used For:

• Active contributors on a requirement
• Development teams implementing features
• Business analysts refining requirements
• Cross-functional collaborators

Owner

Access Level: Full Control

Owners have complete authority over a resource, including administrative actions.

What Owners Can Do:

• Everything Editors can do
• Delete the resource permanently
• Transfer ownership to another user
• Remove any team’s access (except organization admins)
• Manage all sharing settings

Best Used For:

• Original requirement authors
• Primary responsible parties
• Resource administrators

Organization Admin

Access Level: Full Bypass

Organization Admins have unrestricted access to all resources in the organization, regardless of visibility settings or explicit grants.

What Organization Admins Can Do:

• Full access to all resources in the organization
• Bypass all visibility restrictions
• Access private resources without explicit grants
• Manage any resource as if they were the owner
• Administer organization-wide settings

Important Admin Characteristics:

• Admin access cannot be removed from individual resources
• Admins appear in the “Organization” tab of “Who Has Access”
• Admin status is managed at the organization level, not per-resource

Best Used For:

• IT administrators
• System administrators
• Compliance officers needing full audit access
• Organization leadership

Permission Comparison Table

How Permissions Cascade Through Inheritance

Catalio’s permission system includes automatic inheritance from parent resources to their children. This reduces administrative overhead and ensures logical access patterns.

Understanding Parent-Child Relationships

Resources in Catalio form a hierarchy:

Process (optional container)
  └── Requirement
        ├── Use Case
        │     └── Test Case
        └── Test Case (direct)

Inheritance Rules

When you have access to a parent resource, you automatically have access to its children:

1. Access to a Requirement grants access to:

   • All Use Cases under that Requirement
   • All Test Cases under that Requirement
   • All Test Cases under those Use Cases

2. Access to a Process grants access to:

   • All Requirements linked to that Process
   • All child resources of those Requirements

3. Permission level is preserved:

   • Editor on Requirement → Editor on child Use Cases
   • Viewer on Requirement → Viewer on child Test Cases

Inheritance Examples

Example 1: Team Access to a Requirement

Requirement: "REQ-001 User Authentication"
  └── Backend Team has Editor access

Automatic inheritance:
  ├── Use Case: "Login Flow" → Backend Team has Editor access
  ├── Use Case: "Password Reset" → Backend Team has Editor access
  └── Test Case: "Integration Tests" → Backend Team has Editor access

Example 2: Process-Level Access

Process: "Customer Onboarding"
  └── Architecture Team has Viewer access

All linked requirements and their children inherit Viewer access:
  ├── REQ-101 "Account Creation" → Viewer
  ├── REQ-102 "Email Verification" → Viewer
  └── REQ-103 "Profile Setup" → Viewer

Viewing Inherited Access

In the sharing modal, check the Inherited tab to see:

• Which parent resource grants the access
• What permission level is inherited
• Which teams have inherited access

Inherited access shows as:

"Access via Requirement: REQ-001 OAuth Implementation"
  → Backend Team (editor)
  → QA Team (viewer)

Overriding Inherited Access

To modify inherited access:

1. Navigate to the parent resource
2. Open its sharing modal
3. Modify the team’s access there
4. The change cascades to all children

Special Access Scenarios

Internal Visibility and Permissions

When a resource has Internal visibility:

• All organization members can view it
• Only users with explicit editor grants can modify it
• The owner retains full control

This means internal visibility grants implicit viewer access to everyone, but editing still requires explicit grants.

Private Resources

For Private resources:

• Only the owner can access by default
• Explicit grants are required for any other access
• Organization admins can still access (bypass all restrictions)

Cross-Team Collaboration

When multiple teams need access with different permission levels:

Requirement: "Payment Integration"
  ├── Payments Team → Owner
  ├── Backend Team → Editor (implements the feature)
  ├── Frontend Team → Editor (builds UI)
  ├── QA Team → Viewer (reviews before testing)
  └── Security Team → Viewer (compliance review)

Permission Best Practices

Principle of Least Privilege

Grant only the permissions users need:

• Start with Viewer access
• Upgrade to Editor only when modification is needed
• Reserve Owner status for truly responsible parties

Using Teams Effectively

• Group users by role (Backend Team, QA Team)
• Grant access to teams, not individuals
• Create focused teams for sensitive projects

Visibility vs. Permissions

Remember the distinction:

• Visibility controls who can see a resource exists
• Permissions control what they can do with it

Internal visibility with limited editor grants is a common pattern for requirements that should be widely visible but carefully controlled.

Audit Access Regularly

Periodically review the “Who Has Access” panel to:

• Identify outdated access grants
• Remove teams no longer involved
• Verify permission levels are appropriate

Quick Reference

When to Use Each Level

Permission Actions Summary

What’s Next?

• Best Practices - Security and collaboration guidelines
• Sharing Overview - Understanding visibility levels
• Managing Access - Step-by-step sharing guide

Need help? Contact support@catalio.ai or use the AI assistant in the application for guidance on permissions and access control.