2.6. Administrative Functions

The scenarios in this section cover administrative commands. The commands provide access to the three Calendar Tool databases: users, groups, and locations. Regular users can access the databases with viewing commands. Administrative users can modify the databases with add, change, and delete commands. In addition to database access, there are other administrative commands for performing small managerial functions.

As described in Section 2.1, there are separate interfaces for two types of registered user -- regular and administrative. An administrative user is one with designated administrative privileges. Both regular and administrative users can run the Calendar Tool through the regular user interface shown in Figure 1. Only users with administrative privileges can run through the administrator interface of Figure 2. The administrative interface provides commands that modify the databases.

Privileged administrator access is covered in Sections 2.6.1 through 2.6.5 Access to administrative commands by regular users is covered in Section 2.6.6. In the scenarios, the term "administrator" refers to a user with administrative privileges; the term "user" refers to a regular user without administrative privileges. Also, the term "privileged Admin menu" refers to the command menu in the privileged administrator's interface; the term "Admin menu" refers to the menu accessible from the regular, non- privileged interface.

2.6.1. Gaining Administrative Access

When a user invokes Calendar Tool Administration, the system presents the password dialog shown in Figure 116.

Figure 116: Password entry dialog.


The user must enter a legal password in order to be confirmed as an administrator. If the user does so, the system displays the administrative interface of Figure 2. If the user fails to enter the correct password, the system denies access by presenting the dialog of Figure 117.

Figure 117: Password re-entry dialog.


The system displays this dialog for up to three additional attempts, after which the dialog is removed and the user is not permitted administrative access. As the password is typed, it is echoed as asterisk characters, not as the actual characters typed.

Each administrative user has a separate password, which is set with the password command described in Section 2.6.5. The Calendar Tool is installed with one pre-defined administrative user. The user name is "Calendar Tool Administrator", with ID "admin". This pre-defined administrator cannot be deleted.

2.6.2. User Database

The user database contains a record for each registered user. To access the user database, the administrator selects the `Users ...' item in the privileged `Admin' menu. In response, the system displays a dialog of the form shown in Figure 118.

Figure 118: User database dialog.


The scrolling area and search field operate in the same manner as described Section 2.3.5.1 for viewing other users.

To add a new user to the database, the administrator presses the `Add ...' button. In response, the system displays the dialog shown in Figure 119.

Figure 119: Add user dialog.


The dialog contains all the information in a user record. The `Name' is entered separately as `last', `first', and `middle'. Only `last' is required. If `middle' is non-empty, `first' must be non-empty. The names appearing in the database list of Figure 118 are formatted as follows:
last, first middle
The comma and spaces are absent if there are no first and last names. The last name can itself contain space characters. For example, the last name "Calendar Tool Administrator" is that of the initial pre-defined user in the user database.

The `Calendar Tool ID' is the identifier by which a user is known in the Calendar Tool system. The ID must be unique among all Calendar Tool users and groups. The area code and phone number fields are optional information that may be useful for communicating with users outside the context of the Calendar Tool.

`Email' is required information for all users. It is the electronic mail address of the user for mailing meeting notifications and reminders. The `Host Computer' is the unique identifier of the computer on which the user runs the Calendar Tool. The format of the identifier is platform- dependent, based on the type of network to which host computers are attached. IP address is a typical format. `Computer User ID' is the user's identification on the host computer. `Home Directory' is the file directory (i.e., folder) assigned as the user's home directory on the host computer.

`Host Computer', `Computer User ID', and `Home Directory' are optional data fields. All three must be provided in order for the user to receive notification of meetings scheduled by other users. If the value is empty for one or more of these fields, the user does not receive such notifications.

The `Item Limit' field specifies the maximum number of scheduled items that can be stored for the user in the Calendar Tool central repository. The limit value is optional. If it is absent, there is no limit. The item limit can be zero, in which case the user has an empty calendar in the central repository. Complete details on the central calendar repository are covered in Section 2.14.

The `Admin Privileges' radio buttons indicate if the user has administrative privileges. The default is `no'. When the administrator selects `yes', the system performs the following actions when the Add operation is confirmed:

  1. grants the affected user administrative access privileges

  2. adds the user to the `admins' group

  3. sets the value of the user's administrative password to the user's ID
The default password can (and should) be changed using the `Admin Password' command described in Section 2.6.5. When the administrator changes the `Admin Privileges' setting from `yes' to `no', the system ungrants administrative access and removes the user from the `admins' group.

