Understanding Permissions and Member Roles

Mosic uses a comprehensive role-based permissions system to control who can access and modify content within workspaces. This guide explains how permissions work, what each role can do, and how to manage access effectively.

Overview

What is the Permission System?

The permission system in Mosic controls:

• Who can access workspaces and their content
• What actions users can perform (create, read, write, delete)
• Which entities users can interact with (spaces, projects, lists, tasks, events)
• How permissions cascade through the organizational hierarchy

Why Permissions Matter

Proper permission management ensures:

• Data Security: Protect sensitive information from unauthorized access
• Collaboration Control: Share work with team members appropriately
• Workspace Isolation: Maintain separation between different workspaces
• Compliance: Meet organizational security requirements
• Team Structure: Reflect organizational hierarchy in access levels

Workspace Membership

Becoming a Workspace Member

Users become workspace members through:

1. Workspace Creation: The creator automatically becomes an Admin member
2. Invitation: Admins or Editors can invite users via email

Workspace Isolation

Key Security Feature: Mosic enforces strict workspace isolation

• Users can only access workspaces they are members of
• Data in one workspace is completely isolated from other workspaces
• Workspace members cannot see or access other workspaces unless explicitly added
• Each workspace operates as a separate, secure environment

Member Roles

Mosic provides five distinct roles with different permission levels. Each role is designed for specific use cases and responsibilities.

Admin

Primary Role: Full workspace management and content control

Permissions:

• All Create/Read/Write/Delete permissions across all entity types
• Workspace Management: Edit workspace settings and configuration
• Member Management: Add, remove, and modify member roles
• Subscription Management: Manage billing and subscriptions
• Full Comment Access: Create, edit, and delete all comments
• Share Control: Manage sharing settings
• Update Members: Modify member lists on spaces, projects, and lists
• Update Assignees: Assign and reassign tasks

Typical Users:

• Workspace owners
• Team leaders
• Department heads
• Project managers with full authority

Use Cases:

• Creating and managing the overall workspace structure
• Controlling who has access to different areas
• Managing team members and their roles
• Overseeing all projects and tasks

Editor

Primary Role: Content creation and team collaboration management

Permissions:

• Create/Read/Write/Delete: Full access to spaces, projects, lists, and tasks
• Member Management: Can update member lists on spaces, projects, and lists
• Workspace Settings: Can edit workspace settings (but cannot delete workspace)
• Comment Management: Create and edit comments, delete own comments only
• Share Control: Manage sharing settings
• Update Assignees: Assign and reassign tasks
• Tag Management: Full access to create, edit, and delete tags
• Event Management: Full access to create, edit, and delete events

Limitations:

• Cannot delete workspaces
• Cannot delete comments created by others (except Admins)
• Cannot manage workspace invitations

Typical Users:

• Project coordinators
• Team leads
• Content managers
• Senior team members

Use Cases:

• Managing projects and their structures
• Creating and organizing tasks and lists
• Coordinating team activities
• Setting up project frameworks

Member

Primary Role: Active contribution and task execution

Permissions:

• Create/Read/Write: Full access to create tasks, comments, and events
• Task Management: Create, edit, and update tasks
• List Writing: Can write to task lists (modify existing lists)
• Limited Delete: Can delete only tasks and comments they created
• Comment Access: Create and edit comments, delete own comments only
• Tag Management: Create, read, and write tags (cannot delete)
• Event Management: Create and edit events, delete own events only
• Update Assignees: Assign and reassign tasks

Limitations:

• Cannot create, edit, or delete spaces
• Cannot create, edit, or delete projects
• Cannot create or delete lists (can only write to existing lists)
• Cannot delete tasks created by others
• Cannot manage members or workspace settings

Typical Users:

• Team members
• Contributors
• Collaborators
• Task executors

Use Cases:

• Working on assigned tasks
• Creating new tasks in existing lists
• Collaborating through comments
• Tracking work progress

Viewer

Primary Role: Read-only access with commenting ability

Permissions:

• Read: Can view all content in spaces, projects, lists, and tasks
• Comment: Can create and participate in discussions
• Limited Editing: Cannot modify any content

Limitations:

• Cannot create, edit, or delete any entities
• Cannot modify tasks, lists, projects, or spaces
• Can only read tags and other metadata
• Cannot manage members or settings

Typical Users:

• Stakeholders
• Observers
• Clients (limited access)
• Auditors
• Read-only collaborators

Use Cases:

• Monitoring project progress
• Reviewing task status
• Providing feedback via comments
• Tracking team activities

Guest

Primary Role: Minimal access for external collaborators

Permissions:

• Read: Can view content they are explicitly granted access to
• Comment: Can participate in discussions

Limitations:

