Review all of the errors referred to in the data entry details section. Dole them out to appropriate subsections herein.

Just recently, I've thought about the following distinction between an error condition versus non-error, particularly in the context of scheduling (and which is also applicable to searching probably):

"It's an error if it's a precond violation."

OK, here's a no-effect issue that must be dealt with. Viz.,. when the user conforms a change that is really no change at all, the system should not send notifications. Changes that this applies are scheduler meeting changes and administrator database changes. OK -- I just fixed this by adding the "re- edit" conditions to the introduction of the change-delete section.

28jun01 Note: I'm thinking we should not go the Rolodex route with the "no effect" business, but rather do things thusly:

1. say that nothing was greyed out in the initial menu expansions for clarity, and since it's a generic display independent of any particular system state.
2. have an explicit discussion here, or in data-entry-details, or even in gui- details, that describes precisely the conditions under which main menu items are enabled and disabled
3. have a similar explicit (summary) discussion of the dialog state conditions in terms of when GUI elements are enabled and disabled.

The following notes were removed from the structure-viewing section. Deal with them:

• [Ed. Note: determine if we should discuss here that the system beeps and/or discuss in general elsewhere how the system signals an uneffectual command, including allowing an option for such signaling. See just below for further discussion of this.]
• [Ed. Note: Think about adding a dialog, probably an option-controlled dialog, to each of the above "no effect" cases that says something to the effect of: "No X selected, please select one.", where "X" is one of item, day, week, month, or year. The emacs name of the controlling option would be something like display-dialog-on-no-effect-command.]

24jul02 Update: Let's forget error-control options, and just have the system make up it's farging mind about how to do things properly for error handling. This means disabling the widgets for commands that would have no effect or are disabled because their preconds aren't met.

2.12.2. Searching for Unknown User

Potpourri:

• the start date and time must be after the time at which the scheduler operation is confirmed
• the time to send a reminder must be after the time at which the schedule operation is confirmed
• if the `disallow' option is set for overlaps, then add this to the error conditions, i.e., scheduling an overlapping item is an error.

If the list of attendees contains unregistered attendees not so marked, the system will output the error dialog shown in Figure 329.

As noted in the preceding scenarios, only a group leader may schedule a meeting for a group. When one or more group names appear in the attendees list, the scheduler must be a leader of all groups in order for the scheduling operation to proceed. The determination of group leader status is based on the definitions in the group database ( Section 2.6.3 ).

Scheduler validation is performed when the `List Times ...' command is executed. If the scheduler is not a leader of all groups in the attendees list, the system displays an error message, the precise format of which is described in Section 2.12.3.

2.12.3.3. Non-Unique Items

The system disallows multiple scheduled items with exactly the same values for date, start time, duration, and title. Error happens if user tries to violate this. Conditions where is can arise are:

1. schedule appt op; in this case, penciled-in meetings are considered "in"
2. schedule meeting op for the scheduler (handled during notification for attendees), including the case where the scheduler has a private item that causes violation to occur
3. changing an appt or meeting

Possibly useful verbiage axed from meeting-scheduling section:
When a single user schedules an item on the user's own calendar, the system displays an error message if the uniqueness condition is violated. When a scheduler schedules a meeting for other user's, the system does not check the condition for all attendees. Rather, the condition is checked at the time the meeting is accepted by the attending users.

2.12.3.4. Changing a Meeting to an Unavailable Location

Include the case where the identity of an external mailer is not known to the Calendar Tool. This condition is visible to the user by a blank value in the Global Options dialog described in Section 2.7.6.

2.12.5. Errors from or Related to an External Web Browser

Include the case where the identity of an external web browser is not known to the Calendar Tool. This condition is visible to the user by a blank value in the Global Options dialog described in Section 2.7.6.

2.12.6. Administrative Errors

Review all the errors referred to in the admin section.

To cover:

• invalid user IDs or circular supergroup definition in group member dialog of Figure 215,
• conflicting location booking in book location dialog of Figures 226 and

The system should be able to detect this through the login ID.

2.12.7. Failure of Central Host Computer

OK, we might just want to skip all the complicated auto notification stuff and have the central host server run pretty much like an apache server, in that detection of it being down is strictly from the servee as opposed to server side. I don't really think it can work completely this way, since the different here compared to apache is that the server is maintaining data about remote servees in a way that apache is not, i.e., the user ed. We'll have to think about this to see if any apache-insprited simplificaiton is possible or appropriate.

Failure is defined as the central host computer stopping operation or becoming disconnected from the network. In the case of stopped operation, the backup central host immediately becomes the active central host, if it is possible to perform such immediate action in the underlying operating environment. The switch from backup to active host entails the following automatic actions:

1. on the backup host and in the Calendar Tools of all registered users, the ID of the central host is changed to the ID of the backup host
2. all users are notified of the host change

