Groups are used to organize entities and control access to them. Examples of entities are Locks, Keys, Users etc., but can also include things like Roles and Calendars.
Groups always have a Group Type. The group type controls:
For example a Lock may be permitted to be in just one group of type "Department" since it may only be in one physical location; but a user may be a member of multiple groups of type "Administrative".
If the group type permits hierarchies then groups may be assigned to other groups of the same type.
A group B that is assigned to group A is referred to as a
The system supports five pre-defined group types:
| Name | Entities | Membership | Hierarchies |
|---|---|---|---|
| Departments | Locks, Keys, Users, Sync Stations | single | yes |
| Routes | Locks | single | yes |
| Administrative | Any | multiple | yes |
| Permissions | Users | multiple | yes |
| Key Shares | Keys, Users | multiple | yes |
Departments are mostly used for organizing locks. However it is often convenient in simple systems to also assign keys, users and sync stations to departments. Note a restriction is that one of these may only be assigned to one department at a time.
Routes are used to organize locks into checkpoint routes. Only locks may be members. Note it is possible to organize checkpoint routes into hierarchies which simplies the authorization of users to manage such routes, but locks may only be assigned to leaf nodes.
Administrative groups may be used to manage access to any kind of entity, including things like Roles and Calendars. Administrative groups can be organized into hierarchies and entities may be members of multiple groups.
Permissions groups may be used to define common sets of permissions that are inherited by any user that is a member of that group. Permissions may include roles. This is the only exception to the rule that roles are never inherited by users from another entity.
Key Share groups may be used to share a pool of shared keys with a number of users. All pins of Users in the group will be programmed on to all keys in the group, allowing users to activate any one of the keys using their personal PIN.
The main purpose of Administrative groups is to restrict individual users to specified management groups. Departments may also be used for this purpose. The main difference between Administrative groups and Departments is that an entity may only be a member of one department, but may be a member of multiple administrative groups.
When assigning a permission with a Role to a user using Users/Edit/Permissions, you have the option of specifying a group. For example, suppose you have a Role named "Administer department" that has permission to view and edit users, calendars and roles. You have someone named "AdminA" who is going to be responsible for administering these entities in a department "DepA". Use Users/Edit/Permissions to add a permission with the role "Administer department" restricted to "DepA". This means that the rights within role "Administer department" may only be exercised inside the department "DepA", and any sub-departments of "DepA".
When the user "AdminA" logs in they will only be able to see and edit users, calendars and roles that are members of "DepA" or any sub-departments. If AdminA adds any new users, calendars or roles these are automatically added to "DepA". This membership is visible by going to Groups, selecting Departments, and then one of these entities. AdminA is able to change membership of the entity within the hierarchy of subgroups, but may not remove membership entirely.
Note also that user "AdminA" will not be able to view any entities that are not within the hierarchy of Groups to which AdminA has access to. If for example a user is not a member of any group, then that user will no be visible to AdminA. This applies to the AdminA user: if AdminA has "View Entities" permission in DepA, but is not a member of DepA, then AdminA will see their own user record within the list of users. Membership of a group, and permission to exercise a role within a group, are two different things.
To view groups access Groups from the main menu.
By default a list of Departments is displayed. Different types of groups may be selected using the first combo-box as the top of the page.
The "Parent" column is filled if the group is a sub-group of a parent group. Generally a subgroup can only have one parent. A group that has no parent is a "root" group, and these are only visible to users with unrestricted group access or with explicit permissions to view a root group.
The second comb-box at the top right of the form may be used to view entities within the selected group type. When it indicates "(none)" the group information is displayed. When an entity type is selected, the columns after the group Name become a list of that entity type. You can tick the tick-boxes within each column to quickly add or remove an entity from a group. A table cell is highlighted pink if the entity is currently a member of that group. Note that a cell may be colored pink even if the check-box is not ticked, if the entity is a member of a sub-group of that group. By definition an entity is a member of a group if it is an explicit member of that group, or a member of any sub-group (or sub-sub-group etc.) of a group.
The behavior when ticking members of a group depends on the group type. The rule for departments is that an entity may only be a member of one department at a time: departments are intended for geographical categories to be used for the location of locks, for example. When you tick any cell in a row, any other cell becomes un-ticked. For all other group types however an entity may be a member of multiple groups, including being an explicit member of both a parent group and its subgroup(s).
When adding a new group the group type assigned is the same as the current type of group being viewed. Available parent groups are restricted to groups of the same type. For example a department may only be a subgroup of another department, not any other group type. After creating a group the group type may not be changed.
Locks contained within departments or administrative groups can be shared with other accounts. See Group sharing for details.