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 the Calendar Tool central host computer 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 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. Except for the `Connect' command in the `File' menu, all regular-user administrative commands are in the `Admin' menu. All `Admin' commands except `Contact Admin' are disabled until the user establishes a connection to a central host.
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.14.
When a user invokes the Calendar Tool Administration program, the system
presents the password dialog shown in Figure 199.
Figure 199: Password entry dialog.
Figure 200: Password re-entry dialog.
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 2.15 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 Figure 3.
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 201 shows the state of the user database after a number of user
records have been added.
Figure 201: User database dialog.
To add a new user to the database, the administrator presses the `Add
...' button. In response, the system displays the dialog shown in Figure
202.
Figure 202: Add user dialog.
last, first middleThe 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.
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 item limit can be zero, in which case the user has an empty calendar, and therefore unusable calendar on the central host. Complete details on central host data storage are covered in Section 2.14.
Figure 203 shows the administrator having entered values for a new user.
Figure 203: Adding a new user.
The new-user notification message is of the form shown in Figure 204.
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 `File->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 204: New user notification message.
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 205 shows the
administrator having selected James L. Brandon for view.
Figure 205: Brandon selected in users list.
Figure 206: User database record for James L. Brandon.
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 207 shows the results of the administrator having performed edits to
the user record for James L. Brandon.
Figure 207: User record for James L. Brandon edited.
When the administrator presses `Change', the system displays the
confirmation dialog in Figure 208.
Figure 208: Confirmation dialog for changing a user record.
The user notification for the change confirmed in
Figure 208
is shown in Figure 209.
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 209: Notification of change to James L. Brandon user record.
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 210.
Figure 210: Confirmation dialog for deleting a user record.
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 211: Notification sent to deleted user.
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 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.
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 212.
Figure 212: Group database dialog.
To add a new group, the administrator presses `Add ...', whereupon the
system displays the dialog of Figure 213.
Figure 213: Add group dialog.
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. 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 214 shows the administrator having entered values for a new group.
Figure 214: Adding a new group.
Figure 215: Add group member dialog.
Figure 216 shows the administrator having entered IDs for the ceng
group.
Figure 216: Add group member dialog filled in.
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 215,
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 2.12.5.
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 217 shows the results of adding the `ceng' group members.
Figure 217: Add group dialog with members added.
To add one or more group leaders, the administrator follows mostly the same procedure as for adding members. The only difference is that the IDs of group leaders must be individual users, not groups.
At the bottom of the add-group dialog are `OK', `Clear', and `Cancel' buttons. These apply to the group as a whole. When the user presses `OK', the system adds the group to the database. `Clear' and `Cancel' have the normal functionality.
To view an existing group, the administrator selects the group name or ID in
the group database dialog of
Figure 212
and then presses the `View ...' button. For example, Figure 218 shows
the result of the user viewing the csfac group.
Figure 218: Group database record for the Computer Science Faculty.
To delete one or more group members, the administrator selects the name(s) in
the `Members' list and presses the `Delete' button
immediately below the list. To select multiple names for deletion, the user
holds down the SHIFT key as each name is selected in the list. In
response to executing `Members: Delete', the system displays a
confirmation dialog of the form shown in Figure 219.
Figure 219: Group member delete confirmation.
Figure 220: Members deleted in group record dialog.
To delete one or more group leaders, The administrator follows the same procedure as for member deletion. In the leader-deletion confirmation dialog, the word "member" is replaced by "leader".
The four command buttons at the very bottom of 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 221.
Figure 221: Confirmation dialog for changing a group record.
You have been actioned
the group Calendar Tool group.
If you have questions about this
please contact the Calendar Tool administrator at
central host
The actioned string is one of the following, as appropriate to the change(s) made:
"added as a member 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.
"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 221, with the word "change" replaced with "delete" in both the dialog banner and message text. When the delete is confirmed, the system
The Calendar Tool group group,
of which you were a affiliation,
has been deleted.
Change or deletion of a group record has no effect on any user calendars. In particular, no meetings scheduled with the group as an attendee are changed or deleted. Since deleted group IDs remain in scheduled items, system administrators must exercise good judgment in reusing the ID of a deleted group. If a deleted group ID is reused for a group with different membership, the extant appearances of the ID in user calendars will be misleading in terms of the users for whom the meeting was originally scheduled.
The Calendar Tool provides no 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.
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 222.
Figure 222: Location database dialog.
To add a new location, the administrator presses `Add ...', whereupon
the system displays the dialog of Figure 223.
Figure 223: Add location dialog.
Figure 224 shows the administrator having entered values for a new location
record.
Figure 224: Location database record.
Figure 225: Book location dialog.
Figure 226 is an example of a location booking.
Figure 226: A location booking for the Grad Student Room.
To view an existing location record in the database, the administrator selects
a location name or number in
Figure 222
and presses `View ...'. For example, Figure 227 shows the result of
the administrator viewing the second listed location in Figure
Figure 222.
Figure 227: Viewing a location record.
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
scheduler's calendar. If it is a recurring meeting, the displayed instance is
for the start date. When the viewed booking is for a non-meeting usage, the
system displays a booking dialog. For example, Figure 228 shows the result of
`View ...' for the second booking listed in
Figure 227;
Figure 228: Viewing a meeting from the location record dialog.
Figure 229: Viewing an other-usage booking from the location record dialog.
Since an outside-usage booking is for a contiguous time period, it takes multiple bookings to define discontinuous usages. For example, the `Morning Classes' booking in Figure 227 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'. 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.
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.
When the administrator selects the `Host Status' command in the
privileged Admin menu, the system displays a dialog of the form shown
in Figure 230.
Figure 230: 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 2.14.1.
In the case of
Figure 230,
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 231.
Figure 231: Central host status 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 232.
Figure 232: Confirmation for stopping the central host server.
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 233.
Figure 233: Notification that server will stop.
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 234.
Figure 234: Notification that server has stopped.
The central host data repository consists of three databases, registered user
calendars, and group calendars. The internal structure of repository data
files is implementation-dependent. The externally-visible names and
organization of the files is shown in Table 11.
| File or Directory | Usage |
| Users | User database file or directory |
| Groups | Group database file or directory |
| Locations | Location database file or directory |
| Calendars | Directory of user and group calendar files, with each root file name identical to the Calendar Tool user or group ID of its owner |
| Distributions | Directory of custom distributions (see Section 2.6.5.6 ) |
Table 11: Central Host Data Files.
When the Calendar Tool Administration program is installed, initial versions of these repository files and directories are created, as described in Section 2.15.4. The file and directory names shown in Table 11 are fixed. The three databases are either single files or directories organized in some implementation-specific manner. The Calendars directory must contain one file for each user and group calendar, with user or group ID as the root filename. The internal structure of the files and possible filename extensions is left to the implementors.
The repository files and directories are themselves stored in a single
directory, specified initially when the Calendar Tool Administration program is
installed. This superdirectory is the root of the entire central host
repository. If there are conventions in a particular operating environment for
where such application-specific files should be stored within the file system,
then such conventions can be followed during installation. After installation,
the administrator can change the location of the repository directory, if
necessary, using the `Host Files' command. When the administrator
executes `Host Files', the system displays the dialog shown in Figure
235.
Figure 235: Host files dialog.
The Calendars component of the repository contains a copy of each registered user's calendar and (the only copy of) each group calendar. As explained in Sections 2.6.6.1, and 2.8.2, 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's record. For
example, Figure 236 shows the administrator having set the size limit to 10
Mbytes for user James Brandon.
Figure 236: Size limit set in a user record.
For normal implementations 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 237.
Figure 237: Host calendar truncation notification, after size limit change.
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 237, 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 hostThe third and fourth paragraphs of the notification are the same as in Figure 237
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.
No notification is sent to anyone if the size limit is changed on a group calendar, not even the group's leader.
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 2.15.4
), 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 238.
Figure 238: Administrator password change dialog.
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.
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 2.15.4
), 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 239.
Figure 239: Email address dialog.
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.
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 240.
Figure 240: Notify users dialog.
Figure 241 shows the administrator sending a notification that the central host
computer will go down for scheduled maintenance.
Figure 241: 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.
The administrator can create customized distribution copies of the Calendar
Tool application program using the `Distribution' command. When the
administrator selects this command in the privileged `Admin' menu, the
system displays the dialog shown in Figure 242.
Figure 242: Distribution dialog.
The settings in the dialog allow the administrator to configure a version of the Calendar Tool program with pre-defined settings for important Calendar Tool parameters. The `Distribution name' is a descriptive identification of the distribution. When the yes selection is on for 'Include option settings', the distribution includes as pre-defined the option settings specified by the administrator at the time the distribution is created. Details of administrator option control are covered in Section 2.7.6. If `Include option settings' is no, then all options have their base default settings, as described in Section 2.7.7.
The setting of `Calendar connected to this host' constitutes a pre-defined entry in the host connection table described in Section 2.6.6.1. Specifically, the host-connection table in the distribution contains an entry that associates the specified calendar with the host on which the Calendar Tool Administration program is currently running. The value of `Local files directory' pre-defines the directory in which standard Calendar Tool files are saved on the local computer, as described in Section 2.8.7. The value of `Start-up calendar' is the name of the calendar file that is automatically opened when the configured version of the Calendar Tool is invoked from the operating environment, also as described in Section 2.8.7. Finally, the administrator can set the name of the application program that encapsulates the customized distribution, i.e., the name by which the Calendar Program is invoked from the underlying operating environment.
Figure 243 shows the administrator having defined a typical customized
distribution.
Figure 243: Distribution dialog with typical settings.
When the administrator presses `OK' in the distribution dialog, the system creates a distribution of the specified name in the Distributions directory of the repository (see Section 2.6.5.2 ). The distribution consists of the configured application program and any necessary installation support files (see Section 2.15 ). Once created, a customized distribution is installed by a regular user following the installation procedures described in Section 2.15.
The main purpose of a customized distribution is to make installation and initial activation of the Calendar Tool as easy as possible for a new user. The distribution defined in Figure 243 has the following ease-of-use features:
As noted in the introduction, a regular user must be connected to a central host computer in order to perform all but one of administrative commands. The only administrative command available without a connection is `Contact Admin'. Once connected, the user can perform all administrative commands in the regular user interface, as presented in the scenarios that follow.
To connect to a central host, the user selects the `Connect' command
in the `File' menu. In response, the system displays the dialog in
Figure 244.
Figure 244: Host connection dialog.
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 2.14.
With an initially empty host table, as in
Figure 244,
the only enabled command button is `Add ...'. 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 245.
Figure 245: Add host dialog.
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 246 shows the user having entered typical values for a host table entry.
Figure 246: Defining a host table entry.
The user presses 'OK' in
Figure 246
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 247.
Figure 247: Host connection table with new entry added.
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 248.
Figure 248: Host selected in table.
Figure 249: Host connection established.
If any part of the connection validation process fails, the system issues an appropriate error message, as described in Section 2.12.12.
The user can add multiple entries in the host table. For example, Figure 250
shows the user having added three more entries, and having established another
connection.
Figure 250: Host connection with additional entries.
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 245 and 246 ), 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.1.
The following is a summary of the button states in the host connection table, based on what if any entry the user has selected:
Once the user establishes one or more host connections, all commands in the regular-user `Admin' menu can be used 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:
The commands in the regular-user `Admin' menu are host-specific, in that they apply to a particular central host. Specifically, when `Admin' commands are enabled, they apply to the current host. For example, when the user selects the `Users' command in the `Admin' menu, the system displays the user database entries for the current host.
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.
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 251.
Figure 251: Regular user viewing the Users 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 252.
Figure 252: Regular user viewing a user database record.
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.
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 253.
Figure 253: 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 2.6.5.2 On the user's local computer, the password is stored in the host-connection table, which is in turn stored in a local administrative file, as described in Section 2.8.7. There is no explicit Save command for the host-connection table. The system saves the table in the local administrative file whenever the user confirms an add, change, or delete operation for the host table.
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 the only administrative command
that 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 254.
Figure 254: Host request dialog.
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 255.
Figure 255: Contact admin dialog.
Figure 256 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 256: 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 209. 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:
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 item size limit and the systematic deletion of items that may lead to, as explained in Section 2.6.5.2. Per the file encryption requirement described in Section 3.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 2.14
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.