• Cannot create, edit, or delete any entities
• Cannot modify any content
• Access is typically restricted to specific items
• Most limited role in the system

Typical Users:

• External contractors (limited scope)
• Temporary collaborators
• External stakeholders (minimal access)
• Trial users

Use Cases:

• Reviewing specific projects or tasks
• Providing external feedback
• Limited-time collaboration
• Restricted client access

Note: Guest users are free (not counted in paid user limits) but may have separate guest ratio limits based on your subscription plan.

Permission Levels Explained

Action Types

Create

• Add new entities (spaces, projects, lists, tasks, events, comments)
• Initialize new content within the workspace
• Set up organizational structures

Read

• View existing content and details
• Access task information, project data, and workspace content
• Monitor activities and progress

Write

• Modify existing entities
• Update task details, project settings, and list configurations
• Edit content and metadata

Delete

• Remove entities permanently
• Delete tasks, comments, or other items
• Clean up outdated or unnecessary content

Comment

• Create discussions on tasks and other entities
• Participate in team conversations
• Provide feedback and updates

Share

• Manage sharing settings for entities
• Control who can access specific content
• Generate sharing links

Update Member

• Modify member lists on spaces, projects, and lists
• Add or remove members from specific entities
• Manage team access at different levels

Update Assignee

• Assign tasks to team members
• Reassign tasks as needed
• Manage task ownership

Entity-Specific Permissions

Workspace Permissions

Notes:

• Workspace Owner (creator) has all permissions regardless of role
• Only Admin role can create workspaces
• Members, Viewers, and Guests have read-only workspace access

Space Permissions

Notes:

• Editors have full control over spaces
• Members and below have read-only space access
• Space membership is inherited from workspace membership

Project Permissions

Notes:

• Editors have full control over projects
• Members and below have read-only project access
• Project membership is inherited from parent space or workspace

List Permissions

Notes:

• Members can write to lists (modify existing lists) but cannot create or delete them
• List membership can be explicitly set beyond workspace membership
• Enables fine-grained task list access control

Task Permissions

Notes:

• Members can delete only tasks they created (owner check)
• Task visibility follows list membership
• Assignees have special access to tasks assigned to them
• Editors cannot create comment documents directly, but can comment through the interface

Comment Permissions

Notes:

• Only Admins can delete any comment
• Editors and Members can delete only their own comments (owner check)
• All roles can read comments

Event Permissions

Notes:

• Events are personal to the creator (owner or created_by)
• Members can delete only events they created
• Event visibility is tied to workspace membership and ownership

Tag Permissions

Notes:

• Members can create and modify tags but cannot delete them
• Tags can be applied to multiple entity types
• Tag links (associations) follow similar permission patterns

Invitation Permissions

Notes:

• Only Admins and Editors can manage invitations
• Members and below have no invitation access
• Invitation management is a workspace-level privilege

Permission Inheritance

How Permissions Cascade

Permissions in Mosic follow an inheritance model through the organizational hierarchy:

Workspace Membership
    ↓
Space Access (inherited from workspace)
    ↓
Project Access (inherited from space or workspace)
    ↓
List Access (inherited from project, space, or workspace + explicit members)
    ↓
Task Access (inherited from list + assignees)

Inheritance Rules

1. Workspace Membership is Required: Users must be workspace members to access any content
2. Implicit Space Access: Workspace members automatically access all spaces unless restricted
3. Explicit List Members: Lists can have specific member lists beyond workspace members
4. Task Assignees: Assigned users gain task access even with empty list membership
5. Owner Privileges: The workspace owner has full access regardless of role

Special Cases

Workspace Owner

• The user who created the workspace
• Has full Admin permissions regardless of assigned role
• Cannot be removed or downgraded
• Identified by workspace_owner field

Task Assignees

• Users assigned to tasks gain access to those specific tasks
• Access granted even if not a list member
• Enables delegation without full list access
• Assignee can read, write, and update the task

Explicit Members

• Spaces, Projects, and Lists can have explicit member lists
• Explicit members are added beyond workspace membership
• Enables fine-grained access control
• Commonly used for sensitive projects or restricted lists

Manager Field

• Spaces and Projects can have a designated manager
• Manager field is informational, not a permission level
• Manager role is separate from member roles
• Used for organizational hierarchy and ownership

Managing Permissions

Adding Workspace Members

Who Can Add Members:

• Workspace Admins
• Workspace Editors

How to Add Members:

1. Direct Addition (Admin/Editor):

   • Navigate to Settings → Workspace Settings → Members
   • Click “Add Member” button
   • Enter user email address
   • Select role (Admin, Editor, Member, Viewer, Guest)
   • Click “Add” to send invitation

