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


Figure 198: Password entry dialog.



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


Figure 199: 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.

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.


Figure 200: User database dialog.



The scrolling area and search field operate in the same manner as described in 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 201.


Figure 201: Add user dialog.



The dialog contains all of 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 200 are formatted as follows:
last, first middle
The comma and spaces are absent if there are no first and middle names.

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.


Figure 202: Adding a new user.



The password is echoed as typed in the add-user dialog, in contrast to the user editing dialog, where it is shown only as asterisk characters. When the administrator presses `OK' in the add-user dialog, the system performs the following actions:

  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.

Figure 203: New user notification message.



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


Figure 204: Brandon selected in users list.



Only one user can be selected at a time. When the administrator presses `View ...' in Figure 204, the system displays the dialog of Figure 205.


Figure 205: 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 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.


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



The edits are to the 'Email', `Phone', and `Password'. When the administrator changes the Password, the new password is echoed as the actual characters typed, not as asterisks. After the administrator confirms the change, the password is subsequently displayed as asterisks.

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


Figure 207: 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. 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.

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



The notification message lists the specific details of the change.

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.


Figure 209: Confirmation dialog for deleting a user record.



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

  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.
The notification message is of the form shown in Figure 210.


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.

Figure 210: 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 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.


Figure 211: Group database dialog.



This dialog has the same basic format as that for the user database in Figure 200. The `Search by' field operates in the same manner as in the user database dialogs. One group is built-in to the Calendar Tool: the all group consisting of all registered users.

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


Figure 212: 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. That is, no two or more groups can have the same ID, and no group can have the same ID as any user. The `Size Limit' specifies the maximum size in megabytes of the group calendar in the central host repository.

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.


Figure 213: 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 214.


Figure 214: 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 The administrator can view the list of all available user and group IDs in the database dialogs of Figures 200 and 211, respectively. 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.

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.


Figure 215: Add group member dialog filled in.



The first row of IDs are 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 super group. There is no limit on the depth of the super group hierarchy. That is, a super group can have one or more super groups 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.

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.


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


Figure 217: 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 212.

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.


Figure 218: 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 219.


Figure 219: 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 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.


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

  4. notifies all added or deleted leaders of the change, via an on-screen dialog
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

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"
The group string is the group ID. The central host string is the name of the Calendar Tool central host computer on which the change or delete operation is performed, i.e., the central host on which the administrator is current running Calendar Tool Administration.

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 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"

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.


Figure 221: 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 222.


Figure 222: 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 223 shows the administrator having entered values for a new location record.


Figure 223: 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 224.


Figure 224: Book location dialog.



The `Use' field describes the use for which the location is booked. 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 . Pressing `OK' adds the booking to the `Bookings' list, if it does not overlap in time or date with any existing booking. The `Clear' and `Cancel' commands have the standard functionality.

Figure 225 is an example of a location booking.


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



In this example, the booking is the first to be added, so no overlap occurs. If the administrator attempts to add a booking that does overlap with an existing booking, either meeting or other usage, the system issues an appropriate error message as described in Section . A booking overlap 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 221 and presses `View ...'. For example, Figure 226 shows the result of the administrator viewing the second listed location in Figure Figure 221.


Figure 226: Viewing a location record.



The location record dialog has exactly the same data fields as the add-location dialog shown in Figures 222 and 223. 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 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.


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



None of the data fields is editable in the displayed meeting item. Figure 228 shows the result of `View ...' for the third booking listed, which is a non-meeting.


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



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.


Figure 229: Central host status dialog.



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.


Figure 230: Central host status not running.



When the server is running, the `Start Server' command button is disabled and the `Stop Server' button is enabled. The buttons are in opposite states when the server is not running.

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.


Figure 231: Confirmation for stopping the central host server.



The administrator can choose to stop the server immediately or in a specified number of minutes, between 1 and 999. The default is in 5 minutes. When the administrator presses `OK', the system responds by stopping the server immediately or scheduling the server to be stopped in the specified number of minutes.

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.


Figure 232: Notification that server will stop.



The dialog message explains when the server will stop and the effects of the stoppage.

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.


Figure 233: Notification that server has stopped.



In conjunction with the notification, the system performs the following actions on the local computer of all connected users:

  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.

2.6.5.2. Setting the Administrator Password

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.


Figure 234: Administrator password change dialog.



To effect the password change, the administrator 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. A password cannot be empty, but there is otherwise no restriction on the password value; it may be one or more characters that are legally typeable on the platform where the administration program is running.

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.


Figure 235: Email address dialog.



The current address is the default value when the dialog appears. The administrator can enter any other address and press `OK' to confirm the change, or `Cancel' to leave the address unchanged. The Calendar Tool Administration program validates the entered address insofar as is possible, as described in Section . Actual communication using this address is performed entirely through the services of an external email agent, the identity of which is specified as an option (see Section 2.7.5 ). If the administrator enters an incorrect or invalid address that cannot be identified as such in advance, this situation is made evident to the user through whatever behavior the external mail program exhibits given the incorrect or invalid address.

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 236: Notify users dialog.



The administrator enters the desired message text and chooses whether to deliver the notification in an on-screen dialog, in an email message, or both. At least one of the two forms of delivery must be selected.

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


Figure 237: A notification about central host maintenance outage.



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.


Figure 238: Size limit set in a user record.



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.


Figure 239: Host calendar truncation notification, after size limit change.



The dialog explains the change and the effects it has the user's host calendar. The notification is sent immediately after the administer confirms the size limit setting with the `Change' command in user record dialog. Also, the item deletion actions explained in the message are performed immediately upon confirmation of the size change. If the user is not currently connected to the host, the notification is queued and subsequently delivered to the user the next time she connects, as explained in Section 2.6.5.4.

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 third and fourth paragraphs of the notification are the same as in Figure 239 As explained in the notification message, the system reduces the size of the user calendar by 20%, in order to achieve a workable calendar size.

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.


Figure 240: Host connection dialog.



The host-connection dialog contains a table that associates Calendar Tool central host computers with local calendar files. The rightmost column in the table indicates which hosts are currently connected. By default, there are no pre-defined entries in the table.

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.


Figure 241: Add host dialog.



The `Host Address' field is the unique network address of the Calendar Tool central host computer to be connected. The format of the address is platform-dependent, based on the type of network to which host computers are attached. IP address is a typical format. `Calendar File' contains the name of the local calendar file to be associated with the specified host. If a leading file path is not specified in the calendar file name, then the file is assumed to be in the local files directory defined using the `Local Files' command, described in Section .

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.


Figure 242: Defining a host table entry.



In order to enter the proper ID and password values for the specified host, the user must have been notified by the host administrator when the user record was created, as explained in Section 2.6.2 The ID and password values entered in this dialog become part of the host table entry for the specified host. This information is stored on the user's local computer. When the user initiates a connection to the host, the ID and password in the local table entry are matched against the ID and password in the user's database record stored on the host. This matching is what validates the connection. The complete details of the connection process are described momentarily.

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.


Figure 243: Host connection table with new entry added.



Note that the ID, password, and auto-connect values do not appear in the host table display. These values are accessible in the add (and change) entry dialogs. The system does not validate any of the entered values in the add-host dialog, other than to require that all data fields are non-empty. Complete validation is performed when the user initiates a connection, as explained next. Note also that the `Save' button is enabled now that an entry has been made. Details of `Save' are covered following the discussion of making connections.

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.


Figure 244: Host selected in table.



To initiate the host connection, the user presses the `Connect' button. In response, the system performs the following validation actions:

  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
If the validation actions succeed, the system proceeds to establish the connection and performs the following actions:

  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.



Figure 245: Host connection established.



The system also performs actions b and c any time the user subsequently saves the connected calendar; further details save commands are covered in Section 2.8.4.

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


Figure 246: Host connection with additional entries.



The specific rules for multiple calendar/host associations are the following:

  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
Figure 246 illustrates the case where the user has associated the same calendar with two different hosts. The DepartmentCalendar is associated with both the campus ... host and deptsrv ... hosts. The utility of such multi-host-to-calendar associations is discussed further in Section . As the user adds each new table entry, the system keeps the table rows sorted by host address in ascending lexical order.

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.
The user cannot select more than one entry in the table at a time.

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
The definition here of "same user" is based on Calendar Tool user ID.

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.
When the current calendar is not associated with a connected host, or there is no current calendar, then only the `Connect' and `Contact Admin' items are enabled in the `Admin' menu.

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.


Figure 247: Regular user viewing the Users database.



The regular view of the user database displays the same information as the privileged admin user database dialog in Figure 200, with the following two differences:

  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.
Aside from these differences, the functionality of the regular-user database display is the same as the privileged admin database dialog, including the searching, sorting, and viewing functionality.

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.


Figure 248: Regular user viewing a user database record.



This display shows precisely the same information as Figure 205, without any of the command buttons at the bottom of the window. Also, as with the regular-user database display, the banner of the user record display is suffixed with the name of the host on which the user database resides.

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.


Figure 249: Regular user password change dialog, for a central host password.



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.


Figure 250: Host request dialog.



The user must enter a valid central host network address in order to proceed. In this context, a valid address is that of a network-accessible computer that is running a Calendar Tool central host server. If the user enters an invalid address, the system displays a failure dialog with the message "The entered host address is not valid.", in response to which the user can dismiss the failure dialog and re-enter a valid host address. There is no limit to the number of retries the user may perform.

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 251: Contact admin dialog.



When the user presses `Contact', the system launches an external email program, with an empty email message addressed to the indicated email address. The name and location of the external email program are set as a user option, as described in Section 2.7.5. After the external email program is launched, the system removes the contact dialog. The email program and Calendar Tool program then execute entirely independently and asynchronously. All subsequent communication through the external email program is outside of the control of the Calendar Tool.

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

Figure 252: Typical admin request.



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.

2.6.7. Limitations on Administrator Privileges

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.




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