19,20c19,20 < for configuring and connecting to Calendar Tool central host computers, and for < performing other managerial functions. --- > for configuring the Calendar Tool central host computer and for performing > other managerial functions. 60,65c60,64 < 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 --- > 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 69,72c68,71 < 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. --- > 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. 100c99 < presents the password dialog shown in Figure 198. --- > presents the password dialog shown in Figure 199. 109c108 <

Figure 198: Password entry dialog.

--- >

Figure 199: Password entry dialog.

121c120 < presenting the dialog of Figure 199. --- > presenting the dialog of Figure 200. 130c129 <

Figure 199: Password re-entry dialog.

--- >

Figure 200: Password re-entry dialog.

154c153 < Administration menubar, as shown in Figures --- > Administration menubar, as shown in 156,160c155 < 3 < < and < < 4. --- > Figure 3. 176c171 < menu. Figure 200 shows the state of the user database after a number of user --- > menu. Figure 201 shows the state of the user database after a number of user 186c181 <

Figure 200: User database dialog.

--- >

Figure 201: User database dialog.

192,193c187,188 < < Section 2.3.5 --- > > Section 2.3.5.1 199c194 < 201. --- > 202. 208c203 <

Figure 201: Add user dialog.

--- >

Figure 202: Add user dialog.

219c214 < Figure 200 --- > Figure 201 228,233c223,227 < the Calendar Tool system served by a particular host. The ID must be unique < among all Calendar Tool users and groups on that host. 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 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. 238,239c232 < as an additional means for communicating with a Calendar Tool user, outside of < the context of the Calendar Tool itself. --- > as an additional means for communicating with a Calendar Tool user. 244,246c237,239 < 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 --- > 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 251c244 < Figure 202 shows the administrator having entered values for a new user. --- > Figure 203 shows the administrator having entered values for a new user. 260c253 <

Figure 202: Adding a new user.

--- >

Figure 203: Adding a new user.

282c275 < adds the new user record to the user database, if the validation checks succeed --- > adds the new user record to the user database 296c289 < The new-user notification message is of the form shown in Figure 203. --- > The new-user notification message is of the form shown in Figure 204. 312c305 < Calendar Tool `Admin->Connect' command, then select the `Admin->Users' --- > Calendar Tool `File->Connect' command, then select the `Admin->Users' 319c312 < Figure 203: New user notification message. --- > Figure 204: New user notification message. 331c324 < on either the name or ID highlights both. For example, Figure 204 shows the --- > on either the name or ID highlights both. For example, Figure 205 shows the 342c335 < Figure 204: Brandon selected in users list. --- > Figure 205: Brandon selected in users list. 348,350c341,344 < 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. --- > Note that the figure shows the newly added user Richard Anderson. When the > administrator presses `View ...' in Figure > 205, the system displays the dialog of > Figure 206. 360c354 < Figure 205: User database record for James L. Brandon. --- > Figure 206: User database record for James L. Brandon. 380c374 < Figure 206 shows the results of the administrator having performed edits to --- > Figure 207 shows the results of the administrator having performed edits to 391c385 < Figure 206: User record for James L. Brandon edited. --- > Figure 207: User record for James L. Brandon edited. 403c397 < confirmation dialog in Figure 207. --- > confirmation dialog in Figure 208. 413c407 < Figure 207: Confirmation dialog for changing a user record. --- > Figure 208: Confirmation dialog for changing a user record. 450c444 < Figure 207 --- > Figure 208 452c446 < is shown in Figure 208. --- > is shown in Figure 209. 476c470 < Figure 208: Notification of change to James L. Brandon user record. --- > Figure 209: Notification of change to James L. Brandon user record. 486c480 < confirmation dialog of the form shown in Figure 209. --- > confirmation dialog of the form shown in Figure 210. 496c490 < Figure 209: Confirmation dialog for deleting a user record. --- > Figure 210: Confirmation dialog for deleting a user record. 521c515 < The notification message is of the form shown in Figure 210. --- > The notification message is of the form shown in Figure 211. 539c533 < Figure 210: Notification sent to deleted user. --- > Figure 211: Notification sent to deleted user. 569c563 < the user ID that must be provided to establish a connection to the originating --- > the user ID that must provided to establish a connection to the originating 596c590 < system displays the dialog in Figure 211. --- > system displays the dialog in Figure 212. 605c599 <

Figure 211: Group database dialog.

--- >

Figure 212: Group database dialog.

612c606 < Figure 200. --- > Figure 201. 619c613 < system displays the dialog of Figure 212. --- > system displays the dialog of Figure 213. 628c622 <

Figure 212: Add group dialog.

--- >

Figure 213: Add group dialog.

645,646c639 < 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. --- > discretion of system administrators. A group leader need not be a member. 650c643 < Figure 213 shows the administrator having entered values for a new group. --- > Figure 214 shows the administrator having entered values for a new group. 659c652 <

Figure 213: Adding a new group.

--- >

Figure 214: Adding a new group.

668c661 < Figure 214. --- > Figure 215. 677c670 <

Figure 214: Add group member dialog.

--- >

Figure 215: Add group member dialog.

693c686 < 200 --- > 201 697c690 < 211, --- > 212, 699,706c692,696 < 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. --- > respectively. Allowing multiple IDs to be entered facilitates the definition > of groups with a large number of users. 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. 708c698 < Figure 215 shows the administrator having entered IDs for the ceng --- > Figure 216 shows the administrator having entered IDs for the ceng 718c708 <

Figure 215: Add group member dialog filled in.

--- >

Figure 216: Add group member dialog filled in.

744c734 < Figure 214, --- > Figure 215, 750c740 < Section 2.12.6. --- > Section 2.12.5. 755c745 < Figure 216 shows the results of adding the `ceng' group members. --- > Figure 217 shows the results of adding the `ceng' group members. 764c754 <

Figure 216: Add group dialog with members added.

--- >

Figure 217: Add group dialog with members added.

784c774 < Figure 211 --- > Figure 212 786c776 < and then presses the `View ...' button. For example, Figure 217 shows --- > and then presses the `View ...' button. For example, Figure 218 shows 796c786 <

Figure 217: Group database record for the Computer Science --- >

Figure 218: Group database record for the Computer Science 807c797 < Figure 212. --- > Figure 213. 815c805 < confirmation dialog of the form shown in Figure 218. --- > confirmation dialog of the form shown in Figure 219. 824c814 <

Figure 218: Group member delete confirmation.

--- >

Figure 219: Group member delete confirmation.

832c822 < the system removes the names from the members list, as shown in Figure 219. --- > the system removes the names from the members list, as shown in Figure 220. 841c831 <

Figure 219: Members deleted in group record dialog.

--- >

Figure 220: Members deleted in group record dialog.

856c846 < system displays a confirmation dialog of the form shown in Figure 220. --- > system displays a confirmation dialog of the form shown in Figure 221. 865c855 <

Figure 220: Confirmation dialog for changing a group record. --- >

Figure 221: Confirmation dialog for changing a group record. 928c918 < Figure 220, --- > Figure 221, 941,942c931 < notifies all affected users, i.e., all users who were a member and/or leader of < the deleted group --- > notifies all affected users 957,964c946,952 < 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. --- > 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. 980,981c968,969 < privileged `Admin' menu. In response, the system displays a dialog of < the form shown in Figure 221. --- > privileged `Admin' menu. In response, the system displays the dialog > in Figure 222. 990c978 <

Figure 221: Location database dialog.

--- >

Figure 222: Location database dialog.

995,1052c983,988 < The figure shows the state of the location database after eight records have < been added. The location database dialog has a similar format to the dialogs < for the user and group databases. 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, the secondary sorting order is by number when name is the primary sort < key. <

< Either the name or location may be empty, but not both. When items are sorted < by name, all locations with empty names appear at the end of the list. This is < illustrated in < < Figure 221 < < by the appearance of the empty-named locations at the end of the list. When < items are sorted by number, all locations with empty numbers appear at the end < of the list. For example, Figure 222 shows the result of the administrator < having clicked on the `Number' column heading in the dialog of < < Figure 221. < < <
<
<

< <

Figure 222: Location database sorted by number.

< <
< <

< While the `Number' field may typically contain numeric components, it < is treated as string value for the purposes of sorting. For example, the < `Number' value "14-50" lexically follows the value "14-256", even < though the numeric value 50 precedes the value 256. This < ordering is illustrated in both Figures < < 221 < < and < < 222 < < by the placement of the location numbered "14-50" relatively after < other locations with non-empty numbers. Full details of lexical sorting are < covered in < < Section 2.11.28. < <

< The `Search by' field in the location database dialog operates in the < same manner as in the user and group database dialogs. Since the search < function requires typing, it is not possible to search for a location by an < empty name or number. --- > 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. 1069,1089c1005,1010 < The `Name' field is a free-form text string. `Number' is an < additional location identifier, typically in the form of a building/room < number, but not restricted to any specific format. At least one of name or < number is required to be non-empty. The following are the uniqueness rules for < location name and number: <

< two or more locations can have the same name, as long as the number for each is < different <
< if the number is non-empty, it must be unique among all locations <

< These rules allow any or all locations to have empty names or empty numbers, as < long as the other component of the name/number pair is unique. And while names < may be duplicated, non-empty numbers may not be. Overall, the rules mean that < the pair of values for Name and Number constitute a unique identification for < all rooms. <

< 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: --- > 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: 1143,1157c1064,1070 < The `Use' field describes the use for which the location is booked; it < is optional, i.e., it may be empty. The `Start Time' and < `Duration' specify the time slot of the booking; both of these fields < is required, and the entered values must follow the normal data entry rules < described in < < Section 2.11. < < At least one of the seven checkboxes for `Days must be on. <

< 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 date values < must follow the normal data entry rules described in --- > 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 1186c1099 < Section 2.12.6. --- > Section 2.12.5. 1195c1108 < Figure 221 --- > Figure 222 1200c1113 < Figure 221. --- > Figure 222. 1237,1242c1150,1153 < 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 228 shows the result of `View ...' for the second booking < listed in --- > 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 1244c1155 < Figure 227, --- > Figure 227; 1246d1156 < which is a scheduled meeting. 1262,1263c1172,1175 < shows the result of `View ...' for the third booking listed, which is < a non-meeting. --- > shows the result of `View ...' for the third booking listed. > > Figure 227; > 1279,1281c1191,1193 < 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 --- > 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 1291,1298c1203,1206 < more data fields and presses `Change'. The edits must comply with the < same data-entry rules described after < < Figure 225 < < 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. --- > 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. 1462,1464c1370,1371 < `Admin' menu except `Connect' and `Contact Admin', < and disables the `Other User' and `Group' items in the < `View' menu. --- > `Admin' menu except `Contact Admin', and disables the > `Other User' and `Group' items in the `View' menu. 1466a1374,1588 > >

> 2.6.5.2. Host Files >

> >

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

> >
> > When the administrator confirms the change by pressing `OK', the > system verifies that the specified file path is valid and readable and writable > by the Calendar Tool Administration program. If it is not, the system reports > an error as described in > > Section 2.12.6.2. > > Changing the location of the repository does not change the location > of the repository files and subdirectories. The files and subdirectories must > be moved or copied as necessary, using the normal file-move commands of the > underlying operating environment. To avoid operational disruption, the > `Host Files' command is disabled when the server is running. If an > administrator invokes the Calendar Tool Administration program with one or more > repository directories missing or discernibly corrupted, the system responds > with an error message as described in > > Section 2.12.5. > >

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

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

> No notification is sent to anyone if the size limit is changed on a group > calendar, not even the group's leader. > 1469c1591 < 2.6.5.2. Setting the Administrator Password --- > 2.6.5.3. Setting the Administrator Password 1476,1477c1598,1599 < < Section 2.15.3 --- > > Section 2.15.4 1481c1603 < displays the dialog shown in Figure 235. --- > displays the dialog shown in Figure 238. 1490c1612 <

