The TeamSite Permissions System

Everything you always wanted to know about… the TeamSite Permissions System

The TeamSite Permissions System initially seems pretty straightforward. However, once you’ve finished designing and implementing your own permissions system you can end up hitting a wall, simply because no-one had told you about certain crucial details. I will try to provide you with an overview of this system (based on version 6.4) and will then give you some examples and hints that will help give you a better understanding of how it works .

Ready? Then let’s dive into the Permissions System together.

Permissions per folder

The first place where you will be able to set permissions is within the TeamSite itself. In the CCPro, go to the properties of any file or folder and then click on permissions.  You will be given a list of groups and a Full Control option (RWXDPO) to choose from. You can alter the file or folder’s permissions or even add permissions. At the bottom, you will see an “Apply Inherited Permissions” link, which allows the file/folder to inherit  permissions from its parent folder. After clicking on the link, a new list of permissions will be created below the existing ones and it will be clearly indicated that this is a set of inherited permissions. This part is quite clear, so I do not think any further explanations are required. At some point, however, you will discover that this does not cover all eventualities.


Workarea Owner

Each workarea has an Owner. The Owner can be defined in the workarea properties. You have two options: a single user or a group. The accepted best practice is to always use a group, as this will allow you to change  to a different set of users without disrupting the workarea settings. But that’s not all. In the next few sections I will give you some other pointers which prove that choosing the “group” setting is best. But first, we need to take a closer look at other parts of the system.


User Administration

In the Administration panel there is a User Management tab. It contains a list of users along with some basic information. Double-clicking on a user gives you access to more detailed information. There is a bullet list of 2 basic points: ‘User has specific roles and functions’ and ‘User is a Platform Master (all roles, functions, and access to Administration)’.  The former gives you a user with permissions that can be organized by group assignments, along with other options, whilst the latter gives you a user who has access to everything (at least in theory). Below you will find a button to assign a user to a group, allowing you to put them in groups from 2.1 and 2.2. That’s the basics covered. Now onto the more complex points.

The submit.cfg file

In the TeamSite folder (located in local\config) there is a very important file called submit.cfg. This file turns everything we talked about in point 2 on its head. It contains a list of regular expressions and sets of pairs (user/group and permission pawel4type) that are applied if the expression is invoked. This file is used when a user makes a submit. TeamSite checks each file on submitted files list to see if any of the regular expressions match that file (path + filename). The first match is applied, with the related set of permissions from submit.cfg being used to overwrite the file’s current permissions in TeamSite. That’s right. It will overwrite everything you set up in 2.1 (normal and inherited).  This is why you should not rely on inherited permissions if the file will ever be submitted.

Working on Y:\

TeamSite mounts on the Y:\ disc, which allows you to move files from other sources more easily. I do not think I need to convince anyone that this is a very useful option. In theory, it uses the same system as CCpro. If you configure yourself as a Platform Master in point 2.3, you will probably be under the impression that you are able to do everything here. But no. That’s not how it works. The authors decided that this wouldn’t be taken into account on Y:\. However, configuring yourself as belonging to 2 groups will solve this problem. First of all, you need to belong to the Owner group for the workarea you would like to work on. Secondly, you need to belong to the group that has write access to that particular file/directory. Ensuring you belong to these 2 groups should solve your problem.


Other tips and tricks

  • Submit.cfg does not always work.

Yes, that’s right. It will only be run if the file has been changed (I have no idea why).

  • Setting up permissions for new files.

In my opinion, the best way of doing things is to use the submit.cfg file when setting up permissions for a new file. Simply make sure that all the settings are configured as you wish and then submit the file. It is better not to bother setting permissions in the CCPro as they will be overwritten by the first submit.

  •  If you would like to create a user that is not a master user but has write access to certain parts of the workarea, do not forget to add that particular user to the group that owns the workarea in question. If you don’t, the user will not be granted write access.
  • Group permissions inheritance

By default, if one group is a part of second group, it does not inherit its permissions. You will need to change this yourself in one of the settings files. This is definitely worth doing, as it clarifies the permissions system.


Good luck!

Yes. You will need it while working on the TeamSite Permissions System.  I will continue to update this guide with even more pointers that should help you. Hopefully they will.