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 administrative commands for configuring and connecting to Calendar Tool central host computers, and for performing other managerial functions.

As described in Section 2.1, there are two separate interfaces to administrative commands, provided by two separate application programs. Regular users access administrative commands through the regular Calendar Tool interface, shown in Figures 1 and 2. Users with administrative privilege can run the Calendar Tool Administration program, through the interface shown Figures 3 and 4.

Calendar Tool databases are physically stored on designated central host computers. Administrative users run the Calendar Tool Administration program on a central host. Regular users run the Calendar Tool program on their local client computers and connect to a central host via a computer network. A user's local computer may be physically the same machine as a central host, but logically the function of local computer and central host are distinct.

The sole purpose of the Calendar Administration program is to manage the databases and communication services on a central host. The administration program provides no commands for calendar scheduling or viewing. Any computer on which the Calendar Tool Administration program is installed can function as a central host, as long as that computer has proper network access to the client computers of Calendar Tool users.

The purpose of administrative commands for the regular user is to connect to central hosts, view the Calendar Tool databases, and perform other limited administrative functions. Since the database repository resides on a central host computer, the regular user must establish a central host connection in order to have access to administrative data. Details of establishing host connections are covered in Section 2.6.6.1. Before a host connection is established, only the `Connect' and `Contact Admin' commands are enabled in the regular-user Admin menu. Once a connection is established, the other commands become enabled.

In the scenarios to follow, use of the Calendar Tool Administration program is covered in Sections 2.6.1 through 2.6.5. Access to administrative commands by regular Calendar Tool users is covered in Section 2.6.6. Further details on the Calendar Tool multi-user environment, consisting of local clients and central hosts, are covered in Section .

2.6.1. Gaining Administrative Access

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

At any given time, there is a single legal administrative password for a particular installation of the Calendar Tool Administration program. Given this, the definition of "administrative privileges" is simply the knowledge of the current administrative password. Section covers installation procedures, including establishing the initial administrative password.

Whenever an administrator invokes the Calendar Tool Administration program, the computer on which the invocation takes place is considered to be the Calendar Tool central host for the purposes of all subsequent administrative commands. The name of the host computer is displayed in the banner of the Calendar Tool Administration menubar, as shown in Figures 3 and 4.

2.6.2. User Database

As shown in Figure 3, the default administrative interface consists of a menubar and a dialog for accessing the Calendar Tool user database. The same dialog is displayed when the administrator selects the `Users ...' item in the `Admin' menu. Figure 200 shows the state of the user database after a number of user records have been added.

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

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. That is, no two or more users can have the same ID, and no user can have the same ID as any user group. The `Password' is required along with the ID when the user establishes a connection to the central host. The password is encrypted using a suitably secure encryption mechanism.

The `Email' address is optional, but highly recommended. It is the electronic mail address to which meeting notifications and other general notifications are sent. The phone number is also optional; it can be provided as an additional means for communicating with a Calendar Tool user, outside of the context of the Calendar Tool itself.

The `Calendar Size Limit' specifies the maximum size in megabytes of the user's calendar on the Calendar Tool central host. Its value is a real number. The limit value is optional. If it is absent, there is no limit. The size limit can be zero, in which case the user has an empty, and therefore unusable calendar on the central host. Complete details on central host data storage are covered in Section .

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

1. validates that the Calendar Tool ID is unique among all extant users and groups;

2. validates the email address insofar as is possible (see Section for details);

3. adds the new user record to the user database, if the validation checks succeed

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

5. adds the new user's ID to the All Users group, as described further in Section 2.6.3.

6. notifies the new user of the addition via the electronic mail address in the user record; if an email address is not provided, then the administrator must notify the user via some form of communication outside of the Calendar Tool.

The new-user notification message is of the form shown in Figure 203.

You have been added as a new registered user on the Calendar Tool
central host computer deptsrv.csc.calpoly.edu.  Your registration
information is as follows:

    Name: Richard Anderson
    ID: randerso
    Password: Mx13duV0

To view your complete user record, connect to this host using the
Calendar Tool `Admin->Connect' command, then select the `Admin->Users'
command, and then select your name or ID in the list of registered
users.  As soon as you establish the initial connection, it is highly
recommended that you change your initial password using the
`Admin->Password' command.

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

The user record dialog has all of the data fields present in the add-user dialog. 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 206 shows the results of the administrator having performed edits to the user record for James L. Brandon.

When the administrator presses `Change', the system displays the confirmation dialog in Figure 207.

