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:
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:
Potpourri:
If the list of attendees contains unregistered attendees not so marked, the
system will output the error dialog shown in Figure 226.
The following attendees are not registered users:
...
Check `OK' to mark each of these names as `Not Registered'.
OK Check All Cancel
Figure 226: 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.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:
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: