2.12. Error Conditions

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.

2.12.1. Non-Admin Attempting to Login as Admin

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

2.12.2. Commands with No Effect

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 paragraphs that follow are pre the preceding remark and therefore mostly obsolete if we go this way.

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

2.12.3. Searching for Unknown User

2.12.4. Scheduling Errors

Potpourri:

2.12.4.1. Unknown Meeting Attendees

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


The following attendees are not registered users:

    ...

Check `OK' to mark each of these names as `Not Registered'.

              OK    Check All  Cancel

Figure 150: Unregistered attendees error dialog.



2.12.4.2. Meeting Scheduler Validation

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

2.12.4.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.4.4. Changing a Meeting to an Unavailable Location

2.12.5. Errors from an External WWW Browser

2.12.6. Administrative Errors

To cover:






Prev: data-entry-details | Next: gui-details | Up: functional | Top: index