1. if the email has changed, validates the address insofar as is possible (see Section )

2. updates the user record in the database

3. notifies the affected user of the change via the electronic mail address in the user record; if an email address is not provided, then the administrator must notify the user via some form of communication outside of the Calendar Tool.

4. if the size limit has changed, deletes items from the user's calendar on the central host repository, if necessary, to satisfy a changed size limit value; Section Section has further details on central repository size limits

5. if the password has been changed, redisplays its value as asterisks characters in the user record dialog

The user notification for the change confirmed in Figure 207 is shown in Figure 208.

The following information has been changed in your Calendar Tool user
record on central host deptsrv.csc.calpoly.edu:

    Password: from previous value
              to Mx28c91H

    Email: from jlbrando@calpoly.edu
           to   jim@onion.csc.calpoly.edu

    Phone: from 756-2416
           to   805 75601897

If you have questions about these changes, please contact a Calendar
Tool administrator on this host using the `Contact Admin' command.

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

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

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

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

5. notifies the user of the deletion via the electronic mail address in the user record; if an email address is not provided, then the administrator must notify the user via some form of communication outside of the Calendar Tool.

You have been deleted as a registered user of the Calendar Tool system
on host deptsrv.csc.calpoly.edu.

You can continue to use the Calendar Tool to manage your own local
calendars, and to manage Calendars on any other central hosts where
you are registered.

If you have questions about this action, please contact a Calendar
Tool administrator.

Deleting a user does not delete the user's ID from any meeting attendees lists on which it appears. Meeting attendee lists can be manually edited, as described in Section 2.5.2.2.

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.

It is worth noting that all the notifications for user database operations are sent via email, not via on-screen dialogs. The reason is that in each case, the user cannot or may not be able to view an on-screen notification, because in order to do so the user must be connected to the central host from which the notification originates. In the case of addition, the user does not yet know the user ID that must be provided to establish a connection to the originating host. In the case of a change, the notification will not be deliverable on-screen if the action is a password change. In the case of delete, the user's ability to establish a connection to the originating host has been terminated, which again makes the user unable to see an on-screen notification originating from that host.

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

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

The `Members' and `Leaders' lists contain the 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, i.e., administrators may delete dormant and leaderless groups if they so choose. 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 213 shows the administrator having entered values for a new group.

Duplicate IDs are ignored by the system. The precise definition of group membership is the set of entered IDs, with duplicate IDs considered to be a single member. The rationale for allowing duplicates in the members list is to avoid complexity when entering (super)group members, as described just below.

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

Circularity is disallowed in supergroup definition. That is, a group may not contain itself as a member, either directly or indirectly.

When the user presses `OK' in Figure 214, the system validates all entered IDs and checks for any circularity in a supergroup definition. If one or more IDs are invalid or a circularity is detected, the system issues an appropriate error message as described in Section . 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 216 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 211 and then presses the `View ...' button. For example, Figure 217 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 218.

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 the 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 220.

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, via an on-screen dialog

4. notifies all added or deleted leaders of the change, via an on-screen dialog

You have been actioned
the group Calendar Tool group.

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

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 administrator executes `Delete' for a group record, the system displays the same form of confirmation dialog as shown in Figure 220, 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, i.e., all users who were a member and/or leader of the deleted group

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

It is important to note that 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 specific commands for a user to request addition to or removal from a group. Such requests can be made using the Calendar Tool `Contact Admin' command, or by some means outside of the Calendar Tool.

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

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

