By: Worktile Backend Developer Huo Shijie @Ajie

Worktile is one of the best enterprise project collaboration and goal management tools in the country.

This project has lasted for 9 years, writing the long history of the R&D team, and I was honored to participate in it as a “latecomer”. In the past year of research and development, most of what I did was to enhance and reconstruct the original functions. I also learned and summarized a little bit of Worktile core technology and knowledge, and this paper is one of them — permission system.

Worktile permissions is extremely complex, in development, from confusion to thorough, to the later of stopping, until eventually overcome, which many times communication with colleagues, and the summary of the many times, gradually clear, to it now I think of, the following will reveal together with you (share) the complex and compelling content.

I. Worktile Account system

Start with an overview of Worktile’s account architecture. Before that, the first to introduce the system: it is a kind of multi-tenant systems, in I contact multi-tenant systems, there are two types, one is like enterprise WeChat, fly, they have users and tenants type team/group/enterprise, so this kind of application system of account Have two user concepts, one is the users of the system, one is the team members; The other type is Worktile. The tenant type is enterprise/team/organization, which does not include individual tenants. The basic condition of all businesses is team, so the permission is also controlled by team members.

Currently, the mainstream permission design model is Access Control List (ACL), which mainly controls permissions Based on users, and role-based Access Control (RBAC) model. Both are covered in Worktile, mostly in the RBAC model, with a small number of permissions designed and controlled by the user.

In the figure above, you can see that Worktile permissions are composed of functional permissions and data permissions. The following two parts are explained in detail.

Second, design and implementation

Both functional and data permissions are divided based on the dimension of the application. Worktile’s existing apps include Projects, Tasks, Goals (OKR), messages, calendar, approvals, Web disk, and attendance…… (For more details, you can sign up for Worktile’s website for free.)

Functional authority

design

Functional permissions are designed in full accordance with the RBAC model, and the relationship is as follows:

It consists of two parts: operation rights and visible rights, which are divided by application module. Each application module has multiple permission points and visible ranges.

It is presented to the user in the background of the application – > Role Management (see figure below), where the enterprise role consists of two parts:

1. Default system roles (owner, administrator, member, and department director)

2. In the permission list (on the right of the following figure), check box indicates the permissions that the role has. The data range indicates the visible dimensions of the role in the application.

  • Operable authority

  • Visible permissions

implementation

In the traditional relational database design, there are basically three tables: role table, permission table, role permission associated table, if the verification of one or a group of permissions, is the need for three tables associated query.

Worktile, however, uses a non-relational database Mongodb + system configuration file, which is represented by a table, and the permission list is stored by the system configuration file.

  • Mongodb, naturally supports array and JSON type data storage, in the role and permission association configuration is more flexible, this link in this design, indispensable!

  • The configuration file mainly stores the permission list, which is built into the system. The front end also needs a configuration because the list displays a matching position.

Why?

Database because the main library of the entire product is Mongodb, which is the biggest reason; The choice of permission list configuration file storage, I guess because permissions are built into the system, and are fixed, change frequency is low, so there is no need to interact with the database every time, not only functional permissions, the following data permissions are also the same.

Permission list of the system

The configured data structure is roughly as follows (the following is an illustration of the structure, not the actual data) :

Key of level-1 node represents application module, key of level-2 node represents permission point, and value is description of permission. Details are as follows:

This section describes how to associate roles with permissions

All you need in Worktile is a list of roles! The structure is as follows (key fields): ID, Name, PRIVILEGES, is_SYSTEM. The core field is PRIVILEGES, which is a JSON field, as shown in the following figure.

In PRIVILEGES, the first-level node is the application module, and value is the permission value of the role. The value is a string of 0 and 1, where 1 indicates owned and 0 indicates not owned. The position of each character is the storage_position field in the configuration file. Scope is the visible scope.

use

