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 192.

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 194.

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

last, first middle

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

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

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.

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 197 shows the user having selected James L. Brandon for view.

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 199 shows edits to the user record for James L. Brandon.

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

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

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 202.

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

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 204.

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

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 206 shows the administrator having entered values for a new group.

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

When the user presses `OK' in Figure 208, 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 209 shows the results of adding the `ceng' group members.

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 204. and then presses the `View ...' button. For example, Figure 210 shows the result of the user viewing the csfac group.

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 211.

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 213.

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

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"

When the user executes `Delete' for a group record, the system displays the same form of confirmation dialog as shown in Figure 213, 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 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 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 214.

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

1. the title of a scheduled meeting
2. the description of some other usage

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

Figure 218 is an example of a location booking.

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

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 220 shows the result of `View ...' for the second booking listed in Figure 219; Figure 220 shows the result of `View ...' for the third listed booking.

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 222.

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

Explain how the first three kind of options are ?all? settable by user and are therefore explained in the next section. The difference between what the admin does versus what a regular user does is that under `Admin->Global Options', the admin is setting the global defaults for all users, some or all of which may be changed by users on an individual basis. I think it's also worth mentioning that an admin can be a regular user if she wants to be. I.e., there need not be a special user account that is "the" admin; there can be if that's how a group of users wants to set things up, but there need not be. If an admin wants to be are regular user, she needs to be aware that functions performed under the `Admin' menu have potentially global effects, and must exercise according care in the execution of the functions.

The Admin options are viewable by regular users but settable only by system admins, so they're described here in this section of the requirements.

2.6.7.1. Administrative Options

A bit of rationale: Since we're nixing pencil in, there was a bit of thought just now that group leaders may not be all that necessary. However, there are other useful reasons to have them. Also, I think it's reasonable to say that group leaders are the only ones who can schedule meetings for which online notification will be sent by the tool. So in effect what we've done is demote pencil power in to notify power.

With that bit of rationale, here are the group leader privileges as we currently see them:

1. Meeting notifications sent to attendees.
2. Cancellation notice sent we group leader deletes a meeting; deleted for non- recurring, marked as CANCELLED for recurring (maybe, or probably better just to nuke it or maybe make this an option).
3. Can add and remove members for group.

For any or all users and groups, can cap the number of items for that user that are stored in the central calendar. When the cap is reached, items are removed such that an equal number of items, +/-1, appear before and after today's date. Notification is sent to the user when the cap is reached, including an annoying message every time it changes, which means the user either has to do something to clear out old crap or ask the admin to increase the cap.

Changing the cap size to a value smaller than the current number of items effectively executes a purge operation.

2.6.7.1.4. Platform-Dependent Options

Although we'd like to avoid it, it may be necessary to at least plan for platform-dependent options that may be needed for networking connections. If at all possible, I'd like to avoid these. They sound like a cop out to me.

2.6.7.2. 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.