1. the title of a scheduled meeting

2. the description of some other usage

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

Figure 225 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 221 and presses `View ...'. For example, Figure 226 shows the result of the administrator viewing the second listed location in Figure Figure 221.

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 central host copy of the meeting 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.

Figure 227 shows the result of `View ...' for the second booking listed in Figure 226, which is a scheduled meeting.

Since an other-usage booking is for a contiguous time period, it takes multiple bookings to define discontinuous usages. For example, the `Morning Classes' booking in Figure 226 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 administrator 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'. The edits must comply with the same data-entry rules described after Figure 224 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 Privileged Admin Commands

In addition to maintaining Calendar Tool databases, the administrator can perform commands to configure the central host computer and perform other managerial functions. Scenarios follow.

2.6.5.1. Administrative Control of the Central Host Server

When the administrator selects the `Host Status' command in the privileged Admin menu, the system displays a dialog of the form shown in Figure 229.

The dialog shows the status of the Calendar Tool server and if running, how many users are connected. The Calendar Tool server is an independently-executing program that handles user communication with the central host. The server program runs on the same host computer where the administrator is running the Calendar Tool Administration program. The host name shown in the banner of the dialog is the unique network identification of that central host. This is the identification employed by users to establish a central host connection. Complete details on the function of the server program are presented in Section .

In the case of Figure 229, the status of the server is running, with 13 Calendar Tool users connected. When the server is not running, the host-status dialog appears as shown in Figure 230.

The start and stop buttons control the execution status of the server. When the administrator presses `Start Server', the system responds by invoking the server program on the current host and updating the status dialog message from "not running" to "running" with "0 users connected". Also, the enabled/disabled states of the command buttons are swapped, so that the stop button becomes enabled.

When the administrator presses `Stop Server', the system responds with the dialog shown in 231.

When the administrator chooses to stop the server in some number of minutes, the system notifies all connected users with an on-screen notification of the form shown Figure 232.

When the time comes for the server to stop, either immediately or after the specified number of minutes have elapsed, the system notifies all connected users with the dialog shown in Figure 233.

1. updates the display in the central host connection dialog ( Section 2.6.6.1) to show the host as not connected;

2. immediately terminates any meeting-scheduling operations for the host and removes all windows associated with meeting scheduling for the host;

3. immediately terminates any administrative commands for the host and removes all windows associated with administrative commands for the host;

4. removes all display windows for the calendars of other users and groups on the host;

5. if the user is not connected to any other host, disables all items on the `Admin' menu except `Connect' and `Contact Admin', and disables the `Other User' and `Group' items in the `View' menu.

As noted in the introduction, there is a single administrative password for any given installation of the Calendar Tool Administration program. The password is set when the program is initially installed ( Section ), and may be changed any time thereafter. To do so, the administrator selects the `Password' item in the `Admin' menu, whereupon the system displays the dialog shown in Figure 234.

When the administrator presses `OK', the system confirms that the current password is correct and that both versions of the new password are identical. If so confirmed, the system changes the password for all subsequent administrator access. If the current password is incorrect or the versions of the new passwords differ, the system displays an error dialog to that effect, upon dismissal of which the user can try again.

It is the responsibility of an administrator who changes the password to notify any other individuals who need to be aware of the change. The Calendar Tool provides no means to perform this notification.

2.6.5.3. Setting the Administrator Email Address

Regular Calendar Tool users can contact an administrator using the `Contact Admin' command described in Section 2.6.6.5. The contact is made through an electronic mail address for the Calendar Tool administrator(s) on a particular host. The address is any legal email address which the administrator(s) designate as the contact point for administrative communication. It can be an address specifically created for Calendar Tool administration or the address of some individual administrator.

The email address is set when the Calendar Tool Administration program is initially installed ( Section ), and may be changed any time thereafter. To do so, the administrator selects the `Email' item in the `Admin' menu, in response to which the system displays the dialog shown in Figure 235.