Figure 120 shows the administrator having entered values for a new user.

Figure 120: Adding a new user.


As may be typical, values for several of the fields are similar. Here, for example, the `Calendar Tool ID', `Email' prefix, and `Computer User ID' are the same. This is not required, but is likely to be a common practice of administrators. When the adminstrator presses `OK', the system performs the following actions:

  1. adds the new user record to the user database

  2. updates the list of names in the user database dialog

  3. adds the new user's ID to the All Users group, as described further in Section 2.6.3.
Pressing Clear in the add-user dialog erases any edits made since the dialog was displayed. `Cancel' cancels the add operation without adding to the database.

To view the database record of an existing user, the administrator selects the user name or ID in the list and presses the `View ...' button. Clicking on either the name or ID highlights both. For example, Figure 121 shows the user having selected James L. Brandon for view.

Figure 121: Brandon selected in users list.


The figure shows the newly added user Richard Anderson. When the administrator presses `View ...' in Figure 121, the system displays the dialog of Figure 122.

Figure 122: User database record for James L. Brandon.


A shortcut to view a user's record is to double click on the user name or ID in the scrolling list.

The user record dialog has all of the same data fields as the dialog for adding a new user. In addition, there are two scrollable lists that show the Calendar Tool groups of which the user is a member and a leader. The administrator can change all data fields except `Calendar Tool ID', `Member of', and `Leader of'. Once an ID is assigned for a particular user, it cannot be changed. Group membership and leadership are changed with the group database commands described in Section 2.6.3.

Figure 123 shows edits to the user record for James L. Brandon.

Figure 123: User record for James L. Brandon edited.


The edits are to the phone, email, and host computer fields. When the user presses `Change', the system displays the confirmation dialog in Figure 124.

Figure 124: Confirmation dialog for changing a user record.


The administrator confirms the change with `OK' or cancels it with `Cancel'. Upon confirmation, the system performs the following actions:

  1. updates the user record in the database

  2. notifies the affected user of the change

  3. deletes items from the user's calendar in the central repository, if necessary to satisfy a changed item limit value; Section Section 2.14.2 has further details on central repository item limits

  4. terminates the Calendar Tool Administration program if `Admin Privileges' was set to `no' and the the changed user is executing it at the time the change is confirmed, including if it is the administrator who has performed the change
In this example, neither action c or d applies.

The change notification appears on the affected user's screen, in the form shown in Figure 125.

Figure 125: Notification of change to James L. Brandon user record.


The notification message lists the specific details of the change. The email address at the end of the message is that of the administrator who performed the change. This email address is defined in the user record for the administrator.

To delete a user, the administrator presses `Delete' in the user record display. In response, the system displays a confirmation dialog of the form shown in Figure 126.

Figure 126: Confirmation dialog for deleting a user record.


When the administrator confirms the deletion with `OK', the system notifies the deleted user with an on-screen notification of the form shown in Figure 127.

Figure 127: Notification sent to deleted user.


This is the notification sent to user Frank D. Smith. The notification text explains the delete action.

Deleting a user has the following effects on system data:

  1. removes the user's record from the user database

  2. removes the user from all groups of which the user is a member and/or leader, including the All Users group, and if appropriate the Adminstrators group

  3. removes the user's calendar from the central repository

  4. cancels any meeting scheduling operation that the deleted user is executing at the time the deletion is confirmed

  5. terminates the Calendar Tool Administration program if the deleted user is executing it at the time the deletion is confirmed, including if it is the administrator who has performed the deletion
Deleting a user does not delete the user's ID from any meeting attendees lists on which it appears. Once a meeting is scheduled, its attendees list remains unchanged, except for local edits performed by individual (non-scheduler) users.

There is a rare but possible condition where an administrator deletes a user while another user is scheduling a meeting. Under this condition, the user deletion could affect the possible times or time conflict lists that are already displayed at the time of user deletion. In such cases, the system does not dynamically update the affected lists. Therefore, the in-progress scheduling operation proceeds without reflecting the user deletion. All meeting scheduling that begins subsequent to the user deletion is performed as it should be in the context of the deleted user.

Unlike meeting notifications, there is no option to disable the notifications for change or delete of a user record. The on-screen notification appears immediately if the affected user is running the Calendar Tool, or the next time the user invokes the Calendar Tool if it is not running at the time of notification.

2.6.3. Group Database

