Roles and permissions

In Zeitwart no permission hangs on a person and none on a room. Every permission comes out of a chain: user → role → permission on the objects of an organisational unit. That sounds like a detour, but it is the reason large installations stay manageable.

Why not simply direct?

If you granted permissions individually between people and rooms, 1,000 users and 1,000 resources would give you a million possible relationships. Nobody maintains an environment like that.

Zeitwart therefore groups both sides: users into roles, resources into organisational units. Only the relationships in between are managed – a few dozen instead of a million.

The same role, different permissions

Here is the distinctive part: a role does not carry its permissions globally but per organisational unit. The role "office" may do everything in faculty A and only read in faculty B – without you having to create two roles. Link it to another unit and a fresh set of tick boxes appears there.

Each person can belong to any number of roles: student, staff, management. Administrative permissions run the same way – the classic admin role is just one role among many.

Permissions are inherited downwards

Because organisational units are hierarchical, granting permissions is inherited too. If a role has booking rights on a parent unit, they apply to every unit below it and their resources. Group five computer labs under one common unit and a single grant covers all five.

What that lets you model

• students book study rooms only, staff also book meeting rooms

• facilities management sees every booking but may not change any rules

• a faculty secretary administers their own unit and nothing else

• external guests see only the rooms released to them

• a room display has its own account with a role that may only display

Taken from the directory

When people sign in through an identity provider, roles can be assigned automatically – based on the attributes of the sign-in, such as the e-mail domain or a group membership from the directory service. Memberships stay maintained where they are maintained anyway.

Benefits at a glance

• a permission model that stays clear even with thousands of users and resources

• the same role can carry different permissions per organisational unit

• permissions are inherited down the tree, so one grant covers many resources

• any number of roles per person, administrative tasks included

• automatic role assignment when signing in through the identity provider