The following three common scenarios are used based on the above implementation:

  • Get all permissions and ownership status of roles (background administration)

  • Get all permissions for a member (user permissions that the front-end needs to store after login)

  • Verify that an enterprise member has certain permissions (API requests authentication of members)

Ps: Just one example, the other two are similar.

3. Data permission

After seeing the realization of the front function permissions we should feel very simple, if the following still hold this mentality, it is really underestimate it, here I also hope you can read carefully below, experience the design, the article is longer, there is no understanding or need to discuss welcome comments.

In the design of data permissions, most industries are different, which is determined by business. Worktile’s business is very complex, so permissions are also complicated. There are many application modules in Worktile, but due to space, I will not explain all of them in this paper, but only select some typical ones to share with you.

I will explain the analysis with the Worktile core module Mission. Mission is worth mentioning because it allows users to customize the configuration to a high degree. The roles and permissions under the module are configurable (non-system roles and permissions are explained here).

Due to the complexity of the business, I have to show you from some screenshots of the interface here, if you have doubts, welcome to put forward.

Project (Project)

An overview of

A project is a collection of tasks, which are decomposed into multiple tasks. There are components in the project (presentation and management of tasks in different dimensions).

Project permissions are divided into operable permissions and visible permissions. Operable permissions

Corresponding page

Visible permissions

The rule is: public projects are visible to all members, private projects are visible only to members who have joined.

  • The visible range

  • Members that have been added to a private project

By now you should have a general idea and understanding of the project and the permissions in the project.

design

There are three parts in the design of project authority: role mode, project role and authority. The relationship between the three parts is roughly as follows:

In terms of configuration, there are global configuration and intra-project configuration. The dimension of global configuration is all projects, and project setting is an extension of global configuration. For the configuration of a single project, the configuration of the project comes from global configuration.

  • Role mode A role mode can be understood as a role group. A role mode must be created in a project. The role mode consists of the default role mode and the user-defined role mode (see the following figure).

  • Global configuration

  • Project configuration (only globally configured role mode can be selected here)

  • Project roles Project roles have built-in roles (administrator, common member, read-only member) and user-defined roles (see the following figure).

  • Global configuration

  • Project Configuration

  • The project permissions list is described in the overview, but the configuration and association are shown below.

  • Global Configuration (Role permission Association)

  • Project Configuration

implementation

As can be seen from the above design, in fact, this part of the authority is relatively simple, from the technical point of view to explain the specific implementation.

The privilege of a Project is implemented by a PrivilegeConfig PrivilegeConfig: A Project, a RoleMode, a Role and a privilege list configuration file.

Relationship:

  • A Project can be configured with multiple role modes, one-to-many, binding fields in the main table (Project) of ROLE_MODES.

  • Each Role schema can create multiple roles, one-to-many, with bound fields in the roLE_mode_ID from the table (Role).

  • Each role can be configured with multiple permissions. The relationship is one-to-many, but the permission field (permission_value) is a string of 0 and 1, where 0 indicates that the role is not owned and 1 indicates that the role is owned.

The visibility of a project is controlled by two fields: Visibility (public/private) and Members (members). When the project is public, all members are visible, and when the project is private, only the list of members is visible. Use:

  • How do I get the permission list? The server reads the system configuration file and returns it to the front end for display.

  • How do I obtain the permission list of a role? The server reads the role table to find the corresponding permission value (a string consisting of 0 and 1), sorts it according to the system configuration, and returns it to the front end, which is arranged and selected by 0 and 1.

  • How do I verify a member’s permissions? Visibility: first, determine whether the visibility is public or private. If the visibility is public, all members of the project are visible, and if the visibility is private, then determine whether the current member exists in the project member. If the operation permission is verified, read the id and role of the member from the Project table, and then find the permission value (a string consisting of 0 and 1) according to the role. Finally, map the specific single value of the permission value according to the location of the corresponding permission in the system configuration file. If the value is 1, then you have the permission, otherwise you do not have the permission!

The Task (Task)

An overview of

