Group Manager Permission
I received several inquiries about the difference between the position “Group Manager” and the role “Manager”. Ok, here is the run-down.
The position and the role are two different things and, yes, in the sample data I shouldn’t have named them the same.
The Group Manager Position
You can make a user member or manager of a group. Let’s call that the “position” a user has in a group.
Making someone a manager of a group has an effect on the notifications that user gets for events in the calendars of that group. Most of all, that relates to the approval requests for absence types that are marked with “Approval required”.
The group manager can also edit his groups and assign/remove members from them.
The group manager/s of a group will receive an absence approval request email for those absence types when regular member submit them. The group manager is then supposed to edit the calendar of the requesting user and when he saves that calendar again, the absence type is approved. But in order to be able to edit the calendar of that user, the group manager also needs to have the permission to do so.
But how? Just being the group manager does not grant the permission to edit other user’s calendars. That is what a role in TCN is for, granting permission to do things.
The Manager Role
In TCN’s sample data there is a role called “Manager”. Again, apologies to have named it that way because it adds to the confusion with the position of a group manager. So, for the sake of this documentation let’s assume the role is called “Boss”.
Let’s say Mickey Mouse is group manager of the group Disney. He gets an absence approval request from Donald Duck but he notices that he cannot edit his calendar. Why? Because Mickey Mouse is not in a role that allows him to edit calendars of other users in his group.
There are two permissions that would allow him to do so:
Calendar (Edit Group as Member or Manager)
Calendar (Edit Group as Manager)
Mickey Mouse is not in any role that has either of those permission. Let’s do that.
The currently selected Permission Scheme shows this:
OK, so the role “Boss” is allowed to edit calendars of users that the role holder is group manager of. Let’s assign that role to Mickey Mouse.
On the Account tab of Mickey’s user profile, select the role “Boss”.
That will check the following when Mickey Mouse tries to edit Donald Duck’s calendar:
Is Mickey Mouse in the same group as Donald Duck? => Yes
Does Mickey Mouse have the permission “Calendar (Edit Group as Member or Manager)” => No OR
Does Mickey Mouse have the permission “Calendar (Edit Group as Manager)” => Yes
If (1) is true and (a) or (b) is true, allow edit of the calendar.
Why so complicated?
Why not granting a group manager to edit other group users’ calendars right away?
Good question.
Keeping position and role separate allows any combination of the two instead of forcing a role permission to a group position.
While the above described use case is the most common one, I also had users describe other situations that made the separation a useful feature.
TCN’s goal is to serve all use cases as best as possible and that is why you can set up positions and roles so it serves your situation best.
Last updated