User groups are a convenient means to define a named list of related users. In comparison to an individual user, a group can be considered a virtual entity. No single user owns the group; a group has no email address and no host computer information. As explained in Section 2.4.1, meetings scheduled by group leaders are recorded in group calendars, as are meeting changes made by leaders. However, none of the group leaders owns the group calendar explicitly. In particular, if all group leaders are deleted, the group calendar persists.

To access the group database, the administrator selects the `Groups ...' command in the privileged `Admin' menu. In response, the system displays the dialog in Figure 128.

Figure 128: Group database dialog.


This dialog has the same format as that for the user database in Figure 118. Two groups are built-in to the Calendar Tool: all and admins. These groups consist of all registered users and all adminstrative users, respectively.

To add a new group, the administrator presses `Add ...', whereupon the system displays the dialog of Figure 129.

Figure 129: Add group dialog.


The group `Name' is free-form text for the full name of the group. The `ID' is the unique group identifier. The `ID' must be unique among all Calendar Tool users and groups. The `Item Limit' specifies the maximum number of scheduled items that can be stored for the group in the central repository.

The `Members' and `Leaders' lists contain the user IDs of the group members and leaders. Both of these lists can have zero or more entries. A group with no members or leaders is considered dormant. A group with members but no leaders cannot have meetings scheduled for it. The utility of dormant and leaderless groups is limited, but the system allows them to exist at the discretion of system administrators. A group leader need not be a member. This allows a leader to schedule a meeting at which the leader is not an attendee.

Figure 130 shows the administrator having entered values for a new group.

Figure 130: Adding a new group.


Immediately below the member and leader lists are small `Add ...' and `Delete' buttons. These are used to add and delete users from the lists. For example, when the administrator presses the `Add ...' button below the `Members' list, the system displays the dialog of Figure 131.

Figure 131: Add group member dialog.


The dialog allows the administrator to enter one or more IDs for group members. The entered IDs must be of current registered users and/or defined groups. To facilitate entry, ID completion is operative in the dialog. Specifically, the administrator can type the leading prefix for an ID and press the TAB key to have the ID completed. Details of name and ID completion are covered in Section 2.11.16 The administrator can view the list of all available user and group IDs in the database dialogs of Figures 118 and 128. Allowing multiple IDs to be entered facilitates the definition of groups with a large number of users. If desired, the administrator can use the `Edit Paste' command to enter names from an outside text file, assuming inter- program copy/paste operations are supported by the underlying operating environment.

Figure 132 shows the administrator having entered IDs for the ceng group.

Figure 132: Add group member dialog.


The first row of IDs are for individual users. The IDs that follow are for other groups. As introduced in Section 2.4.1.3, a group that contains other groups as members is a supergroup. There is no limit on the depth of the supergroup hierarchy. That is, a supergroup can have one or more supergroups as members. In terms of individual users, supergroup membership is defined as the set of all users appearing throughout the supergroup hierarchy. As explained in Section 2.4.1.1, user duplication in a group membership hierarchy is ignored in the context of scheduling meetings.

When the user presses `OK' in Figure 132, the system validates all entered IDs. If one or more IDs are invalid, the system issues an appropriate error message, as described in Section 2.12.6. If all IDs are valid, the system enters them in alphabetic order into the members list for the group. If the same ID is entered more than once in the add-member dialog, the name appears only once in the completed members list. Figure 133 shows the results of adding the `ceng' group members.

Figure 133: Add group dialog with members added.


The added members are listed alphabetically, one per line in the `Members' viewing list.

To add one or more group leaders, the administrator follows mostly the same procedure as for adding members. The only difference is that the IDs of group leaders must be individual users, not groups.

At the bottom of the add-group dialog are `OK', `Clear', and `Cancel' buttons. These apply to the group as a whole. When the user presses `OK', the system adds the group to the database. `Clear' and `Cancel' have the normal functionality.

To view an existing group, the administrator selects the group name or ID in the group database dialog of Figure 128. and then presses the `View ...' button. For example, Figure 134 shows the result of the user viewing the csfac group.

Figure 134: Group database record for the Computer Science Faculty.


The administrator can change all fields except `ID'. As for a user, once an `ID' is assigned to a group in cannot be changed. The `Add' buttons immediately below the members and leaders lists operate in exactly the same manner as in the add-group dialog of Figure 129.

To delete one or more group members, the administrator selects the name(s) in the `Members' list and presses the `Delete' button immediately below the list. To select multiple names for deletion, the user holds down the SHIFT key as each name is selected in the list. In response to executing `Members: Delete', the system displays a confirmation dialog of the form shown in Figure 135.