The creation of the address itself as a valid electronic mail destination is beyond the scope of Calendar Tool Administration. The address must be created by the staff of the underlying operating environment or some other individual who has the capability to create a valid and usable email address.

2.6.5.4. Notifying Users

Preceding scenarios have described a variety of notifications sent to Calendar Tool users to inform them of significant administrative actions. The administrator can also send a general-purpose notification to all registered users with the `Notify Users' command. When the administrator executes this command, the system displays the dialog in Figure 236.

Figure 237 shows the administrator sending a notification that the central host computer will go down for scheduled maintenance.

Unlike meeting notifications ( Section 2.4.1.5 ), there is no user option to disable on-screen administrative notifications. This includes all administrative notifications, whether sent with the `Notify Users' command, or as the result of executing any of the other administrative commands that generate the notifications. On-screen administrative notifications appear immediately for all affected users who are connected to the originating host at the time the notification is sent. When a user is not connected, the notification is queued for display the next time the user connects to the originating host, as described in Section 2.6.6.1. Aside from the fact that administrative notifications cannot be refused, the queue of pending administrative notifications is managed in the same way as the meeting notification queue described in Section 2.4.1.6.8. All administrative notifications are kept in a separate queue, the complete contents of which are displayed to a connecting user before any meeting notifications are displayed.

The Calendar Tool Administration program provides no command specifically for communication with individual users. Individual communication occurs when notifications are sent to users as a result of administrative commands that generate the notifications. An administrator can reply via external email to an individual message sent with the `Contact Admin' command ( Section 2.6.6.5 ). An administrator can also send an individual email message to any user, by way of the email address listed in a user's database record. However, the Calendar Tool Administration program provides no command to launch an email program for this purpose. The administrator can use the copy and paste facility of the underlying operating environment to copy the address from the database record and paste it into the external email program.

2.6.5.5. Setting Calendar Size Limits

As explained in Section 2.8.8, the central host repository contains a copy of each registered user's calendar and the only copy of each group calendar. As explained further in Sections 2.6.6.1, and Section 2.8.4, the system copies the user's local calendar to the central host when the user initially establishes a host connection and whenever the user saves the calendar while connected.

The reason that user and group calendars on the host are stored in individual files is so the administrator can ascertain the size of each calendar using the normal file-size commands available in the underlying operating environment. In this way, if a user or group file exceeds a size that can be supported on a given host, the administrator can limit the file size by setting the value of the `Calendar Size Limit' component in the user and group records. For example, Figure 238 shows the administrator having set the size limit to 10 Mbytes for user James Brandon.

For a typical implementation of the Calendar Tool, it is expected that the size of calendar data files will remain manageably small, unless they contain a particularly large number of scheduled items. Nevertheless, it is necessary for an administrator to be able to cap the size of user calendars as needed on a particular host.

When the administrator sets the size limit for a user's calendar, the user is not notified of the setting unless the current size of the user's host calendar is greater than the limit. The user can view the size limit at any time by viewing her user record in the database.

In the case where the current size of the user's host calendar is greater than a changed size limit, the system notifies the user with an on-screen dialog of the form shown in Figure 239.

The other circumstance that leads to user notification of a size limit is when the user adds scheduled items to a calendar such that the addition causes the host calendar size limit to be exceeded. This case arises when the user saves the local calendar file when connected to the host, or establishes a host connection after having added items locally while not connected. When one of these actions occurs, the system notifies the user with the same form of dialog as shown in Figure 239, but with the text of the first two paragraphs of the message changed to the following:

The size of the local calendar just transmitted to the host
exceeds the calendar size limit for the host.

To satisfy the required limit, your host calendar has been
reduced to 8 megabytes, which is 20% smaller than the set limit.