Figure 235: Administrator password change dialog.

--- >

Figure 238: Administrator password change dialog.

1498,1507c1620,1625 < 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. --- > characters typed. 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. 1515c1633 < 2.6.5.3. Setting the Administrator Email Address --- > 2.6.5.4. Setting the Administrator Email Address 1533c1651 < Section --- > Section 2.15.4 1537c1655 < the system displays the dialog shown in Figure 236. --- > the system displays the dialog shown in Figure 239. 1546c1664 <

Figure 236: Email address dialog.

--- >

Figure 239: Email address dialog.

1560c1678 < services of an external email agent, the identity of which is specified as an --- > services of an external email program, the identity of which is specified as an 1562,1563c1680,1681 < < Section 2.7.5 --- > > Section 2.7.4.3 1577c1695 < 2.6.5.4. Notifying Users --- > 2.6.5.5. Notifying Users 1585c1703 < executes this command, the system displays the dialog in Figure 237. --- > executes this command, the system displays the dialog in Figure 240. 1594c1712 <

Figure 237: Notify users dialog.

--- >

Figure 240: Notify users dialog.

1603c1721 < Figure 238 shows the administrator sending a notification that the central host --- > Figure 241 shows the administrator sending a notification that the central host 1613c1731 <

Figure 238: A notification about central host maintenance --- >

Figure 241: A notification about central host maintenance 1660c1778 < --- > 1662c1780 < 2.6.5.5. Setting Calendar Size Limits --- > 2.6.5.6. Creating Calendar Tool Distributions 1666,1690c1784,1787 < 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 239 shows the administrator having set the size limit to 10 < Mbytes for user James Brandon. --- > 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. 1695c1792 < --- > 1697c1794 < --- > 1699c1796 <

Figure 239: Size limit set in a user record.

--- >

Figure 242: Distribution dialog.

1705,1709c1802,1816 < 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. --- > 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. > 1711,1714c1818,1839 < 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. --- > 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. 1716,1718c1841,1842 < 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 240. --- > Figure 243 shows the administrator having defined a typical customized > distribution. 1723c1847 < --- > 1725c1849 <

--- >

1727,1728c1851 <

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

--- >

Figure 243: Distribution dialog with typical settings.

1733,1741c1856,1863 < 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. --- > These settings reflect the conventions of a UNIX-style operating environment, > in particular with the use of the "~" character to specify the user's home > directory and the use of a short lowercase name for the application program. > The distribution name must be unique among any existing distributions and > cannot be empty. If the 'Local files directory' is left blank, it > must be specified at installation time, as described in > > Section 2.15. 1742a1865,1866 > If `Executable program name' is empty, the default installation value > is "Calendar Tool". 1744,1752c1868,1872 < 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 240, --- > 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 1754,1769c1874,1877 < 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 240 --- > ). The distribution consists of the configured application program and any > necessary installation support files (see > > Section 2.15 1771,1772c1879,1880 < 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. --- > ). Once created, a customized distribution is installed by a regular user > following the installation procedures described in Section 2.15. 1774,1779c1882,1909 < 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. --- > 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: >

> When installed, the caltool distribution has the pre-defined options > defined by the administrator. >
> At installation time, the specified local files directory is created if > necessary, and a new calendar file named "DepartmentCalendar" is > created in that directory. >
> When the user initially invokes the caltool, the calendar named > "DepartmentCalendar" is opened by default. >
> Assuming that the distribution options have `Auto-connect on file > open' set to yes, caltool automatically begins the > connection process to the central hostname on which the caltool > distribution was created, in this case the host > deptsrc.csc.calpoly.edu; the connection process is described fully in > > Section 2.6.6.1 > >

1787,1791c1917,1921 < 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. --- > 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. 1800,1801c1930,1931 < in the `Admin' menu. In response, the system displays the dialog in < Figure 241. --- > in the `File' menu. In response, the system displays the dialog in > Figure 244. 1810c1940 <

Figure 241: Host connection dialog.

--- >

Figure 244: Host connection dialog.