Figure 135: Group member delete confirmation.


Here the confirmation is in response to the administrator selecting two users for deletion from the csfac group. `OK' confirms the deletion, `Cancel' cancels it. In response to confirming the delete, the system removes the names from the members list, as shown in Figure 136.

Figure 136: Members deleted in group record dialog.


Since the members list is longer than fits in the scrolling area, only the deletion of `cdaniels' is immediately visible.

To delete one or more group leaders, The administrator follows the same procedure as for member deletion. In the leader-deletion confirmation dialog, the word "member" is replaced by "leader".

The four command buttons at the very bottom of group dialog correspond to the group record as a whole. When the user presses `Change', the system displays a confirmation dialog of the form shown in Figure 137.

Figure 137: Confirmation dialog for changing a group record.


When the administrator confirms the change with `OK', the system performs the following actions:

  1. updates the group record in the group database

  2. updates the members and leaders lists in the group records of all affected users

  3. notifies all added or deleted users of the change

  4. notifies all added or deleted leaders of the change
If the same user is added as both a member and leader, only one notification is sent. The notification takes the following form:

You have been actioned
the group Calendar Tool group.

If you have questions about this
please contact the Calendar Tool administrator at
admin

The actioned string is one of the following, as appropriate to the change(s) made:



"added as a member of"

"added as a leader of"

"added as a member and leader of"

"deleted as a member of"

"deleted as a leader of"

"deleted as a member and leader of"
The group string is the group ID. The admin string is the email address of the administrator performing the operation.

When the user executes `Delete' for a group record, the system displays the same form of confirmation dialog as shown in Figure 137, with the word "change" replaced with "delete" in both the dialog banner and message text. When the delete is confirmed, the system

  1. removes the record from the group database

  2. removes the group calendar from the central repository

  3. removes the group from the members and leaders lists of all affected users

  4. notifies all affected users
The notification takes the following form:

The Calendar Tool group group,
of which you were a affiliation,
has been deleted.

The group string is the group ID. The affiliation is one of the following, as appropriate: "member", "leader", or "member and leader"

Change or deletion of a group record has no effect on any user calendars. In particular, no meetings scheduled with the group as an attendee are changed or deleted. Since deleted group IDs remain in scheduled items, system administrators must exercise good judgment in reusing the ID of a deleted group. If a deleted group ID is reused for a group with different membership, the extant appearances of the ID in user calendars will be misleading in terms of the users for whom the meeting was originally scheduled.

The Calendar Tool provides no commands for a user to request addition to or removal from a group. Such requests must be made to an administrative user by some means outside of the Calendar Tool, such as electronic mail. The user can view a list of all administrators using the `List Admins' command. The email address for an administrator is available in the administrator's user database record.

2.6.4. Location Database

The location database contains information records for rooms and other locations in which meetings can be scheduled. To access the location database, the administrator selects the `Locations ...' command in the privileged `Admin' menu. In response, the system displays the dialog in Figure 138.

Figure 138: Location database dialog.


This dialog has a very similar format to the user and group database dialogs. Here, locations are listed by name and number. The default sorting order is by name, which can be changed to number by clicking on the `Number' column heading. Since names need not be unique, secondary order is by number when name is the primary sort key. The `Search by' field operates in the same manner as in the user and group database dialogs.

To add a new location, the administrator presses `Add ...', whereupon the system displays the dialog of Figure 139.

Figure 139: Add location dialog.


The `Name' field is a free-form text string. `Number' is the unique location identifier, typically in the form of a room number, but not restricted to any specific format. The scrollable `Bookings' field contains a list of time slots during which the room is booked for meetings or other activities. The entries in the `Bookings' list are of two forms:

  1. the title of a scheduled meeting

  2. the description of some other usage
The meeting titles are for meetings scheduled using the Calendar Tool, as described in Section 2.4.1. The other usage descriptions are added by the administrator for times during which the location is known to be in use, meaning that meetings cannot be scheduled at those times. Immediately below the bookings list are command buttons to add and view bookings. The `Remarks' field contains optional explanatory information about the location, such as equipment or facilities it contains.

Figure 140 shows the administrator having entered values for a new location record.

Figure 140: Location database record.


The `Name', `Number', and `Remarks' values are entered by normal typing. To add a booking, the administrator presses the `Add ...' button below the bookings list, in response to which the system displays the dialog of Figure 141.