1. in the Calendar Tools of all registered users, the status of the central host computer is set to `down'
2. all users are notified of the failure

The format of the central host failure notification is shown in Figure 330.

If the automatic switch from active to backup host is not possible, then the adminstrator must perform the reassignment of active host manually on the backup host, as described in Section .

In the case of network failure or when it is not possible to send failure notificaiton automatialy from the central host, individual user computers must detect central host failure when execcuting any command that requires access to the central host. These commands are:

• File Save, Save As, or Save All
• the `List Times' command during meeting scheduling
• View Other User or Group
• any Admin command

If no backup host computer is in operation, it is the adminstrator's responsibiltiy to maintain backup copies of Calendar Tool administrative data files that can be used in the event that the active central host stops operating or becomes disconnected from the network.

2.12.7.1. Loss or Corruption of Central Host Data

Sketch: Individual user hosts can run the Calendar Tool just fine, but they won't have access to any of the databases or other user's calendars. There's not data consistency problem with any extant scheduled meetings that refer to other users, groups, or locations, since all such references are purely symbolic. (Explain what "symbolic reference" means and add any additional general explanation that's necessary.)

2.12.7.2. Invalid repository path

Among other things, we should probably think about error logging when communication local computers fails. Or perhaps the whole idea of the central host as the "up to" machine obviates the need to worry about local machine failure when running the non-admin cal tool. Worrying about local machine failure when running cal tool admin may in fact have to be considered.

2.12.9. Attempting to Connect to a Host with the Same User ID at the Same Time

If there no valid readable Options file, the Calendar Tool creates one when it starts up. If in cannot, because the user's cal tool dir is non- existen or unwriteable, it issues an error.

2.12.11. File Errors

Enumerate all the file things the user can do to fuck things up while caltool or caltool admin are running, and what the error messages are that correspond to the fuckups. Here's the beginnings of this enumeration (no sure if more needs to be added):

• delete, corrupt, or turn off write permission to an open file -- error detected when user attempts save
• delete, corrupt, or turn off read permission to an unopen file -- error detected when user attempts open
• delete, corrupt, or change read permission to a file listed in the host connection table -- error detected when user attempts connect to host associated with that file
• delete, corrupt, or change read permission to the caltool user dir -- error detected when user attempts connect to host associated with that file

Here's some fodder nuked from the File section, to be attended to (even though I'm pretty fucking sick of having to re-read bullshit like this as the buck keeps being past):

IDiscuss what exactly happens if the user hacks (i.e., corrupts or deletes) a cal tool file while either caltool or admin is running, or not running for that matter. The deal is we most likely need to be completely clear about exactly when the cal tool reads and writes its files, and thence the effect that external file hacking has on cal tool behavior. It probably won't be as smart as Emacs is, but hey, it ain't emacs.

Enumerate exactly when a file becomes unreadable or unwritable due to external change, such that the dialogs cannot deal with it properly, i.e., show it as enabled when a concurrent external changes renders it to a state where it should be disabled.

Also discuss what happens if the caltool user dir or repository dir is invalid. This can happen by outside diddling, or with the regular-user and admin options that allow the "master" directories to be changed. E.g., here's a bit about admin dirs from the old options section:

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

Among other things, let the user overwrite an existing file, of either calendar or other type, with a confirmation-required warning before doing so.

Desribe unwritable file error.

Also make sure that the issue of missing or corrupted files is dealt with fully, if it's not already been done in the File section. I think it should have been dealt with semantically there, so what will go here, as usual, are the details of what the associated error message(s) look like.

2.12.12. Zero-Instance Recurring Items

Deal with this, including when this happens via change.

2.12.13. Errors in Specifying Recurrence

Include start >= end, enforcement of weekly day rule described at the end of Section 2.5.3.1.

2.12.14. Exceeding Item Limits

When a user confirms a scheduling op such that her item limit is exceeded, the system issues the error message in Figure 331.

And here's some rationale fodder: Thought about having the system do an auto delete of the oldest scheduled item in the calendar when the item limit is

When a scheduler confirms a meeting and adding that meeting to the user's central host calendar causes that calendar to exceed its limit, the scheduler is notified that the meeting did not get scheduled for that user. Since this is presumably a rare occurrance, we may not need to have the option to delete the oldest other item. So what presumably happens is that the scheduler contacts an admin and/or the user(s) whose item limit(s) was(were) exceeded to deal with the situation.

2.12.15. Host Connection Failure

If communication cannot be established with the selected host, the first line is changed to

Communication cannot be established with the selected host computer.

The selected host computer is not currently running a Calendar Tool server.

The selected host computer is running a Calendar Tool server, but you are not a
registered user on it.

the file associated with the selected central host does not exist in the
Calendar Tool local files directory (offering to create it or allowing user to
select a different one might be nice, but I can live without these offers)

... do this (not too tough)

The following bullets appear to be mostly redundant with the preceding blather.

• if the server is unknown or down, then an appropriate error is displayed;
• if the server computer is up but not running as a cal tool central host, an appropriate error is displayed;
• if the server is up as a cal tool central host, but the user is not registered there, an appropriate error is displayed;
• if the server is up as a cal tool central host and the user is registered there, the validation is satisfied.