Delegation: Difference between revisions
Telcredstaff (talk | contribs) |
Telcredstaff (talk | contribs) |
||
Line 91: | Line 91: | ||
[[File:doorsharing.png|Door sharing]] |
[[File:doorsharing.png|Door sharing]] |
||
==== Sharing vs. transfering a door ==== |
|||
Sharing and transfering a door sound similar but there are important differences and they support different use cases. |
|||
* When sharing a door the sharing organization retains full control over the door. They can create access privileges for their own users, change the settings, and see all the events for the door. The purpose of sharing the door is to let another organization ''also'' do this. A good use case for sharing is when the owner of an office building wants to let their tenants create access rights for the common entrance door. |
|||
* When transfering a door, the transfering organization gives up all control and visibility of the door. It is only the receving organization that can create access privileges for the door, change access control related settings (e.g. unlock by schedule) and see the events for the door. At the same time, the receiving organization does not need to concern themselves about the technical aspects of the door, such as which controller it is connected to. A good use case for door transfer is when the owner of a residential building wants to give their tenants full control of the doors to their own apartments, while not having to worry about (or potentially mess up) the technical settings for the doors. |
|||
=== Privileges === |
=== Privileges === |
Revision as of 12:02, 7 September 2020
Officers and capacities
The people involved with the administration of a system are referred to as officers. An officer can have one or more of the following capacities:
- System owner
- Create and edit organizations
- Create and edit new officers
- Assign officers to be system owners, organization owners, and administrators
- Organization owner (for one or more organizations)
- Edit organization
- Create and edit new officers
- Assign officers to be organization owners, and administrators
- Administrator (for one or more organizations)
- Monitor events
- Manage access rights, i.e. doors, users, devices, schedules...
- Configure hardware and set up commands & triggers
Administrator views
The administrator GUI is separated into three different views that mirror the capacities system owner, organization owner, and administrator. For a large installation, these may be used by different people. For a smaller installation, it is likely that the same person(s) will use all three views, but for different things.
System owner
This view is accessible to officers with the system owner capacity, and is available at:
https://access.telcred.com/sys
When creating a new organization, the system owner specifies the default time zone (can be changed for individual door controllers). In the same screen, the system owner can assign officers to be organization owners and / or administrators.
The system owner can also appoint other officers to be system owners. This is done when creating or editing an officer. In the same screen it is also possible to assign the officer to be organization owner for one or more organizations:
Telcred Access Manager supports two-factor authentication for officer login and we highly recommend to use it. The only method currently supported is Yubikey OTP (One Time Password). More information about two-factor authentication can be found here.
An officer can be temporarily blocked, in which case he or she will not be allowed to login.
Organization owner
This view is accessible to officers with the organization owner capacity, and is available at:
https://access.telcred.com/org
An organization owner can edit the organization name and default time zone, and assign officers to be organization owners and / or administrators (for the current organization). Assigning officers can be done when updating the organization information OR when creating or editing officers:
Administrator
This is the normal administrator view, where an officer with the administrator capacity can add new users, assign access rights to users, etc. This view is available at:
Switching between organizations
One officer can be administrator or organization owner in several organizations. In this case, the officer can switch between organizations using the selector at the top of the screen:
Transfer doors to another organization
A common use case is that one organization, typically the building owner, is responsible for the technical aspects of the doors and the access control system, but want to delegate administration of certain doors to the tenants. To support this use case, it is possible create a door config in one organization, and then transfer the door to another. It is only possible to transfer a door to one organization at the time.
After a door has been transfered, it will automatically show up under Doors for the receiving organization and it is no longer available to the transfering organization. It is now only the receiving organization that can create access privileges for this door as well as change access control related settings for the door. Also, it is only the receiving organization that can see the events for the door.
However, the door config remains with the transferring organization, and at any time it is possible to end the door transfer. The events that occurred during the time that the door was transferred will stay with the organization that was responsible for the door during the time of the event.
Sharing between organizations
Doors
With delegation, each organization can manage their own users, doors, and access rights. However, it is common that users belonging to one organization need access rights to doors belonging to another organization. For example, in an office building with tenants, all tenants need access to the entrance doors to the building, as well as garages, and elevators.
One way to address this need is through door sharing. The administrator of organization A can share a door with organization B, which makes it possible for the administrator of organization B to create privileges for that door as if it were their own (but not change any settings for the door).
Sharing vs. transfering a door
Sharing and transfering a door sound similar but there are important differences and they support different use cases.
- When sharing a door the sharing organization retains full control over the door. They can create access privileges for their own users, change the settings, and see all the events for the door. The purpose of sharing the door is to let another organization also do this. A good use case for sharing is when the owner of an office building wants to let their tenants create access rights for the common entrance door.
- When transfering a door, the transfering organization gives up all control and visibility of the door. It is only the receving organization that can create access privileges for the door, change access control related settings (e.g. unlock by schedule) and see the events for the door. At the same time, the receiving organization does not need to concern themselves about the technical aspects of the door, such as which controller it is connected to. A good use case for door transfer is when the owner of a residential building wants to give their tenants full control of the doors to their own apartments, while not having to worry about (or potentially mess up) the technical settings for the doors.
Privileges
Sometimes there is a need for more fine-grained control of when and how a shared door can be accessed by the users of other organizations. For example, the building owner may want to share the door to a common storage room with all the tenants, but only during office hours. For these cases, Telcred Access Manager has privilege sharing. The administrator of a door can create a privilege (with its credential and optional schedule restriction) and then share it with other organizations. The administrator(s) of the organization(s) can then assign this privilege to their own users via a role just as for their own privileges.
Users
User sharing solves another use case, namely when a user belonging to one organization often needs access to doors belonging to another organization. For example, the building owner can create a user for service staff and then share this user with all the tenants. This allows the tenants to maintain control of when service staff can access their premises.