The circumstance that leads to an automatic size-limit change in a group calendar is when a group leader schedules a meeting that cause the size of the group calendar to be exceeded. In such a case, the system reduces the size of the group calendar using the same 20%-reduction procedure as for a user calendar. No notification is sent to anyone if the size limit is changed on a group calendar, not even the group's leader.

2.6.6. Regular User Access to Admin Commands

As noted in the introduction, only the `Connect' and `Contact Admin' commands are enabled in the regular-user Admin menu, prior to establishing a host connection. Once connected, the user can perform all administrative commands in the regular user interface, as presented in the scenarios that follow.

2.6.6.1. Central Host Connections

To connect to a central host, the user selects the `Connect' command in the `Admin' menu. In response, the system displays the dialog in Figure 240.

The association of a central host computer with a local calendar file is a fundamental feature of Calendar Tool networking. As explained in the introduction, regular users run the Calendar Tool on local computers, where their calendar files are stored. To support multi-user calendar sharing, there are Calendar Tool central host computers to which users can connect. When a user is connected to a particular host, the associated calendar is the user's "portal" onto that host. When a user connects to the host, a copy of the associated local calendar is sent to the host. When another user schedules meetings on the host, the meeting is penciled in on the associated calendar. Further discussion on these and other aspects of Calendar Tool networking appears in Section .

With an initially empty host table, as in Figure 240, the only enabled command buttons are `Add ...' and `Cancel'. The other buttons become enabled as table entries are added. To add a new entry, the user presses `Add ...', in response to which the system displays the dialog in Figure 241.

The `User ID' and `User Password' fields contain the Calendar Tool ID and password for the user on the specified host. These values must match the ID and password values defined by the host administrator in the user's database record (see Section 2.6.2 ).

The last field in the add-host dialog is `Auto-Connect on File Open'. The setting of this field specifies whether or not the system initiates a connection to the host when the associated calendar file is opened. This is the same option value that appears in the `Admin' tab of the `Administrative' options dialog, described in Section 2.7.5. The setting also appears in the add-host dialog, as a convenience. When the user changes the option setting here, the system changes it to the same value in the options dialog, and vice versa.

Figure 242 shows the user having entered typical values for a host table entry.

The user presses 'OK' in Figure 242 to confirm the addition of the host table entry, after which the system removes the add dialog from the screen and updates the host connection table as shown in Figure 243.

Once at least one host is in the table, the user can initiate a host connection. To do so, the user selects the host by clicking on the desired row in the table. In response, the system highlights the row and enables the `Connect', `Change', and `Delete' buttons, as shown in Figure 244.

1. verifies that the host is accessible on the network and is currently running a Calendar Tool server (see Section 2.6.5.1 );

2. verifies that the user ID and password in the host table match those of a registered user on the host;

3. verifies that the file associated with the host is an existing Calendar Tool file on the local computer that is readable and writable by the user

1. opens the associated calendar file if it is not already open;

2. copies all new penciled-in meetings from the host calendar to the associated local calendar;

3. copies the entire local calendar, including the new pencil-ins, to the host, thereby making the local and host copies of the calendar identical;

4. processes all pending notifications, as described in Sections 2.4.1.6.8, 2.5.2.2.9, and 2.6.5.4;

5. in the host table: marks the host as connected; unhighlights the newly connected host; disables the `Connect', `Change', and `Delete' buttons, all as shown in Figure 245.

The set of new penciled-in meetings is comprised of all those penciled in on the central host calendar that have not yet been copied to the local calendar. The contents of this meeting set is determined by the setting of the pencil-in acceptance option on the host copy of the calendar when the meeting is scheduled. Details of the pencil-in acceptance option are described in Section 2.4.1.5 The three possible cases for copying new penciled-ins are the following:

