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."Ah, but now that I've written it down, it's exactly right and what we've always been saying. This means that it's not an error for the scheduling op not to find any available times, nor similarly for a search to find applicable search targets. This in turn is (further) justification for searching and scheduling not to be formally spec'd with non-success as preconds (which I think we already pretty much know). From the requirements perspective, specifically with regard to the guideline that we leave error conditions to later, it's consistent with this guideline to include the "No times found" message" in the scheduling section, but leave other scheduling errors, such as "You're unauthorized to send to these users: ..." to the error section of the requirements.
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:
The following notes were removed from the structure-viewing section. Deal with them:
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.
Potpourri:
If the list of attendees contains unregistered attendees not so marked, the
system will output the error dialog shown in Figure 310.
The following attendees are not registered users:
...
Check `OK' to mark each of these names as `Not Registered'.
OK Check All Cancel
Figure 310: Unregistered attendees error dialog.
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.
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:
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.
Review all the errors referred to in the admin section.
To cover:
The system should be able to detect this through the login ID.
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:
The format of the central host failure notification is shown in Figure 311.
The Calendar Tool central host computer is down or unavailable. You can continue to use the Calendar Tool on your local computer, but you will not have access other to user calendars or any of the administrative commands.
Figure 311: Central host failure notification.
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:
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.
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.)
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.
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.
Deal with this, including when this happens via change.
When a user confirms a scheduling op such that her item limit is exceeded, the
system issues the error message in Figure 312.
Figure 312: Item limit exceeded.
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.
If communication cannot be established with the selected host, the first line is changed to
If communication can be established, but the host is not running a Calendar Tool server, the message isCommunication cannot be established with the selected host computer.
If host is running a Calendar Tool server but the user is not registered there, the message isThe 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 following bullets appear to be mostly redundant with the preceding blather.