Configurable user roles.
Vidas
Marie-Anne Herremans MarcoB Alexis Hargrave Brad S Konia Till Henning Lambrey Renaud Joe Trodler we are working on the following concept and I would like to get your input:
We are planning to change Teamhood roles and licensing structure to offer more flexibility and variety of use case specific access around the system.
- We will allow having as many Viewer licenses as you need (users who can only see boards/items and write comments or attach files. Ideal for inviting your clients to Teamhood for progress reporting and feedback.
- We will introduce a new license/role called external collaborator. It will be slightly less powerful than Limited collaborator (cannot create new items, cannot be assigned as watcher), but you will be able to purchase as many of those as you need at a fraction of full user license cost. Ideal for subcontractors.
- We will allow making any view private (board, folder, page, report)
- We will allow making any item field private, just not sure which way is the best:
A) Private field by role (admin, collaborator, reader, etc.) this way, it's easier to manage, but not that robust (every time you add users to workspace, you just need to assign a role)
B) Private field by user (John, Mary, Peter, etc.) this way it's more robust/flexible, but a bit harder to manage (every time you add users to workspace, you might need to add them to private fields or boards)
L
Lambrey Renaud
Hello Vidas, if you want to keep the current roles approach, here is what I would need:
Administrator => good as it is
Project Manager => full control on projects as needed, can view boards (KPIs, workload, etc)
Collaborator => can change item assigned, can read entire planning
Limited collaborator=> can change item assigned, no view on planning
Reader => can only read available plannings in workspace, no access to anything else
Ideally, I also would like to select what users can see, i.e. plannings or boards in the different workspace.
Vidas
Lambrey Renaud: this is super helpful, thank you!
Joe Trodler
Vidas Given the two choices, A) would be easier to manage once you reach a certain company size. If you have >20 users, managing that will become very tedious.
Brad S Konia
I agree that the current permissions system is way too rigid. For example, I'd like to allow a user to view all tasks in the workspace, comment on all tasks, create/edit/delete their own tasks, but no edit/delete permissions on other users' tasks. This would allow users to manage their own tasks within the workspace, but only view and comment on tasks created by other users.
It would also be nice if the permissions system was hierarchical, so we could assign permissions for folders, projects, and task lists. Each level would inherit the permissions from its parent level, but could also override the parent-level permissions.
* Ability to create custom roles
* Ability to specify the exact permissions for each role
* Ability to assign roles at the following levels: Workspace, Folder, Project, Row
* Roles would be inherited from the next higher level unless a role is overridden at a lower level. If overridden, the override would then be inherited by subsequent lower levels.
The attached screenshot from a competing platform demonstrates a possible UI for implementing custom roles.
Marie-Anne Herremans
We would like to have this feature as well. For us it doesn't work that collaborators can see all reports. We would like, based on roles, to hide all or some of them.
Vidas
Marie-Anne Herremans: from next release you will be able to place reports under board (just like pages). Then - make that board private to certain number of people. This could be a quick workaround for your case.
Marie-Anne Herremans
Vidas: That will indeed work as a quick fix for now. Thanks!
A
Alexis Hargrave
Agree with Till Henning's post below. This feature is exactly what I'm looking for!
M
MarcoB
Alexis Hargrave: yes, but it is necessary to be able to manage different permissions for users; the four current types are not enough.
M
MarcoB
I know, but management is too simple this way; It would be necessary to be able to customize the rights per user.
Vidas
Merged in a post:
Granular workspace permissions / user rights
T
Till Henning
Project participants should ideally get a license that includes reading permissions for the entire workspace, but writing permissions only for items explicitly assigned to them (more granular permission configuration).