• If pencil-in is accepted whenever connected to the host, then the set of new penciled-in meetings at the time of establishing a connection consists of all those meetings penciled in since the user last disconnected from the host.
• If pencil-in is accepted only at initial connection to the host, then the set of new penciled-in meetings at the time of establishing a connection consists of all those meetings penciled in since the user last connected to the host, or since the user last executed the `Get now' command in the Scheduling Meetings Options tab (see Section 2.7.3.3 ), whichever occurred most recently.
• If pencil-in is never accepted, then the set of new penciled-in meetings is empty at the time of establishing a connection.

If any part of the connection validation process fails, the system issues an appropriate error message, as described in Section .

The user can add multiple entries in the host table. For example, Figure 246 shows the user having added three more entries, and having established another connection.

1. the same host address cannot appear more than once in the table, where "same" means lexically equal as strings

2. more than one host can be associated with the same calendar, but at most one of the same-calendar hosts can be connected at any given time

To change or delete a host table entry, the user selects the entry of an unconnected host. In response, the system enables the `Change' and `Delete' buttons. A host entry cannot be changed or deleted when the host is connected. When the user selects a connected host, the system enables the `Disconnect' button, leaving the `Change' and `Delete' buttons disabled.

When the user presses `Change', the system displays the same dialog used to add an entry (Figures 241 and 242 ), with the word "Add" in the window banner replaced with "Change". The current values of the selected table entry are displayed in the change dialog. The user can make any changes, except that none of the data fields can be empty. As the user confirms each new table entry change, the system keeps the table rows sorted by host address in ascending lexical order.

When the user presses `Delete', the system displays a confirmation dialog with the message "Are you sure you want to delete the selected host table entry?", with an `OK' button to confirm the delete and `Cancel' button to cancel it.

When the user presses `Disconnect' (after having selected a connected host in the table), the system displays a confirmation dialog with the message "Are you sure you want to disconnect from the selected host?", with an `OK' button to confirm the disconnect and `Cancel' button to cancel it. Disconnection does not close the associated calendar, however the converse is true. That is, closing the calendar associated with a connected host performs a disconnect with that host, as described in Section 2.8.3.

When the user presses the enabled `Save' button, the system saves the contents of the host table into the Calendar Tool Settings file. Only the host table portion of `Settings' is affected by this save, with all other portions of the settings file left unchanged. Details of Settings file contents and related commands are covered in Sections 2.8.1 and Unsaved changes can also be saved using the `Save Settings' command in the `File' menu, as described in Section .

When the user presses `Cancel', the system clears any unsaved changes to table entries that are not connected, and removes the dialog from the screen. Unsaved changes to connected table entries are unaffected by `Cancel', and reappear in their pre-cancel state if the user re- executes the `Admin->Connect' command.

The following is a summary of the button states in the host connection table, based on what if any entry the user has selected:

1. When no entry is selected, including the case where the table is empty, only the `Add' and `Cancel' buttons are enabled.

2. When an unconnected entry is selected, the `Change' and `Delete' buttons are enabled; `Add' and `Disconnect' are disabled; `Connect' is enabled if the selected host is not connected with another calendar in the table; `Cancel' is enabled.

3. When a connected entry is selected, only `Disconnect' and `Cancel' are enabled.

4. `Save' is enabled whenever the user has edited one or more fields so that the values are different that those most recently savd.

To enforce the calendar/host association rules fully, the Calendar Tool server program prohibits more than one connection at a time from the same user to the same host. While the intent of the association rules is to prohibit this, they do not cover the following cases:

1. two different central host addresses in the connection table are actually the address of the same host computer, e.g., one is an IP number, the other a domain-qualified name;

2. the same user is running the Calendar Tool program more than once at the same time, on the same local computer or on two different local computers

When a user attempts to establish a second connection to a particular host, the system displays the error dialog described in Section . The Calendar Tool system does not prevent the same user from connnecting to two different hosts at the same time. That is, two different servers running on two different hosts do allow a single user to be connected to both hosts at the same time.

2.6.6.2. Defining the Current Host to Which Admin Commands Apply

Once the user establishes a host connection, the system enables the database and password commands in the regular-user `Admin' menu. Theses commands are host-specific, in that they apply to the particular central host that is current. For example, when the user selects the `Users' command in the `Admin' menu, the system displays the user database entries for the current host.

The definition of "current host" is the connected host that is associated with the current calendar. As defined in Section 2.3.6.4, the "current calendar" is the one at the top of the calendars list on which the user is currently operating. Hence, all commands in the regular-user `Admin' menu are enabled when the current calendar is associated with a host, and that host is connected. In summary, to make a host current, the user follows these steps:

1. defines an entry in the host connection table;

2. connects to the host;

3. makes the calendar associated with the host the current calendar.

Since the results of regular-user `Admin' commands are host-specific, they are displayed in separate windows for each host. For example, suppose the user views the user database for host A, then makes host B current, then selects the `Admin Users' command again. In response, the system displays a separate window for the user database of host B. The displays for all regular-user `Admin' command operate in this manner, with a separate display window for the results of each command, for each host. In effect, admin commands always operate in multi-window mode, as described in Section 2.3.6.2.3. The `Windowing Mode' setting in the `View' menu ( Section 2.3.6.2 ) does not apply to any admin commands.

2.6.6.3. Regular User Access to the Admin Databases

A regular user can view but not modify all three of the Calendar Tool databases. To do so, the user selects one of the top three commands in the regular-user `Admin' menu. For example, if the user selects the `Users' command, the system displays the dialog shown in Figure 247.

1. The banner of the display for the regular-user display is suffixed with the name of the host on which the user database resides.

2. The `Add' and `Cancel' command buttons are missing in the regular user display of the database.

To view a selected user record, the user selects the desired record in the user database display and presses `View'. In response, the system displays a dialog of the form shown in Figure 248.

In general, all regular-user database display windows have the host name in the window banner. Also, all regular-user database displays lack the following buttons when compared to the privileged administrator dialog versions of the displays: `OK', `Clear', `Cancel', `Add', `Change', and `Delete'. Without `Add' buttons, none of the data-entry dialogs for adding database information are available to regular users.

Normally in Calendar Tool display windows, uneditable data fields are shown in light-grey typeface and borders. This is not the case with the regular-user database displays, since none of the fields is ever editable, and they appear more readable in regular type and black borders.

Except for the password change command described in the next section, a regular user cannot edit any user, group, or location database record, including the user's own. The user can request that an administrator make a change by contacting the administrator with the `Contact Admin' command, described in Section 2.6.6.5.

2.6.6.4. Changing the User Password on a Central Host

A registered user's password is the only piece of information stored on the central host that the user can change directly. To change a host password, the user first makes current the host on which the change is to occur, as explained in Section 2.6.6.2. Then the user executes the `Change Password' command in the regular-user `Admin' menu. In response, the system displays the dialog in Figure 249.

To effect the password change, the user enters the current password, a new password, and then reenters the new password to confirm. As all password values are typed, they are echoed as asterisk characters, not as the actual characters typed. When the user presses `OK', the system confirms that the current password is correct and that both versions of the new password are identical. If so confirmed, the system changes the password in the user's database record on the host, as well as in all affected entries in the host connection table (see Section 2.6.6.1 ). An affected entry in the host connection table is one in which the current host is listed as the value of host address in the table entry.

If the current password is incorrect or the versions of the new passwords differ, the system displays an error dialog to that effect, upon dismissal of which the user can try again.

Some clarification on the storage of user password values is in order. For a regular Calendar Tool user, the value of a central host password is stored both on the central host as well as on the user's local computer where the Calendar Tool program runs. The password on the central host is stored in the user's database record. The host database record contains the defining value of the password, in that the host password value must be matched when the user initiates a host connection. A password value is also stored on the user's local computer in the host connection table, as described in Section 2.6.6.1. An entry in the local host connection table contains an accessing value of the password, in that this value is the one matched against the host-stored password value in order to validate a connection.

In terms of physical storage, the host password is stored in the user's database record, which is in turn stored in the Users component of the host central repository, as described in Section On the user's local computer, the password is stored in the host-connection table, which is saved permanently in the settings file, as described above.

