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
Access to administrative commands by regular users is covered in
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-
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.
Figure 117: Password re-entry dialog.
Each administrative user has a separate password, which is set with the
password command described in
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.
To add a new user to the database, the administrator presses the `Add
...' button. In response, the system displays the dialog shown in Figure
Figure 119: Add user dialog.
last, first middleThe 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:
Figure 120 shows the administrator having entered values for a new user.
Figure 120: Adding a new user.
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.
Figure 122: User database record for James L. Brandon.
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.
Figure 124: Confirmation dialog for changing a user record.
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.
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.
Figure 127: Notification sent to deleted user.
Deleting a user has the following effects on system data:
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
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.
To add a new group, the administrator presses `Add ...', whereupon the
system displays the dialog of Figure 129.
Figure 129: Add group dialog.
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.
Figure 131: Add group member dialog.
Figure 132 shows the administrator having entered IDs for the ceng
Figure 132: Add group member dialog.
When the user presses `OK' in
the system validates all entered IDs. If one or more IDs are invalid, the
system issues an appropriate error message, as described in
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.
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
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.
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.
Figure 136: Members deleted in group record dialog.
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.
You have been actioned
the group Calendar Tool group.
If you have questions about this
please contact the Calendar Tool administrator at
The actioned string is one of the following, as appropriate to the change(s) made:
The group string is the group ID. The admin string is the email address of the administrator performing the operation.
"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"
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
The Calendar Tool group group,
of which you were a affiliation,
has been deleted.
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
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.
To add a new location, the administrator presses `Add ...', whereupon
the system displays the dialog of Figure 139.
Figure 139: Add location dialog.
Figure 140 shows the administrator having entered values for a new location
Figure 140: Location database record.
Figure 141: Book location dialog.
Figure 142 is an example of a location booking.
Figure 142: A location booking for the Grad Student Room.
To view an existing location record in the database, the administrator selects
a location name or number in
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 `Add ...' booking command is described
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 144 shows the result of `View ...' for the third listed
Figure 144: Viewing a meeting from the location record dialog.
Figure 145: Viewing an other-usage booking from the location record dialog.
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,
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
188.8.131.52. Summary of Super User Privileges