WEBAPP PORTION

1. Navigate to components/admin_console/system_roles/system_role/system_role_permissions.tsx

2. Notice the variable sectionsList which holds all the sections. The sections and subsections are what map out to Privileges in admin_console/user_management/system_roles/{role_id}. For example, here is the user management section and subsection mapping to what you see in system console.

3. Navigate your assigned section (in this tutorial, I’ll be dealing with the experimental section) and add the corresponding subsections. Experimental has 3 sub sections so I will be adding 3 objects in the subsections array for those subsections. The subsection naming convention follows section_name_subsection_name.

4. Now you would want to scroll to the bottom of the file and add the translations for these subsections. Located your section and add the corresponding translations for subsections. The naming convention is admin.permissions.sysconsole_section_{section_name}_{subsection_name}. These will help us generate the correct translations when we run make i18n-extract in our terminal.

5. Navigate to your REDUX repo and go to the file src/constants/permissions_sysconsole.ts . Add your section keys to the RESOURCE_KEYS variable in the format

SECTION: {
  SUB_SECTION_1: 'section.subsection1',
  SUB_SECTION_2: 'section.subsection2',
  ...
}

It should look something like this

Now locate your section in the ResourceToSysConsolePermissionsTable and break it down like the following. Note that each one of these sub-sections will have its own READ and WRITE permissions that we will later be implementing. Once you’ve broken it down as shown in the left photo, you can delete the section to permission mapping as seen on the left.

6. Now you probably notice RED lines underneath the new permissions and that’s because we haven’t written those permissions yet. That is what we will do next. While we are still in the REDUX navigate to src/constants/permissions.ts . Scroll down and locate your sections permissions. In my case, the permissions I was looking for are here

You can go ahead and delete these and implement the subsection permissions we referenced earlier. This is what it should look like after the breakdown. Take notice that the red lines seen earlier in permissions_sysconsole.ts have gone away.

Image Removed

Image Added

Make sure you copy all of the READ permissions to the values.SYSCONSOLE_READ_PERMISSIONS array and all the WRITE permissions to values.SYSCONSOLE_WRITE_PERMISSIONS.

7. We want to navigate back to our WEBAPP repo and go to components/admin_console/admin_definition.jsx . This file is what defines what we see in the system console. Find the section you are dealing with in the AdminDefinition variable.

8. We will be adding isHidden and isDisabled for each section, subsection, and contents of subsection. So I will start with the over-arching section (experimental section) and only add a isHidden function to it. This section should be hidden if we don’t have any READ permission to any of it’s subsection.

9. Now for every subsection, that particular subsection should be HIDDEN if we don’t have read permission to it. Otherwise, It’s contents should be disabled if we don’t have write permission to it. Notice how the Features sub-section is hidden if we don’t have READ permission and the contents within this subsection are disabled only if we don’t have WRITE permissions to that sub section.

Do this for all of the sub-sections for the section you are dealing with.

10. In your webapp directory, run make i18n-extract to get your translations. Now would also be a good idea to do a make fix-style to fix any linting errors.

BACKEND (SERVER) PORTION

1. This part is a little bit tedious. You will want to navigate to model/permission.go. You’ll want to locate your section permission (in my case it’s PERMISSION_SYSCONSOLE_READ_EXPERIMENTAL and PERMISSION_SYSCONSOLE_WRITE_EXPERIMENTAL ) and underneath declare a new permission for each subsection. We won’t need to delete the section permission but rather will deprecated it.

   Image Added

2. You can find the assignment of the section permission and then underneath, create the assignment for all the subsection permissions. Note that the second and third parameters for the new permissions are ignored since they were once upon a time used for internationalization however that is no longer the case. It will look something like this:

Image Added

3. Take all the new permissions and add them to the respectively to SysconsoleReadPermissions and

SysconsoleWritePermissions .

Image Added

4. With this done, you can start up both your mattertmost-server and mattermost-web and use the webapp to login into your system admin account. Since your system account doesn’t have these new permissions (which we will need to write a migration for later), you can go to system roles and and assign these new permissions to a role which didn’t have them before. In my case, system manager did not have experimental permissions at all (set to No Access) and I changed to Can Edit and assigned a test user.

Image Added

After you’ve saved these settings, you can log out as your system admin account and login as your test account (test456 in my case).

5. Now when you log into your test account you should see those sections and sub sections since you will have the proper permissions.

Image Added

Yeah! It means we’ve done everything correctly up to this point!! 🎉 🎉
6. Now we need to map out our ancillary permissions. That is to map out our system console permissions to more granular permissions that allow us to do certain actions within that sub section. Note that your sub sections may not need any ancillary permissions.

So you may be asking what are ancillary permissions? Basically within a system console sub section, you may be required to do some action (eg. remove a member from a team) which requires a certain granular permission.

Why not just the system console permissions rather than having a dedicated granular permissions to do such actions? Well there are a couple reasons for this:

1. System console permissions were originally implemented only for front end validation. That is