Figure 141: Book location dialog.


The `Use' field describes the use for which the location is booked. The `Use' string must be unique among all bookings for the same location. The `Start Time' and `Duration' specify the time slot of the booking. The `Start Date' and `End Date' specify the date range. The dates may be empty, which means that the location is booked indefinitely for the specified use. If the `Start Date' is specified but the `End Date' is empty, the start date is taken as a single date. The time and date values must follow the normal data entry rules described in Section 2.11. Pressing `OK' adds the booking to the `Bookings' list, if it does not conflict with any existing booking. The `Clear' and `Cancel' commands have the standard functionality.

Figure 142 is an example of a location booking.

Figure 142: A location booking for the Grad Student Room.


In this example, the booking is the first to be added, so no conflict exists. If the administrator attempts to add a booking that conflicts with an existing booking, either meeting or other usage, the system issues an appropriate error message as described in Section 2.12.6. A booking conflict arises when the time and date range of any existing booking overlaps with any part of the time and date range for a new booking to be added.

To view an existing location record in the database, the administrator selects a location name or number in Figure 138 and presses `View ...'. For example, Figure 143 shows the result of the administrator viewing the second listed location in Figure 138.

Figure 143: Viewing a location record.


The location record dialog has exactly the same data fields as the add-location dialog shown in Figures 139 and 140. In place of the `OK' button there are `Change' and `Delete' buttons. The sorting order for the `Bookings' list is alphabetic, case-insensitive. If a meeting title and other-usage booking are the same string, the meeting title appears first in the list.

The `Add ...' booking command is described above. To view an existing booking, the administrator selects the booking description in the list and presses the `View ...' button immediately below the list. When the selected booking is for a meeting, the system displays an item- level view for the version of the meeting on the scheduler's calendar. If it is a recurring meeting, the displayed instance is for the start date. When the viewed booking is for a non-meeting usage, the system displays a booking dialog. For example, Figure 144 shows the result of `View ...' for the second booking listed in Figure 143; Figure 144 shows the result of `View ...' for the third listed booking.

Figure 144: Viewing a meeting from the location record dialog.




Figure 145: Viewing an other-usage booking from the location record dialog.


Since an outside-usage booking is for a contiguous time period, it takes multiple bookings to define discontinuous usages. For example, the `Morning Classes' booking in Figure 143 covers the 8 AM to 1 PM time slot. The `Afternoon Classes' booking covers 2 PM to 6 PM. These two definitions allow meetings to be scheduled between 1 and 2 PM.

The adminstrator can change or delete a booking using the command buttons at the bottom of the booking dialog. To change, the administrator edits one or more data fields and presses `Change'. To delete, the administrator presses `Delete'. `Clear' removes any edits made after initial dialog display. `Cancel' removes the dialog with no change or deletion made.

An other-usage booking is not a scheduled item, so it does not appear on any calendar. The effect that a booking has on scheduling is to prohibit a meeting from being scheduled in the location during any of the booked times and dates. An other-usage booking expires after its end date or single start date, if present. The system does not automatically delete expired bookings, but an expired booking no longer affects meeting scheduling. Deletion of expired bookings is the responsibility of system administrators.

2.6.5. Other Admin Commands

Describe that the Central Host command allows the admin user to set unique identification for the Calendar Tool central host computer. Describe functions of central host, viz,

  1. facilitates communication among computers of Calendar Tool users

  2. stores calendar information and notifications when necessary (i.e., when user computers are not operating or accessible in the network)

Describe that `List Admins' shows who all the admins are, Figure 146.

Figure 146: List of Calendar Tool administrators.


Describe that `Password' lets the admin change her password or the password of any other system administrator. Clearly, administrators should use good judgment when changing passwords, particularly for other administrators.

2.6.6. Regular User Access to Admin Commands

2.6.6.1. Summary of Super User Privileges

  1. Maybe on this one. Can cancel any leader-scheduled meeting. We need to clarify that the super user can see only the meeting in the group calendar, not in any individual user's calendar.

  2. Can delete items from group calendars.

  3. Can delete any user. The user's calendar wont be affected, but the user will no longer participate the way a registered user does.

  4. Cannot see any more of any user calendar than any other user can; cannot change or delete anything from any user's calendar.

  5. Can cap the number of items that appear in the central Cal Tool repository for any particular user or group.




Prev: finer-points | Next: options | Up: functional | Top: index