1817,1818c1947,1955 < table indicates which hosts are currently connected. By default, there are no < pre-defined entries in the table. --- > table indicates which hosts are currently connected. In a standard > distribution of the Calendar Tool, there are no pre-defined entries in the > table. In a customized distribution, such as the one created in the > > Section 2.6.5.6, > > there may be an initial entry. The assumption in this scenario is that the > user has invoked a standard distribution, with no pre-defined host connection > entries. 1837c1974 < Figure 241, --- > Figure 244, 1839,1842c1976,1979 < 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 242. --- > 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. 1851c1988 <

Figure 242: Add host dialog.

--- >

Figure 245: Add host dialog.

1862,1864c1999,2002 < file is assumed to be in user's Calendar Tool directory, as described in < < Section 2.8.1. --- > file is assumed to be in the local files directory defined using the `Local > Files' command, described in > > Section 2.8.7. 1881c2019 < --- > 1884c2022 < The setting also appears in the add-host dialog, as a convenience. When the --- > The setting also appears in the add-host dialog as a convenience. When the 1888c2026 < Figure 243 shows the user having entered typical values for a host table entry. --- > Figure 246 shows the user having entered typical values for a host table entry. 1897c2035 <

Figure 243: Defining a host table entry.

--- >

Figure 246: Defining a host table entry.

1918c2056 < Figure 243 --- > Figure 246 1922c2060 < in Figure 244. --- > in Figure 247. 1931c2069 <

Figure 244: Host connection table with new entry added.

--- >

Figure 247: Host connection table with new entry added.

1936,1943c2074,2078 < 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. --- > Note that the ID, password, and auto-connect values do not appear in 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. 1949c2084 < in Figure 245. --- > in Figure 248. 1958c2093 <

Figure 245: Host selected in table.

--- >

Figure 248: Host selected in table.

1978c2113 < file on the local computer that is readable and writable by the user --- > file on the local computer that is readable and writable by the user. 2001c2136 < 2.6.5.4; --- > 2.6.5.5; 2006c2141 < `Delete' buttons, all as shown in Figure 246. --- > `Delete' buttons, all as shown in Figure 249. 2016c2151 <

Figure 246: Host connection established.

--- >

Figure 249: Host connection established.

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

2062c2188 < Section 2.12.14. --- > Section 2.12.12. 2065c2191 < The user can add multiple entries in the host table. For example, Figure 247 --- > The user can add multiple entries in the host table. For example, Figure 250 2076c2202 <

Figure 247: Host connection with additional entries.

--- >

Figure 250: Host connection with additional entries.

2084,2085c2210 < the same host address cannot appear more than once in the table, where "same" < means lexically equal as strings --- > each host in the table must be associated with exactly one calendar; 2087,2088c2212,2213 < 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 --- > a calendar in the table can be associated with more than one host, at most one > of which can be connected at any given time. 2091c2216 < Figure 247 --- > Figure 250 2095c2220 < campus ... and deptsrv ... hosts. The utility of such --- > campus ... host and deptsrv ... hosts. The utility of such 2113c2238 < 242 --- > 245 2117c2242 < 243 --- > 246 2138,2156c2263,2264 < < 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 . --- > > Section 2.8.1. 2159,2164d2266 < 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. <

2170c2272 < the `Add' and `Cancel' buttons are enabled. --- > the `Add' button is enabled. 2174,2178c2276,2277 < are disabled; `Connect' is enabled if the selected host is not < connected with another calendar in the table; `Cancel' is enabled. <

< When a connected entry is selected, only `Disconnect' and < `Cancel' are enabled. --- > are disabled.; `Connect' is enabled if the selected host is not > connected with another calendar in the table. 2180,2181c2279 < `Save' is enabled whenever the user has edited one or more fields so < that the values are different that those most recently saved. --- > When a connected entry is selected, only `Disconnect' is enabled. 2184,2208d2281 <

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