2.6.6.5. Contacting an Administrator

The regular Calendar Tool user may need to contact an administrator for a number of reasons. The reasons include requesting a change to the user's database record; requests to be added or deleted from a Calendar Tool group; or requests for general information about the operation of the Calendar Tool in a particular installed environment. To make any such request, the user selects the `Contact Admin' command in the regular-user `Admin' menu.

As noted earlier, `Contact Admin' is enabled whether or not there is a current host connection. `Contact Admin' is still host-specific, like all other Admin commands. The system requests a host from the user if no host is current when `Contact Admin' is executed. Specifically, if the user executes `Contact Admin' when no host is current, the system displays the dialog in Figure 250.

When the user enters a valid host address in the request dialog, or when a host is current in the first place when the user executes `Contact Admin', the system displays the dialog in Figure 251.

Figure 252 shows the body of a typical email message that a user sends to an administrator.

Dear Admin:

I've changed my email address and phone number since the last time I used the
calendar program.  They are jim@onion.csc.calpoly.edu and (805) 756-1897.
Also, I've forgotten my password.  Can you tell me what it is or change it to
something new.

Thanks,
    Jim Brandon

The administrator's response to this particular request is described in the change scenario of Section 2.6.2. The user is notified of the change as discussed there, in particular Figure 208. Since users contact an administrator with an external email program, an administrator may reply to the contact directly via external email. Such communication is outside the control of the Calendar Tool. For managerial requests such as the preceding from user Brandon, the administrator need not reply externally to the request, since the Calendar Tool sends a change notification as part of the change process.

The following is a summary of the administrative communication services provided by the Calendar Tool and Calendar Tool Administration programs:

1. Regular users can contact administrators using the `Contact Admin' command, which in turn launches an external, independently-executing email program.

2. An administrator can send general notifications to all connected users with the `Notify Users' command; users receive these notifications in on-screen dialogs, email messages, or both (see Figure ).

3. Calendar Tool Administration sends notifications to affected Calendar Tool users when the administrator performs functions that require notification, as described in Sections 2.6.2 through 2.6.5.

As described in the preceding scenarios, Calendar Tool administrators have full access to the three Calendar Tool databases. They also have complete execution control over the Calendar Tool central host server.

Administrators have limited control over user calendars stored in the central host repository. By setting the `Size Limit' field in a user database record, the administrator can limit the number of items stored in the central host copy of a user's calendar. The administrator can also move or delete the files in which user calendars are stored.

Administrators have no direct control over the internal content of user calendars stored in the host repository. Specifically, administrators cannot add or change individual scheduled items in the calendars. The only deletion control is indirect, through the setting of the calendar size limit and the systematic deletion of items that may lead to, as explained in Section 2.6.5.5. Per the file encryption requirement described in Section 3.2.1, administrators cannot meaningfully view the contents of user calendar files, except by running the Calendar Tool in the normal way on the host computer. This prevents administrators, or any other users of the central host computer, from viewing the private portions of user calendars stored in the host repository.

Administrators have limited and indirect control over Calendar Tool operations on users' local computers. Specifically, when a local user is connected to a central host, notifications from an administrator are sent to and received by the Calendar Tool program running on the local computer. When using the Calendar Tool Administration program, administrators have no control whatsoever over the contents of Calendar Tool files stored on any users' local computers.

A Calendar Tool user who happens to be an administrator may run the regular Calendar Tool on a host computer to manage her own personal calendars and to schedule meetings for other users. When running the regular Calendar Tool in this way, the user is not considered to be a administrator at all. Further, the physical computer that happens to be a Calendar Tool central host is considered to be the user's local computer when running the regular Calendar Tool program. As explained in Section the distinction between central host computer versus local client computer is a logical distinction, in that the same physical computer can serve both functions. The precise definition of "administrator" is one who is running the Calendar Tool Administration program on any computer where the administration program happens to be installed.