Understanding Permissions
Permissions in Skand control who can access what resources and what they can do with them. For example, if a User (who) has Edit access (what they can do) to a Folder (what resources), they can upload, download, and delete files within that folder.
Who Can Be Granted Access?
In Skand, access can be granted to:
User: An individual person using Skand.
User Group: A collection of users who share similar permissions. This makes it easier to manage access for multiple people at once.
Role: A predefined set of permissions. Roles act like templates, allowing you to quickly assign the same permissions to multiple users or user groups.
Pro tip: To simplify permission management, we recommend using User Groups and Roles. This allows you to group users and assign permissions to the group or role, rather than managing each user individually:
A User Group can also be assigned a Role.
A User can be assigned to a User Group and a Role.
Understanding Access Levels
Access levels in Skand are tailored to each type of resource. This means the available permission levels might differ depending on whether you're working with a project, a folder, or another resource. Common access levels include:
Admin: Full control. An Admin can do anything with the resource.
Edit: Can make changes. Users with Edit access can modify the resource.
Read: Can view but not modify. Users with Read access can see the resource but can't make any changes.
Note: Currently, only Account Admins have access to the Manage page where roles and permissions are configured. We're planning to expand this functionality in the future to allow designated users who have Admin access to manage permissions for specific resources.
Resource Types and Permissions
Skand offers granular control over permissions, allowing you to set them for broad categories (Global Resources) or specific items (Individual Resources).
Global Resources
These permissions apply to broad categories of resources:
All resources: Account admins who have access to manage all resources.
All project groups: Permissions applied at this level affect all project groups.
All projects: Permissions applied at this level affect all projects.
All folders: Permissions applied at this level affect all folders.
Individual Resources
These permissions apply to specific items:
Specific project groups: Control access to individual project groups.
Specific projects: Control access to individual projects.
Specific layers: Control access to individual layers.
Specific folders: Control access to individual folders.
Permissions for Different Resources
Project Group and Project Permissions
Project Groups act as containers for Projects. Having Read permission to see a Project Group automatically grant you access to read the Projects within it. However, if you have Restricted permissions to a Project Group, you'll see the Project Group listed, but you won't be able to see any of the Projects it contains. You'll need specific permission for each Project you want to access.
This allows you to control which teams or individuals can see which projects within the same project group, keeping work separate.
Project and Layer Permissions
Similar to Project Groups and Projects, having Read permission to a Project means you can see its Layers as well. However, if you have Restricted access to a Project, you'll see the Project listed, but you won't see any of its Layers. You'll need specific permission for each Layer.
This is particularly useful when different teams work on different aspects of a project. For example, if two engineers are working on separate annotation groups (Layers), this ensures they only see and interact with their assigned Layers.
Report Permissions
Reports in Skand are based on specific projects. If you have Read permission for a project, you can view all reports created from that project. If you have Edit permission for the project, you can also create new reports based on it.
Folder Permissions
Permissions for folders work hierarchically. If you have a certain permission level for a parent folder, you automatically have at least that same level of permission for all its child folders and files.
Understanding Permission Hierarchy
Your users' final permissions are like a "best of all worlds" scenario. They get the highest level of access granted to them through any of these channels:
Their individual permissions
Their user group's permissions
Their role's permissions
For example, if Edison has:
Read access individually
Edit access through his user group
No direct role assignments
Edison will effectively have Edit access, since it's the highest permission level granted through any channel.
When to Use User Groups and Roles
Setting up your permissions structure the right way can save you time and keep things organized. Here’s the best approach:
Start with User Groups
Begin by organizing your users into logical groups based on their needs and responsibilities. User groups are your foundation - they're simple to set up and give you immediate control over permissions. For example, you might create groups like:
Engineering Team
Project Managers
External Contractors
Introduce Roles When You See Patterns
As your organization grows, you'll likely notice patterns in how you assign permissions. This is your cue to introduce roles. Think of roles as permission templates that you can quickly apply to multiple groups or users.
Let's say you notice these user groups all have identical permissions:
Engineering Team: Read access to all projects
Project Managers: Read access to all projects
External Contractors: Read access to all projects
Instead of managing these identical permissions separately, you can create a "Project Reader" role and assign it to all three groups. This saves time and reduces the chance of inconsistencies.
Keep It Simple and Scalable
Start with user groups and introduce roles only when you spot clear, repeating patterns in permissions. This approach keeps your permissions structure clean, manageable, and ready to scale as your organization grows.