< 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; <
< 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 2.12.9. < < The Calendar Tool system does not prevent the same user from connecting 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. 2216,2224c2289,2292 < 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 --- > 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 2239c2307 < makes the calendar associated with the host the current calendar. --- > makes the calendar associated with the host the current calendar 2242,2243c2310,2318 < no current calendar, then only the `Connect' and `Contact < Admin' items are enabled in the `Admin' menu. --- > no current calendar, then all items in the `Admin' menu are disabled > except for `Contact Admin'. >

> 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. 2250,2257c2325,2331 < all regular-user `Admin' commands operate in this manner, with a < separate display window for the results of each command, for each host. <

< The system does not display multiple copies of the same admin window for a < specific host and a specific command. For example, there is at most one copy < of the user database window open for any given host. The windowing display < style for admin commands is fixed, and not affected by the `Windowing < Mode' setting in the `View' menu (see --- > 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 ( 2261c2335 < ). --- > ) does not apply to any admin commands. 2272c2346 < `Users' command, the system displays the dialog shown in Figure 248. --- > `Users' command, the system displays the dialog shown in Figure 251. 2281c2355 <

Figure 248: Regular user viewing the Users database.

--- >

Figure 251: Regular user viewing the Users database.

2286c2360 < The regular-user view of the user database displays the same information as the --- > The regular view of the user database displays the same information as the 2289c2363 < Figure 200, --- > Figure 201, 2298c2372 < regular-user display of the database. --- > regular user display of the database. 2306c2380 < a dialog of the form shown in Figure 249. --- > a dialog of the form shown in Figure 252. 2315c2389 <

Figure 249: Regular user viewing a user database record. --- >

Figure 252: Regular user viewing a user database record. 2323c2397 < Figure 205, --- > Figure 206, 2367,2369c2441,2443 < Then the user executes the `Change Password' command in the < regular-user `Admin' menu. In response, the system displays the < dialog in Figure 250. --- > Then the user executes the `Change Password' command in the regular- > user `Admin' menu. In response, the system displays the dialog in > Figure 253. 2378c2452 <

Figure 250: Regular user password change dialog, for a --- >

Figure 253: Regular user password change dialog, for a 2421,2422c2495,2496 < < Section 2.8.8. --- > > Section 2.6.5.2 2425,2427c2499,2505 < table, which is saved permanently in the settings file, as described above. < Whenever a password is stored on a file, it is suitably encrypted to prevent < readability within the contents of the file. --- > 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. 2442,2447c2520,2526 < 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 251. --- > 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. 2456c2535 <

Figure 251: Host request dialog.

--- >

Figure 254: Host request dialog.

2471c2550 < the system displays the dialog in Figure 252. --- > the system displays the dialog in Figure 255. 2480c2559 <

Figure 252: Contact admin dialog.

--- >

Figure 255: Contact admin dialog.

2489,2490c2568,2569 < < Section 2.7.5. --- > > Section 2.7.4.3. 2497c2576 < Figure 253 shows the body of a typical email message that a user sends to an --- > Figure 256 shows the body of a typical email message that a user sends to an 2516c2595 < Figure 253: Typical admin request. --- > Figure 256: Typical admin request. 2530c2609 < Figure 208. --- > Figure 209. 2547c2626 < An administrator can send general notifications to all users with the --- > An administrator can send general notifications to all connected users with the 2549,2553c2628 < dialogs, email messages, or both (see < < Section 2.6.5.4 < < ). --- > dialogs, email messages, or both. 2556c2631 < users when the administrator performs functions that require notification, --- > users when the administrator performs functions than require notification, 2581c2656 < files in which user calendars are stored on the host. --- > files in which user calendars are stored. 2586c2661 < control is indirect, through the setting of the calendar size limit and the --- > control is indirect, through the setting of the item size limit and the 2588,2589c2663,2664 < < Section 2.6.5.5. --- > > Section 2.6.5.2. 2606,2607c2681 < on Calendar Tool files stored on any users' local computers, or on the contents < of any of these files. --- > over the contents of Calendar Tool files stored on any users' local computers. 2609,2615c2683,2689 < A Calendar Tool user who happens to be an administrator may run the < regular-user 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 --- > 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 2626d2699 <