Task is a specific form of work content, task can describe the work content, process control, task and task between the association and derivation.

Ps: Tasks can exist on their own or in projects.

Here’s how it’s used in a real-world scenario

design

Task permissions are very different from project permissions by design. Task permissions are dominated by permissions, as shown in the following figure.

This topic describes concepts such as role mode, role, permission mode, permission, security level mode, and security level. Security mode and security level are the same as visible rights.

A common part of the project is the role model. The difference is that task roles are composed of project roles and task roles (task leader, participant, etc.), and the main design method is to control task permissions by configuring task type permissions. In another way, it is better to say that task configuration permissions are equal to task type configuration permissions.

What is a task type?

As the name implies, it is the type of task that the Worktile belongs to. The core reason why Worktile is suitable for most enterprises is the type of task, and it also supports enterprise member creation and customization.

The type of task used in practice

Note: Tasks can have only one task type

Operable authority

  • Rights Mode A rights mode is a collection of multiple rights, or a rights group. The rights include the built-in rights mode (common rights mode, software rights mode) and user-defined rights mode (see the following figure).

  • Global configuration

  • Permission configuration for task types in a project

  • Permission mode and role mode

  • Permission mode, role mode, and role association

  • Permission mode, role, and permission association

  • permissions

  • Built-in system permissions: The system defines unchangeable property permissions, such as create task, archive task, copy task…… Etc.

  • Task attribute permission: Task attributes can be configured by users, so the attributes have the attribute permission, such as changing the owner and changing the task status……

Visible permissions

The visible permissions in a task are called security levels. It consists of two parts: security mode and security level.

  • Security mode (system built-in security mode and custom security mode)

  • Security mode and Role Mode The binding between security mode and role mode indicates which roles in the security mode are visible.

  • Security mode and security level

  • Security levels and roles indicate which roles (including project roles and task roles) are visible

  • Task type and security level configuration in a project

implementation

The permissions of the task involve 9 tables and 3 configuration files.

Table and relation:

  • Task Task table, TaskType Task type table, one-to-one relationship, associated fields in the main table task_type_id Task.

  • PermissionMode: a list of permission modes. It is many-to-one based on the task type. A task type can have multiple permission modes.

  • TaskPermission: The dictionary table of task permissions is initialized to this table through the system task permissions file. The relationship with the permission mode is many-to-one. One permission mode corresponds to multiple permission items with the associated field selectable_permission. Note that this field is synchronized to the permission mode for roles to select.

  • RoleMode: RoleMode table, which has a one-to-one relationship with permission modes. One permission mode is bound to one RoleMode.

  • Role: The Role table, which is many-to-one with the Role schema table.

  • PermissionRole: PermissionRole list. It is many-to-many related to the permission mode. The permissions in this table must be selected from the permission items in the permission mode, and the roles must be selected from the roles in the role mode bound to the permission mode.

  • SecurityMode: SecurityMode table, which configures the visible permissions of tasks and initializes tasks from the system configuration file to the database. It has a one-to-one relationship with the role mode. Each SecurityMode is bound to one role mode.

  • Security: Security level table, configure the task role (including task built-in role and the role of the default role mode) of visible permissions, also from the system initialization configuration file to the database, and the task role is a one-to-one relationship, and the Security model is more of a relationship, a Security mode you can configure multiple roles.

Use logic:

Check that a member has operation rights for a task

Checks whether a member has visible permissions on a task

Four,

Permissions mentioned in this paper are generally stored in configuration files in accordance with the RBAC model. The advantages are light weight, less complex operations related to tables, and less data permissions to interact with the database in mission module:

  • The operation rights of a project are role group + Role + Permission

  • The project visibility permission binding is a member

  • The permission of a task is permission group + Permission + Role group + role to control task attributes

Thank you very much for reading this carefully. If you have any questions or better comments, please feel free to communicate with us. Looking forward to more Revelations, and keep watching Worktile!

Welcome to official Worktile