Description

Along with Calendars, Events, Contacts and User Groups, Users are one of the main objects in the system.

Like other objects you may:

  Add or Edit Users
Delete Users
  Un-delete Users
Remove Deleted Users

Why do I need users?

One reason to create userids is to track who has added an event to the database or who has last modified an event.

Each time an event is added the currently logged in user is recorded inside the event. Also, whenever an event is modified the currently logged in userid is also recorded. In this way you can monitor who created or edited an event.

Another reason to create userids is to take advantage of the program's permission system. By creating different users with differing levels of permission one can control which users can add or edit events, manage calendars or even view the calendar.

Finally, without userids it would be impossible to insure that one user cannot change another user's events.

    Note: If two users have the same permission level (for example EDIT) they cannot edit each other's events.

What are user permissions?

A user's permission is an attribute stored with the user that instructs the program which options that user may take advantage of. For example, some users may be able to add and edit events while other can administer a calendar.

Complete information on user permissions is available here.

Common ways to set up user ids

A common support question is "Must I create a separate user id for every user?"

The answer is "No. Sort of". It is not necessary - you may create a single VIEW user and a single EDIT user (in addition to the SUPER or registration user). In this way you can control access to modifying the events by only telling those people you want to change it the EDIT password. The trouble with this approach is that two users can modify each other's events.

Another common way to set up a calendar is to set the default permission for the calendar to EDIT in the Calendar Edit screen. Then create a single ADMIN user. In this way no one even has to log in to add or edit events. Only the ADMIN user must log in to access the administration functions. This method suffers from the same trouble as above - since we are not distinguishing between users we cannot protect against one person changing someone else's events.

A third common way to set up a calendar is to set its default permission for the calendar to NONE (using the Calendar Edit screen). Then create a user with VIEW permission. In this case no one can even view events without first logging in. One might use this method to create a private calendar.

Finally you can setup your calendar in such a way that no-one even knows there is such a thing as logging in by turning of the login related items by checking hide all login items in the Calendar Editor. This will cause the Current User and Current Permission on the left of the screen to disappear and the Login menu item on the right of the screen to disappear. In this way everyone who accesses the calendar will get the default permission , so for example you could set it to VIEW to create a view only calendar, or EDIT to create a calendar that everyone can edit.

Using external user ids

Another common question is "Is it possible to use the operating system login to identify users (so I don't have to create a duplicate collection of userids)"?

The answer is "Yes". We call this feature Remove Login. Please see that help file.

The Registration or SUPER user

The Registration or SUPER user is a special of user. This is the only user that can create, edit, add or delete other users. Also, this is the only user that can change registration information or view installation information. Finally - you may not delete this user from the system.

This user is created automatically when you register and is called 'demo' before you register.