CS Resource Roles & Permissions

Complete breakdown of what each role in CS Resource can and cannot do.

A CS Resource user can be granted one of three roles within the application. Each role has specific access allowance, detailed in the article below. Use this guide to determine the best role for your resource application users.

---

1. Reader

✅ CAN DO:

• Dashboard

  • View general database statistics

❌ CANNOT DO:

• Anything really 🤷

• Create, update, or delete resources

• Read resources (no resource:read permission)

• View specific resource statistics

• View recent activity

• Manage users

• Manage attributes, groups, service areas, funding sources

• Manage taxonomy

• Manage service conditions

• Manage external agencies

• Manage audit types

• View annual update statistics

Use Case:

• General organization member who does not curate or manage the resource database

---

2. Writer

✅ CAN DO:

• Resource Management

  • Create resources

  • Read resources

  • Update resources

  • Delete resources

• Annual Update Change Requests

  • Create change requests

  • Read change requests

  • Update change requests

  • Delete change requests

• Dashboard Access

  • View recent activity

  • View resource statistics

  • View my tasks

  • View annual update statistics

• Read-Only Access to Configuration

  • Read attributes (attribute-manager:read)

  • Read audit types (audit-type-manager:read)

  • Read funding sources (funding-source:read)

  • Read groups (group-manager:read)

  • Read service areas (service-area-manager:read)

  • Read service conditions (service-condition-manager:read)

  • Read taxonomy (taxonomy:read)

❌ CANNOT DO:

• Create, update, or delete attributes

• Create, update, or delete audit types

• Create, update, or delete funding sources

• Create, update, or delete groups

• Create, update, or delete service areas

• Create, update, or delete service conditions

• Create, update, or delete taxonomy terms

• Manage users

• Manage external agencies

• Manage annual updates (only change requests)

• View personal statistics

Use Case:

• Primary role for resource curators who edit resources

• Can create/update/delete resources but cannot modify system configuration

• Can manage tasks and participate in annual updates

---

3. Superadmin

✅ CAN DO:

• EVERYTHING

• Bypasses all permission checks

• Has superadmin scope which grants unlimited access

• Can access any endpoint regardless of scope requirements

❌ CANNOT DO:

• Nothing - complete system access

Use Case:

• System superusers

• Emergency access

• Development/testing

• Highest level of access

---

Permission Scope Reference

Resource Operations

• resource:create - Create new resources

• resource:read - View resources

• resource:update - Edit existing resources

• resource:delete - Delete resources

User Management

• user-manager:create - Add new users

• user-manager:read - View users

• user-manager:update - Edit users

• user-manager:delete - Remove users

Configuration Management

• attribute-manager:* - Manage attributes

• audit-type-manager:* - Manage audit types

• group-manager:* - Manage groups

• service-area-manager:* - Manage service areas

• funding-source:* - Manage funding sources

• taxonomy:* - Manage taxonomy terms

• service-condition-manager:* - Manage service conditions

• external-agency:* - Manage external agencies

Annual Update Operations

• annual-update-assignment:* - Manage annual update assignments

• annual-update-change-request:* - Manage change requests

• annual-update:manage - Full annual update management

• annual-update-stats:read - View annual update statistics

Dashboard Access

• dash-personal-stats:read - Personal statistics

• dash-recent-activity:read - Recent activity feed

• dash-resource-stats:read - Resource statistics

• dash-my-tasks:read - My tasks view

Special

• superadmin - Bypasses all permission checks

---

Role Comparison Matrix

Permission	Reader	Writer	Superadmin
Resource CRUD	❌	✅	✅
User Management	❌	❌	✅
Attribute Management	❌	👁️	✅
Group Management	❌	👁️	✅
Service Area Management	❌	👁️	✅
Funding Source Management	❌	👁️	✅
Taxonomy Management	❌	👁️	✅
Service Condition Management	❌	👁️	✅
External Agency Management	❌	❌	✅
Audit Type Management	❌	👁️	✅
Annual Update: Manage	❌	❌	✅
Annual Update: Change Requests	✅	✅	✅
Annual Update: Assignments	✅	❌	✅
Dashboard: Resource Stats	❌	✅	✅
Dashboard: Recent Activity	❌	✅	✅
Dashboard: My Tasks	❌	✅	✅
Dashboard: Personal Stats	✅	❌	✅

Legend:

• ✅ = Full access (create, read, update, delete)

• 👁️ = Read-only access

• ❌ = No access

---

Access Control Notes

1. Organization Scoping: All roles are scoped to the user's organization

2. Agency Scoping: Agency Admin and Agency Writer roles may be further scoped to specific agencies

3. Site Scoping: Users can be assigned to specific sites (additional filtering)

4. Superadmin Bypass: Superadmin role bypasses all permission checks in middleware

5. Permission Validation: All endpoints use requireScope middleware to validate permissions

---

Common Use Cases

Reader

• Annual update reviewers

• Stakeholders who need to see annual update progress

• Read-only participants in annual update workflows

Writer

• Primary resource curators

• Content editors who maintain resource data

• Users who need to create/edit resources but not configure the system

Superadmin

• System superusers

• Emergency access

• Development/testing environments

---

Implementation Details

• Permission Storage: Permissions stored as comma-separated strings in role.permission_scope

• Validation: requireScope middleware checks user's role permissions

• Superadmin Check: Special handling for superadmin scope that bypasses all checks

• Role IDs: Fixed IDs (1-6) for standard roles

• Organization Scoping: Roles belong to organizations via organizationId