The concept of a user's permission is fundamental to way this software works. The software provides a six level hierarchical permission system. Permissions may be assigned to calendars, users, user groups or remotely. Through a combination of these settings one has very fine control of whom may change what, when.

As stated, permissions are hierarchical. By this we mean that if a user has a certain permission she has all the privileges of lower levels permissions. For example, edit users have add and view permission. Admins have edit, add and view permission. Elsewhere in this help file when we say "a user has a certain permission (or higher)" this is what we mean.

The super user has every privilege and is not limited in any way as to any function of the software. The super user is the only such user.

Setting permission at the calendar level is explained fully in the calendar edit article. Assigning remote permissions is explained in the remote login help file. User group permissions are described in the user group help file. The current article describes permission settings as relates to the user itself. Having said that, all sources of permission settings are applied in the final calculation in any given situation. This final permission calculation is described below.

Setting a user's permission

You may change a user's permission setting in the user edit screen. If permitted users may edit themselves using the user edit dialog where they may request a permission setting. When editing themselves users may ask for permission settings higher than can be automatically granted. This will cause a pending request to be generated awaiting further approval. Administrators may, if they wish, grant permissions on a per calendar basis.

Levels of Permission

There are six levels of permission:

Trusted users

If a user is made 'trusted' then that user has additional privileges over a regular user of the same type.

A trusted edit user, for example, may edit every event in the system, including events owned by users with higher permission. A trusted edit user also see a few more functions under the event manager than a regular edit user sees. This capability may be useful for an assistant who must modify multiple other user's events but to whom you do not wish to grant admin permission.

A trusted admin user sees everything a regular admin user sees however he/she may also add users and access other system-wide functions. In effect this creates a mini-super user, however trusted admin users may not edit the super user's password nor create other trusted admin users.

The other permissions (none, view and add) may be specified as trusted but it has no effect. The super cannot be made trusted because, again, it would have no effect.

Components of the permission calculation

There is a number of different permission components that go into granting a particular permission for a particular user on a particular calendar. These are the default calendar permission, the default remote login permission (if any), the user's default permission, the users special permission (if any) and the user's group permission (if any). The following algorithm tries to describe in a succinct fashion how all these components work to make up a user's permission. If you under this - you understand permissions.

Calculation of a user's permission

The calculation of the user's effective permission is complicated but it makes perfect sense if you understand it. Without trying to explain it in words the following pseudo code algorithm tries to clarify how permissions are calculated for any particular situation.

calculate_permission()
{
    // Handle an easy case...
    if (remote login is enabled but $REMOTE_USER is empty and the user is not logged in)
        return default calendar permission

    // Handle an easy case...
    if (remote login is disabled and the user is not logged in)
        return default calendar permission
        
    // At this point the user is logged either remotely 
    // or against the internal user database

    // Look for the user's permission in the user database
    var userid = userid of logged in user
    if (userid is found in user database) // may be remote
    {
        // Pick the default permission for this user
        permission = default permission for this user

        // Check for permissions per calendar
        if (user has special permission for this calendar)
            permission = special permission for this user for this calendar

        // If enabled and permission is higher apply user group permission
        if (user is member of one or more user groups)
            permission = highest of current permission and highest user group permission

        // If the user is trusted we note that here but the 
        // user's permission remains unchanged.  Where appropriate, 
        // certain functions are permitted for trusted users that 
        // would not be granted otherwise

        // Return calculated value
        return permission
    }
    
    // The user was not found in the program's 
    // internal user database fall back to defaults
    if (remote login is enabled)
        return remote login permission

    // Final case (probably never happens)
    return default calendar permission
}

Its confusing, we admit, but it does the right thing.