Minkowsky Documentation

Groups and Permission


Groups are meant to group users together for easier access. You may invite groups instead of inviting each group member individually. Or may access the calendars of all group members faster.

But groups are also important for determining access permissions. Each group may have one or more administrators. On the other hand each appointment, each task and each project has one group assigned as "administrative group". The administrators of this group do They may have (and usually will have) extended access permissions.

Minkowsky defines at least one group called All. Likewise Minkowsky defines always one user called Minkowsky Administrator (short admin) Both may be renamed by the administrator of the Minkowsky server, but still work as described below. Minkowsky Administrator is always one administrator of the group All. Other administrator of group All may be defined by the administrator of the Minkowsky server

Furthermore this group has a special meaning to Minkowsky. The administrator of this group is administrator to all objects with Minkowsky.

Access Permissions

Access permissions control the access on the different objects in Minkowsky. The three sections of Minkowsky do have an specially adopted system of access permissions

Access Permissions on Appointments

The access permissions on Appointments are the most sophisticated with Minkowsky. This applies to both the structure of the permissions and the Source determining these permissions.

The Permission String

The permission string defines which permissions are granted for a user or a group on a particular appointment. The permission can be granted or not in four areas:

  • Time / Location: [short l]
    This includes all settings about the date, repeating and the location of the appointment. Appointments are visible to a user if read access on Time / Location is granted to him.
  • Texts: [short t]
    This includes the title and text about appointment details.
  • Participants: [short p]
    This includes the list of participants and all settings made there. Also included is the privacy status and the priority.
  • Comments: [short c]
    Includes reading and adding comments.

To access reminder settings a user need permission on Time / Location and Participants.

On each of the four areas read or write (or both) access may be granted. This access permission are symbolised by a permission string, like:

r=zütk w=zütkd      or in short     zütkzütkd .

The first block (starting with r= or the first four letters of the short form) defines on which areas read access is granted. The letters z ü t k stand for the four areas, as defined above

The second block (starting with w= or the last five letters of the short form) defines on which areas write access is granted. The letters z ü t k stand for the four areas, as defined above. The laster letter d stands for the permission to delete this appointment.

If permission on a particular areas is not granted, the letter is replaced be an -. Hence the permission string

r=zü-k w=-ü-k-      or in short     zü-k-ü-k-

means that the users has read access on times, location, texts and comments and write access on texts and comments.

Sources of permissions

There are three sources which may determine access permission to an appointment.

  1. Permission defined within the appointment
    There is one permission string for participants of an appointment regardless if user or group. Is the viewer of the appointment one of the participants his permission defined within the appointment are used. All other permission are ignored apart from the administrator permissions.
    Is the viewer not participants but member of one or more participating groups the permission defined for this groups are used. There are combined such a way that all permission granted in at least one of this groups is granted to the viewer. All permissions defined by the viewed calendar are ignored.
  2. Permission defined by the viewed calendar
    • For viewing users calendar
      Each user may define access permission to appointments in his calendar. By default this permission are set to zütk-----. Furthermore he may define special access permissions for members of particular groups. If the viewer is member in one or more of this groups he has the combined access permissions. If the viewer is not member of any of these groups the default access permissions as defined by the owner of the calender are used.
    • For viewing groups calendar
      If the viewer is member of the group access permissions for group members are used. Otherwise access permissions for non-members are used. This permissions are defined on the server by administrator of the server.
    • For viewing rooms calendar
      For rooms access permission are defined on the server by administrator of the server. This permissions are used if the viewer is not participating in one or another one in appointment.
  3. Extended Permissions to Administrators
    Each Appointments has one group assigned to it as "administrative group". If the viewer is Administrator of this group the permissions for administrators of this groups are added to the permission derived under 1 or 2.
    If the viewer is Administrator of the group All the permissions for administrators of groups All are added to the permission derived before.
    The permissions for administrators for group are defined by the administrator of the server on the server.

Access permission are derived for each appointment separately. Hence, a viewer may only see some appointments in the calendar of another user. For example the other user may not grant him to view any appointment. But of course he can see all appointments both view and the other attend.

Access Permission on Tasks and Projects

There are four levels of access permissions on tasks and projects:

  1. Full Access with Delete   [short rwd]
    A Task or Project may be modified and deleted.
  2. Full Access without Delete   [short rw]
    A Task or Project may be modified but must not be deleted.
  3. Readonly Access   [short r]
    A Task or Project may be read.
  4. No Access   [short -]

Which of the permissions apply are defined as follows:

  1. The initiator has always Full Access with Delete.
  2. If the task or project is private all users other than the initiator have No Access.
  3. The administrators of the group All and the "administrative group" have Full Access with Delete.
  4. The operator(s) have the permission defined within the task or project, but at least Readonly Access.
  5. If public is defined as "administrative group" instead of a normal group all users have Readonly Access.

Access Permissions on addresses

There are four levels of access permissions on addresses.

  • Full Access : Reading writing and deleted addresses is allowed
  • Read only + Write Memos:Addresses may only be read but user may create and modify notes
  • Read only:Addresses may only be read
  • No Access:Applies to users to which non of the other levels are granted

For each of the first three levels

  • a group,
  • the public (all users are member of the public ;-) )
  • or the modifying user

may be set.If a user is members of groups on different levels the highest permission applies. If a user is not member in any of the three groups, the user has no access to the address.

If the users who created the address is defined on all three levels this address is effectively private. (However, Administrator of group All may access anyways).

Rüdiger Goetz
Last modified: Tue May 28 11:35:13 CEST 2002