2. Via Invitation (Admin/Editor):

   • Navigate to Settings → Workspace Settings → Invitations
   • Click “Create Invitation” button
   • Choose invitation type (single-use or multi-use)
   • Select default role for invited users
   • Generate invitation link
   • Share link with users

Subscription Limits:

• Member additions are subject to subscription limits
• Paid user limit based on plan (max_users)
• Guest ratio limit based on paid users (guests = paid_users × guest_ratio)
• Admins receive warning when approaching limits
• Additions blocked when limits are exceeded

Changing Member Roles

Who Can Change Roles:

• Workspace Admins
• Workspace Editors (with update_member permission)

How to Change Roles:

1. Navigate to Settings → Workspace Settings → Members
2. Find the member in the list
3. Click the role dropdown next to their name
4. Select new role (Admin, Editor, Member, Viewer, Guest)
5. Confirm the change

Role Change Effects:

• Changes take effect immediately
• User’s access is updated in real-time
• No need to log out/log in
• Permission checks happen on each action

Role Change Restrictions:

• Cannot change the Workspace Owner’s role
• Cannot remove the Workspace Owner from workspace
• Must maintain at least one Admin per workspace (recommended)

Removing Members

Who Can Remove Members:

• Workspace Admins
• Workspace Editors (with update_member permission)

How to Remove Members:

1. Navigate to Settings → Workspace Settings → Members
2. Find the member in the list
3. Click “Remove” or disable toggle next to their name
4. Confirm the removal

Removal Effects:

• User immediately loses access to workspace
• User can no longer view any content in the workspace
• User’s previous contributions remain intact
• User remains assigned to tasks (as historical record)
• User can be re-added later if needed

Cannot Remove:

• Workspace Owner (creator) cannot be removed
• Cannot remove yourself if you’re the only Admin

Managing Space, Project, and List Members

Who Can Manage:

• Workspace Admins
• Workspace Editors
• Users with update_member permission on the specific entity

How to Manage:

1. Space Members:

   • Open Space detail page
   • Navigate to “Members” or “Settings” tab
   • Add or remove members explicitly
   • Set roles at space level (if supported)

2. Project Members:

   • Open Project detail page
   • Navigate to “Members” or “Settings” tab
   • Add or remove members explicitly
   • Control project access independently

3. List Members:

   • Open List detail page
   • Navigate to “Members” or “Settings” tab
   • Add or remove members explicitly
   • Enable fine-grained task access control

Why Use Explicit Members:

• Restrict sensitive projects to specific team members
• Create private lists for specific collaborators
• Delegate tasks without full workspace access
• Control access to confidential information

Security Best Practices

General Guidelines

1. Principle of Least Privilege: Assign the minimum role necessary for users to accomplish their work
2. Regular Audits: Review workspace members and their roles periodically
3. Remove Inactive Members: Disable or remove members who no longer need access
4. Use Guest Role Wisely: Reserve Guest role for external, temporary collaborators
5. Limit Admin Access: Keep the number of Admins to a minimum (typically 1-3 per workspace)

Role Assignment Recommendations

Assign Admin when:

• User needs to manage workspace settings
• User needs to manage billing and subscriptions
• User is a team leader or department head
• User needs full control over member management

Assign Editor when:

• User needs to create and manage projects
• User needs to set up organizational structures
• User is a project coordinator or manager
• User needs to manage team member access at project level

Assign Member when:

• User is an active contributor
• User needs to create and work on tasks
• User is a team member executing work
• User does not need structural management access

Assign Viewer when:

• User needs to monitor progress only
• User is a stakeholder requiring visibility
• User should not modify any content
• User needs read-only access with commenting

Assign Guest when:

• User is an external collaborator (short-term)
• User needs minimal, restricted access
• User is a client requiring limited visibility
• User should not have full member privileges

Protecting Sensitive Information

1. Use Explicit Members: Add specific members to sensitive projects or lists
2. Limit Workspace Access: Keep workspace member count appropriate
3. Regular Role Reviews: Audit member roles quarterly
4. Remove External Access: Remove Guest users when collaboration ends
5. Separate Workspaces: Use different workspaces for different security levels

Subscription and Billing Security

1. Limit Billing Access: Only Admins can view billing information
2. Monitor Member Count: Track paid users against subscription limits
3. Control Guest Ratio: Ensure guest users stay within plan limits
4. Review Invitations: Regularly audit active invitations
5. Subscription Ownership: Ensure workspace owner manages subscription

Troubleshooting

Common Permission Issues

”Access Denied” or “Permission Denied”

Possible Causes:

• User is not a workspace member
• User role does not have required permission
• User trying to access another workspace
• User trying to delete another user’s content

Solutions:

• Verify workspace membership
• Check user role and required permissions
• Confirm correct workspace is selected
• Verify ownership for delete operations

”Cannot Add Member - Limit Reached”

Possible Causes:

• Subscription user limit exceeded
• Guest ratio limit exceeded
• No active subscription

Solutions:

• Upgrade subscription plan for more users
• Review current member count
• Remove inactive members
• Confirm subscription is active

”Cannot Delete Item”

Possible Causes:

• User lacks delete permission for entity type
• User is not the owner (for comments, tasks, events)
• User role is Member trying to delete others’ content

Solutions:

• Verify user has delete permission
• Check item ownership
• Request Admin to delete if needed
• Upgrade user role if appropriate

Member Cannot See Content

Possible Causes:

• User is not a workspace member
• Content is in a space/project with restricted members
• User role is too restricted
• Cache or session issue

Solutions:

• Verify workspace membership
• Check space/project member list
• Verify user role has read permission
• Ask user to log out and log back in
• Clear browser cache if needed

Cannot Modify Workspace Settings

Possible Causes:

• User role is Member, Viewer, or Guest
• User is not Admin or Editor
• Workspace owner permissions required

Solutions:

• Verify user role is Admin or Editor
• Contact workspace owner for access
• Request role upgrade if needed

Frequently Asked Questions

Who can create workspaces?

Any user can create a new workspace. The creator automatically becomes the workspace owner with Admin role. All users with accounts can create unlimited workspaces (subject to platform limits).

Can I have different roles in different workspaces?

Yes. Your role is specific to each workspace. You can be an Admin in one workspace and a Member in another workspace. Roles do not transfer between workspaces.

What happens to content when a member is removed?

When a member is removed:

• Their created content remains in the workspace (tasks, comments, etc.)
• Their name remains attached to their contributions (historical record)
• They can no longer access or modify any workspace content
• Task assignments remain for historical tracking
• Ownership remains unchanged on their items

Can I change the workspace owner?

The workspace owner is the user who created the workspace and cannot be changed through the UI. The owner has permanent Admin access and cannot be removed. This ensures workspace control and accountability.

Do assigned users need to be list members?

No. Users assigned to tasks automatically gain access to those specific tasks, even if they are not explicit list members. This enables task delegation without granting full list access.

What is the difference between Member and Viewer roles?

Member: Active contributor who can create and modify tasks, comments, and events. Can delete own content.

Viewer: Read-only observer who can view content and comment, but cannot create or modify anything.

Use Member for team members actively working on tasks. Use Viewer for stakeholders monitoring progress.

Can Guests access everything in the workspace?

No. Guests have the most restricted access level. They can only view content they are explicitly granted access to and participate in discussions via comments. Guests cannot create or modify any content.

How do subscription limits affect permissions?

Subscription limits control:

• Maximum paid users (Members, Editors, Admins) based on plan
• Guest ratio (guests = paid_users × guest_ratio from plan)
• Adding members is blocked when limits are reached
• Current members retain access if limits exceeded later

Admins receive warnings when approaching limits. Upgrade subscription to add more members.

Can I have private projects within a workspace?

Yes, using explicit member lists. While all workspace members can see the project exists, you can restrict who can access content by:

1. Setting explicit members on the project
2. Limiting list membership to specific users
3. Using Member or Viewer roles for restricted access

This enables sensitive projects within a shared workspace.

What permissions do I need to invite new members?

You need Admin or Editor role to invite new members to the workspace. Members, Viewers, and Guests cannot send invitations or add users to the workspace.

How do I know what my role is?

To check your role:

1. Navigate to Settings → Workspace Settings → Members
2. Find your name in the member list
3. Your role is displayed next to your name

Alternatively, if you cannot access workspace settings, you likely have Member, Viewer, or Guest role.

Can Editors delete workspaces?

No. Only the workspace owner (creator) can delete workspaces. Editors can modify workspace settings but cannot delete the workspace itself. This prevents accidental deletion.

Related Documentation

• Introduction to Mosic - Understanding Mosic concepts and features
• Workspaces - Managing workspaces and switching between them
• Settings - Configuring workspace settings and preferences
• Spaces - Organizing work with spaces and members
• Projects - Managing projects and team collaboration
• Lists - Creating and managing task lists with members
• Tasks - Creating and assigning tasks to team members

Summary

Understanding Mosic’s permission system enables you to:

• Control access appropriately for your team structure
• Secure sensitive information with role-based restrictions
• Collaborate effectively by assigning appropriate roles
• Maintain security with workspace isolation and permission inheritance
• Scale your team by managing members and their access levels

Key Takeaways:

• Five roles (Admin, Editor, Member, Viewer, Guest) with distinct permissions
• Workspace membership required for all access
• Permissions cascade through organizational hierarchy
• Owner has permanent full access
• Regular audits and least privilege principle ensure security

For additional help with permissions and security, visit our Getting Help page or contact support at support@mosic.pro.