Whether you're managing a multi-tiered hierarchy of client or contractor projects, creating restricted areas to hold sensitive data, or just trying to set up a project for you and your teammates to work in, you need to understand how permissions work, and how permissions inheritance affects projects and modules. This week we're going to look at TIMU's permissions structure, from the network all the way down to each individual task and file.
TIMU uses a cascading permissions structure, where security settings can trickle down from the network level, to individual projects, to project modules, to individual items like tasks and files. Understanding this structure is key to working in TIMU; improper use of permissions settings can result in team members not being able to join projects after being invited, or giving access permissions to hundreds of users at once, or generating large numbers of unnecessary notifications.
In every part of TIMU, a user has a specific set of permissions. There is a default level specified at the network level, which can be inherited and modified by projects, then by modules, then by individual items such as tasks, discussions, and files. Most commonly, you'll see these permission levels used to control access at the project level. There are several levels of permissions:
- Owner: has full access to all areas of the project, and the project settings pages.
- Trusted Contributor: has access and can add to all areas of a project, and is able to rename tasks and edit view settings.
- Contributor: has access and can add to all areas of a project, but cannot adjust any project settings or security.
- Commenter: can view and comment on items within a project, such as tasks and files, and contribute to discussions, but cannot create content such as tasks or TIMU Write documents.
- Reader: can view the project but cannot contribute any material or comments.
Sometimes you need to restrict access to TIMU content, or upgrade another user's permissions level. You have the option of changing permissions for the entire project, for specific modules, or even for individual items in a module.
You must have owner-level permissions to change security settings.
You can adjust permissions, remove members from a project, or invite new users from the project settings page. On the security tab, you'll see a list of project members and their roles within the project.
To invite new members to the project, click on 'Invite People'. To change project members’ permissions, use the dropdown next to their names to select a new role. To revoke a user's permissions in the project and all of its sub-projects, click the trash can icon. This is really important and bears repeating- removing a user from the project prevents them from accessing any of its sub-projects!
Modules inside a project inherit the project's security settings by default- that is, the permissions you set for the project will automatically be applied to all the modules it contains. Examples of why you may want to break this inheritance include setting up private discussion modules for different groups of users or hiding modules from users who need 'pass-through' permissions to access a subproject but shouldn't see the module contents.
To break permissions inheritance for a module, you can click on the security tab from the module's settings page. When you click 'Stop Inheriting', you have the option of preserving the current set of users and permissions as a starting point, or removing everyone but yourself so you can start setting new permissions from scratch.
After breaking permissions inheritance, you will see a dropdown next to each member’s name that you can use to set new, module-specific permissions. To remove a user from the module entirely, click on the trash can icon next to the user’s name.
Just like modules normally inherit from projects, items inside a module will inherit the module's security settings by default. Breaking permissions inheritance for individual items is useful when you want to restrict who can read or edit a document, when you want to have a private discussion with a few teammates, or when a task contains sensitive information that shouldn't be accessible to all project members.
Permissions for individual tasks, files, discussions, or other items can be edited from the item's security tab, which is marked by a lock icon in the item's details. When you click 'Stop Inheriting', you have the option of preserving the current set of users and permissions as a starting point, or removing everyone but yourself so you can start setting new permissions from scratch.
After breaking permissions inheritance, you will see a dropdown next to each member’s name that you can use to set new, item-specific permissions. To remove a user from the item entirely, click on the trash can icon next to the user’s name.
By now you should have a good enough grasp of TIMU permissions to set up and manage your project. To recap:
- TIMU's permissions structure is based around inheritance, where permissions in the parent item are automatically applied to its children.
- You can break inheritance and specify a custom set of permissions at any level of the hierarchy, from a project to an individual item.
There's still plenty more for us to cover- stay tuned for part 2 of this series, where we'll look at more advanced permissions structures and use cases!
Subscribe to TIMU Blog
Get the latest posts delivered right to your inbox