Access Control in KanbanDeck

Motivation: The Need For Access Control

In your business, you work with a number of individuals such as employees, managers, vendors, clients, temp-staff, interns, etc. In most cases, not all projects/initiatives need to be accessible to everyone.

General business initiatives such as those regarding employee benefits, policy changes, or brainstorming sessions should typically be accessible to all employees. But you'd usually want to avoid including clients/vendors in such discussions.

On the other hand, specific projects may require input/feedback from clients, but not require the involvement of every employee. And, of course, in all cases, company owners and team administrators should always be able to access all of their team's projects and initiatives.

Based on interactions with users, and from our own experience at GatorStack, it was clear that KanbanDeck required a system for managing users' access to projects. Such a system would need to account for different types of users such as managers, employees, clients, vendors, etc.

Two-Tier Access Control System

In line with the above motivation, we've implemented a two-tier access control system. In KanbanDeck, per-user access can be managed on a project-specific basis, and more generally, on a team-wide basis.

Additionally, KanbanDeck has two types of projects: team-wide projects and private projects. The two-tier access control system, in conjunction with two types of projects, allows you to set up fine-grained access control patterns for ensuring that the right users have access to the right projects.

Team-Wide Access Control

On a team-wide basis, a user may have one of three access levels: guest, regular, and admin.

Guest:

• This access level is meant for outside vendors, clients, temp-staff, etc.
• Team members with 'guest' access are called 'team guests'.
• Team guests can neither create projects nor add/manage team members.

Regular:

• This access level is meant for regular employees.
• Team members with 'regular' access are called 'team regulars'.
• Team regulars can create projects, but can't add/manage team members.

Admin:

• This level is meant for business owners and administrators.
• Team members with 'admin' access are called 'team admins'.
• Team admins can create projects and invite/manage team members.

Please note that a team can have multiple team admins. Similarly, a team can have multiple team regulars and team guests.

Adding & Managing Team Members:

Team admins can go to the Users page to invite users and manage their team-wide access level. To invite a user, click the 'Invite' button, then fill and submit the invitation form. The invitee shall receive an email with a link to accept the invitation.

To manage the team-wide access level of a user, click on the menu button right next to their name, and click 'Change Access Level'. You can also use the same menu-button to deactivate (or reactivate) the access of any particular user.

Project Creation & Visibility:

Team admins and team regulars can create projects via the Projects page. To create a new project, click the 'Create Project' button. After entering a title and optional description, you can set the visibility of the project to 'Team Wide' or 'Private'.

Before discussing the difference between team-wide and private projects, we need to discuss project-specific access control.

Project-Specific Access Control

On a project-specific basis, a user may have one of three access levels: reader, regular, and admin.

Reader:

• Project members with 'reader' access are called 'project readers'.
• Project readers can view all columns, cards, and uploads.
• They cannot edit/move any card or column; they can't add/manage project members.
• They can participate in both Project Comments, and Task Comments.

Regular:

• Project members with 'regular' access are called 'project regulars'.
• Project regulars can do everything that project readers can.
• Plus, they can edit/move cards.
• But they can't edit/move columns and can't add/manage project members.

Admin:

• Project members with 'admin' access are called 'project admins'.
• Project admins can do everything that project regulars can.
• Plus, they can edit/move columns and can edit project properties.
• They can also add/manage project members.

Project Creator Becomes a Project Admin

As mentioned before, a project may be created by a team admin or a team regular. For any given project, the creator of the project becomes a project admin (for that project).

Please note that a project can have multiple project admins. Similarly, a project can have multiple project regulars and multiple project readers.

Team-Wide Vs Private Projects

Team-Wide Projects:

• Team-wide projects are meant for managing team-wide initiatives and communication.
• Thus, these projects are implicitly accessible to all team admins and team regulars, but not to team guests.
• Team admins can implicitly access the project as if they were project admins. Such implicit project access cannot be overridden by another project admin.
• Team regulars can implicitly access the project as if they were project regulars. Such implicit project access can be overridden by a project admin.
• Team guests cannot implicitly access the project, but they can be explicitly added to the project by a project admin.

Private Projects.

• Private projects are meant for managing specific/private projects that don't require the involvement of your entire team.
• Thus, these projects are implicitly accessible only to team admins, not to team regulars or team guests.
• Team admins can implicitly access the project as if they were project admins. Such implicit project access cannot be overridden by another project admin.
• Team regulars and team guests cannot implicitly access the project, but they can be added to the project by a project admin.

Adding Members To A Project

Project admins can add members to a project and manage their project-specific access level. To add project members, click on the menu button right next to the project's title and select 'Project Members' and scroll down to the 'Add Project Members' section.

Explicit Vs Implicit Access - An Example:

To make things clear, let's take an example. Consider the following team:

• Team admins: Adam, Amanda
• Team regulars: Roger, Rita, Ronald
• Team guests: Greg, Gina

Let's say Roger (a team regular) creates a team-wide project titled "Website Redesign Project" or just WRP for short.

• As Roger created the project, by default, he becomes a project admin.
• As Adam and Amanda are team admins, they can implicitly access the project as project admins.
• As Rita and Ronald are team regulars, they can implicitly access the project as project regulars.
• As Greg and Gina are team guests, they can't implicitly access the project.

We see that while Roger is a team regular, he is a project admin for WRP. Now, let's say he needs Rita's help in managing the project's columns.

• As a project admin, Roger sets Rita's project-specific access level to 'admin'.
• Now, while Rita is a team regular, she too is a project admin for WRP.

Further, let's say that WRP doesn't really require much involvement from Ronald.

• Hence Roger (a project admin) sets Ronald's project-specific access level to 'reader'.
• Now, while Ronald is a team regular, he is only a project reader for WRP.

Further yet, let's say that Roger needs to heavily collaborate with Greg, an outside developer they've contracted for managing their website.

• Hence, Roger (a project admin) adds Greg to the project with project-specific access level 'regular'.
• Now, while Greg is a team guest, he is a project regular for WRP.

Questions?

The two-tier access control system described above may feel a bit tricky at first. But in time, one easily gets accustomed to it. If you have any questions, please feel free to email [email protected]. We'll be happy to help.