Changing and deleting scheduled items is performed in item-level displays. As illustrated in the preceding section of the requirements, all item-level displays have `Change' and `Delete' command buttons to perform these operations. The enabled/disabled state of these buttons is consistent in all four types of item. Specifically, when the system initially displays an item-level view, the `Change' and `Clear' buttons are disabled and the `Delete' button is enabled. This is illustrated in the display excerpt shown in Figure 143.

As soon as the user performs an edit to some data field, the initial state of the command buttons is reversed. Namely, the `Change' and `Clear' buttons are enabled and the `Delete' button is disabled. This is illustrated in Figure 144.

When the user executes and confirms `Delete', the system removes the item from the affected calendars, removes the item-level display from the screen, and updates any affected display windows.

Since the different types of scheduled item share many data fields in common, many aspects of changing items are common to all types. Aspects of item deletion are also common among the different types of item, such as the general form of the confirmation dialogs. The most wide-ranging effects of change and delete are made to meetings by meeting schedulers. Such changes and deletions potentially affect meeting attendees.

As noted in Section 2.4.1.5, there is a separate copy of a meeting for the scheduler and for each attendee. The system allows schedulers as well as attendees to change or delete their own individual copies. This multi-user access to meeting items leads to functional requirement details that must be carefully considered. The scenarios presented in Section 2.5.2.2 address these details.

2.5.2.1. Changing and Deleting Appointments

To change a scheduled appointment, the user edits one or more data fields in the item-level display and then presses the `Change' button. For example, Figure 145 shows the user having edited the date and time fields of the dentist appointment scheduled in Figure 6.

In this scenario, the user selects `OK' in the confirmation dialog, whereupon the system proceeds with the appointment change. After the change is confirmed, the system updates all display windows that are affected by the change. For example, the month view shown in Figure 21 is changed to that shown in Figure 147, where the dentist appointment has been moved from 8-9:30 on the 25th to 8:30-10 on the 29th.

All data fields may be edited in the item-level view of an appointment. The same data-entry rules apply when changing an appointment as when initially scheduling it. These rules are covered in detail in Section . In addition to these data-entry rules, there are the following restrictions on changing a recurring appointment:

1. a recurring appointment cannot be changed to non-recurring;

2. changes made to any of the following data fields in a recurring appointment apply to all instances of the appointment:
   • Start Date (as opposed to Instance Date)
   • End Date
   • Recurring Interval and the associated recurring details

Figure 148 shows the user having edited an instance of a recurring appointment.

The user decides to perform another change to the racket ball appointment, by deleting the last three weeks from the recurring schedule. To do so, the user moves to the October 1 instance and performs the edit shown in Figure 151.

The user proceeds to press `Change' in Figure 151, in response to which the system displays the confirmation dialog in Figure 152.

If the user changes an appointment with `all future' selected, the system displays the dialog of Figure 154.

To delete a non-recurring appointment, the user presses `Delete' in the item-level display. In response, the system displays the confirmation dialog of Figure 155.

When the user executes `Delete' for a recurring appointment, the system displays one of the three confirmation dialogs shown in Figure 156, based on the setting of the change/delete radio buttons.

The change and delete commands for meetings behave much the same as they do for appointments. A significant difference is when a scheduler changes or deletes a meeting, all attendees can be notified. Scheduler deletion of a meeting is the means by which the meeting is effectively canceled for all attendees.

Individual users can also change their own local copies of scheduled meetings. When both schedulers and non-schedulers make changes to the same meeting, their changes must be reconciled. What it means to have separate copies of the "same meeting" is that values of the `Scheduled By', `On', and `Host' fields are the same in each of the copies. The set of values for these three fields constitutes the unique identification of a meeting on all users' calendars. This is the reason why these values cannot be changed after a meeting has been scheduled.

The precise relationship between the scheduler and non-scheduler copies of a meeting can be characterized as follows. The meeting copies are "synchronized" when they contain exactly the same values for all data fields. The synchronized state exists when an attendee accepts a meeting without making any changes, and the scheduler makes no changes subsequent to confirming the scheduling operation. Synchronization also occurs when a non-scheduler accepts scheduler-initiated changes, as discussed in Section 2.5.2.2.1.

When the scheduler and/or non-scheduler change their copy of a meeting, it becomes "unsynchronized". The only time an unsynchronized meeting is brought to the attention of an attendee is when the scheduler changes the meeting and then notifies the attendees. At this point, the user must be able to identify which data fields have been changed and by whom. To assist in this identification, the system color codes the changes when it displays the change notification dialog. Table 9 describes this coding.

In order for change notifications to be sent and received, the scheduler and attendees must be connected to the same Calendar Tool central host computer, and it must be the host from which the changed meeting was originally scheduled. The scenarios of Sections 2.5.2.2.1 through 2.5.2.2.5, assume that the scheduler and affected non-schedulers are so connected, and that the changes they make do not conflict. Sections 2.5.2.2.6 and 2.5.2.2.7 address the cases where scheduler and non-scheduler make changes while disconnected from the host and then subsequently reconnect. Section 2.5.2.2.8 covers conflicting scheduler and non-scheduler changes.

2.5.2.2.1. Scheduler Changing Meetings

To change an existing meeting, the meeting's scheduler edits its item-level display, in the same manner as appointment editing is performed (see Section 2.5.2.1. ). If the scheduler wants all attendees of the meeting to be notified of the changes, the scheduler must be connected to the same central host computer to which she was connected when the meeting was originally scheduled. If the scheduler is not connected to this host at the time a change is confirmed, then the changes are made only to the scheduler's local copy of the meeting and no change notification is sent (see Section 2.5.2.2.6 ).

As described in Section 2.4.1, some of the data fields of a scheduled meeting are computed by the system, based on the initial scheduling request. This means there are scheduler restrictions on changing some meeting data fields. Furthermore, some data fields are sufficiently critical to the meeting that all attendees must be notified if one or more such fields are changed. Table 10 summarizes what changes, if any, are allowed by the scheduler and which field changes require attendee notification.

The table entries listed as "any" are still subject to the general data entry rules described in Section

Figure 157 shows edits made by the scheduler to the staff meeting confirmed in Figure 88.

1. One or more critical data fields have been changed, Duration in this case; this requires that all attendees be notified.

2. There is a time conflict for one or more attendees; the scheduler is informed of this condition in the dialog.

In this scenario, the scheduler chooses `OK'. The scheduler's calendar is changed and all affected display windows are changed on the scheduler's display screen. In this case the scheduler is among the attendees and also appears in the conflicts list. The scheduler receives no notification, since the dialog itself serves this purpose. The fact that the meeting conflicts with existing item(s) on the scheduler's calendar is handled in the normal way, i.e., the item is subsequently displayed in overlapping format, as illustrated in Section 2.3.1.

When the scheduler confirms the change, all attendees are notified. Complete details of attendee change notification are covered in Section 2.5.2.2.3

The definition of time conflict when changing a meeting is the same as when the meeting is initially scheduled. Viz., a conflicting item on an attendee's calendar is any non-private item that overlaps with the changed meeting. Such a conflict can arise when the scheduler makes a change to one or more of the following meeting fields:

• (Start) Date
• End Date
• Start Time
• Duration
• Recurring
• Attendees

The system provides no means to recompute a list of possible meeting times via the `Change' operation. All that the system does is detect and report attendee time conflicts. If the scheduler wants to reschedule the meeting at time when there are no conflicts, the scheduler must re-execute the `Schedule Meeting' operation to view a list of non-conflicting possible times. The scheduler can then choose a time from that list for the change, using copy and paste. Alternatively, the scheduler can delete the original meeting and re-execute the `Schedule Meeting' operation from scratch.

Figure 159 shows the scheduler having edited an instance of the recurring lecturer meeting scheduled in Figure 91.

Figure 161 shows another change to the lecture meeting, this time to future instances, at and beyond the October 1 instance.

When the scheduler presses `Change' in Figure 161, the system displays the dialog of Figure 162.

Figures 158, 160, and 162 show three examples of the confirmation dialog for changes made by a meeting scheduler. There are sixteen possible configurations for this dialog, based on whether there are attendee conflicts, whether the meeting recurs, and whether attendee notification is to happen. The following is a description of all possible configurations:

• If there are conflicts, the following text appears at the top of the dialog:

  "The change will create a time conflict for the following users:"

  with the IDs of all affected users listed below the message.

• The confirmation message appears below the conflict message, or at the top of the dialog if there is are no conflicts. The confirmation message text is one of the following four alternatives, based on whether the meeting is recurring, and if so, which of the change/delete radio buttons is selected:

  "Are you sure you want to change this meeting?"
  
  "Are you sure you want to change this instance
            of the recurring meeting?"
  
  "Are you sure you want to change all instances
            of the recurring meeting?"
  
  "Are you sure you want to change this instance and
    all future instances of the recurring meeting?"

• Below the confirmation message is the indication or choice of attendee notification. If one or more critical fields are changed, the notification text is

  "If you choose `OK', all attendees will be notified."

  If no critical field is changed, the notification text is

  "If so, select whether to notify all attendees of the change."

  below which are the `notify' and `do not notify' radio buttons.

• At the bottom of the dialog are `OK' and `Cancel' buttons.

To delete a non-recurring meeting, the scheduler presses `Delete' in the item display. In response, the system displays a dialog of the form shown in Figure 163.

The scheduler presses `OK' to proceed with the delete, in response to which the system deletes the meeting from the scheduler's calendar, deletes the meeting from all attending group calendar(s), and notifies all attending users. The system also updates any affected display windows on the scheduler's screen by removing the deleted item from those displays. Updates to attendee screens are performed as described in Section 2.5.2.2.3. If the scheduler selects `Cancel', the system performs no delete and removes the confirmation dialog, leaving the item-level display in its state prior to `Delete' having been executed.

Deletion of a recurring meeting applies to all instances selected by the change/delete radio buttons, with the same effects for each instance as non- recurring deletion. The confirmation dialogs are shown in Figure 164.

When the scheduler cancels a meeting with `Delete', the meeting is permanently removed from the scheduler's calendar, and from the calendars of all accepting attendees. If the scheduler wants to retain a record of a canceled meeting, the scheduler can perform cancellation with `Change' instead of `Delete'. To do so, the scheduler can type an appropriate cancellation text in the `Title' and/or `Details' fields. To bring the changed field(s) to the attention of notified users, the system color highlights the title and border of the changed field(s), as described in the next section.

2.5.2.2.3. Meeting Change and Delete Notifications

When the scheduler changes a meeting such that a notification is required or selected, the system notifies each attendee, except the scheduler. The notification is sent in an on-screen change notification dialog, of the form shown in Figure 165.

If the attendees list in a meeting is changed, the change notification is sent to those users appearing in the attendees list prior to the change who have not been deleted by the change. Users deleted from or newly added to the attendees list are sent a different form of notification, as described below.

When a scheduler change causes a time conflict with one or more existing items in a notified user's calendar, the notification message has the following line appended:

NOTE: this change conflicts with N existing item(s).

The user can view the complete details of the change by pressing the `View ...' button in the initial change notification dialog. For example, when the user presses `View ...' in Figure 165, the system responds by displaying the notification details dialog in Figure 166.

In Figure 166, the scheduler changes in blue are those made in a preceding scenario (see Figure 157 ). The non-scheduler changes in green were made before the user accepted the meeting (see Figure 113. ). The case of conflicting scheduler and non-scheduler changes is not shown in Figure 157; it is covered later in Section 2.5.2.2.8.

All data values shown in Figure 166 are those in the scheduler's copy of the meeting. The user can compare these values with hers for the same meeting by viewing the same meeting using the `View Item' menu command, as discussed in Section 2.5.2.2.5

There are `Accept' and `Decline' buttons at the bottom of the detailed notification dialog. To the left of the buttons is a label explaining that the buttons apply to the changes made by the scheduler. The user can edit any data fields except `Scheduled By', `On', and `Host'.

The user can respond to a meeting change notification in one of three ways: accept the change, decline the change, or delay a decision. Both the smaller change notification dialog ( Figure 165 ) and the larger details dialog ( Figure 166 ) have `Accept' and `Decline' buttons. If the user chooses `Accept', the changes are merged into the scheduled item in the user's calendar. If the user chooses `Decline', the changes are not merged. The prudence of declining scheduler changes to a meeting may questionable, but left to the user's discretion.

To delay the accept/decline decision, the user can close the notification dialog window, using the `View Windows Close' command or equivalent window shortcut. A user cannot delay an accept/decline decision beyond the date and start time of a non-recurring meeting, or beyond the date and start time of the last occurrence of a recurring meeting. If a user fails to accept or decline within this time, the system automatically executes decline on the user's behalf.

In the case of Figure 166, the notified user decides to edit the `Duration' field from the scheduler changed value of 1.5 hours back to the original value of 1 hour, as shown in Figure 167.

When the user presses `Accept' in Figure 167, the system merges the scheduler's changes into the user's copy of the meeting item. Change merging is accomplished by retaining the most recently entered value for each meeting data field. For this staff meeting, the user has changed the `Title', `Duration', `Category', and `Remind' fields more recently than the scheduler. Therefore, the user's values for these fields are retained in the changed version. In the case of `Title', `Category', and `Remind', the user's edits where made prior to the original acceptance of the scheduled meeting ( Figure 113 ). The `Duration' field was edited by the scheduler ( Figure 157 ), but then subsequently edited by the user in the notification dialog ( Figure 167 ). Therefore, the user's edit to `Duration' is the most recent, and it is retained in the changed version. The scheduler's change to the `Details' field is most recent, and therefore appears in the accepted version. All of the other data fields are unchanged by either the scheduler or user from their original scheduled values, and hence are retained as they are. Any user edits made in the notification dialog are reflected in the ultimately accepted changes. As a result, when the user executes `View Item' after pressing `Accept' in Figure 167, the system displays the item-level view shown in Figure 168.

The policy to merge only the most recent changes may not be optimal in all circumstances. For example, the user may wish to retain a previous value, as was the case with the meeting `Duration' in the preceding example. The system provides no option to select a different merge policy. The user can view the change notification and item displays side by side to inspect the differences between scheduler and user versions of a changed meeting. The user can then edit any scheduler-changed fields in the notification dialog.

There are two local copies of a meeting for each user who has not yet accepted or declined scheduler changes. The copy shown in the item-level display is that stored in the user's local calendar, without any not-yet-accepted scheduler changes. The copy shown in the change notification dialog reflects changes made by the scheduler. The scheduler-changed copy of the meeting is stored in the notification dialog itself, and is not yet a scheduled item in the user's calendar. The meeting in the user calendar refers to the scheduler-changed copy, via the `View ...' button, as shown in Figure 171. In terms of physical storage, the notification copy of the meeting is stored on the user's local computer when the notification is received from the central host computer. In this way, the user may subsequently disconnect from the central host and still have a record of the scheduler changes to that point. Further discussion of local and central data storage are covered in Section .

To undo any edits made after the change confirmation dialog is initially displayed, the user can press `Clear'. As illustrated in Figures 166 and 167, the `Clear' button is disabled until the user performs some editing.

When the detailed notification dialog is displayed, the initial smaller notification dialog remains active. The user can press `Accept' or `Decline' in either dialog. When the user does so, the active dialog is removed from the screen, and the other dialog, if displayed, is also removed.

When a scheduler changes a recurring meeting, the notification dialog text is one of the following, based on the scheduler's setting of how many instances to change:

"User user ID has changed one instance
   of the recurring meeting on date"

"User user ID has changed all instances
     of the recurring meeting on date"

"User user ID has changed all future instances
  of the recurring meeting starting on date"

When the scheduler deletes a meeting, attending users are notified with a dialog of the form shown in Figure 169

To view details of the scheduler-deleted meeting, the user presses `View ...' in Figure 169. In response, the system displays the dialog in Figure 170.

If the user presses `Accept', the system deletes the meeting from the user's calendar, updates all affected displays, and removes the delete notification dialog(s) from the screen. If the user presses `Decline', no deletion is performed. If the user has edited one or more data fields prior to pressing `Decline', the system displays a change confirmation of the form shown in Figure 172. If the user confirms the change, the system removes the notification from the screen. If the user cancels the change, the notification dialog remains, with no action having been taken.

Prior to an accept/decline decision for a scheduler changed or deleted meeting, the meeting appears in penciled-in form. As discussed in Section 2.4.1.5, the penciled-in format appears in daily, weekly, and monthly calendar views, as well as in all list views. The format is illustrated in Figure 114. In item-level calendar views, meetings with not-yet-accepted scheduler changes or deletion are indicated by additional command buttons at the bottom of the display. Details of this are presented in Section 2.5.2.2.5

The appearance of change/delete notifications is controlled by the setting of the meeting notification option described in Section 2.4.1.5. Also described in that section is the option that controls the appearance of penciled-in items. When an attending user is connected to the originating central host, and options settings permit, the system dynamically updates all active displays that are affected by a scheduler meeting change. An "affected" display is any attending user's display that shows the item prior to being changed. In all such displays, the item is dynamically changed from normal format to penciled-in format. In item-level displays, scheduler changes are indicated with the dynamic appearance of extra command buttons. The format of these item-level displays is described in Section 2.5.2.2.5. Further details of dynamic view updating are covered in Section 2.5.6.

After the user makes the accept, decline, or delay decision in any notification dialog, the notification is never redisplayed. If the start date and time of the meeting pass before the user makes the accept/decline decision, the system automatically executes decline on the user's behalf. As a result, the scheduler's changes are ignored, and the meeting is changed from penciled-in form back to a regular scheduled item. If the start date and time of the meeting pass before the notification dialog is allowed to appear, the system never displays it. The further details of notification handling discussed in Section 2.4.1.5 apply to change/delete notifications in the same way as they apply to originally scheduled meetings.

In terms of physical storage, the scheduler-changed copy of the meeting is effectively part of the change notification itself, not in the user's local calendar. This effective behavior is necessary so that the user can compare, if desired, the complete content of the extant local copy of the meeting with the scheduler-changed copy, as explained in Section 2.5.2.2.5.

In the case where a meeting change involves addition or deletion in the `Attendees' list, the notification for added or deleted attendees is different from the change notification described above. Specifically, each newly added attendee receives a regular meeting notification, as described in Section 2.4.1.5. The only difference in the added-attendee notification is that the third line of text is changed to "with you as an added attendee" instead of "with you as an attendee" (see Figure 110 ). The notification is sent to newly-added attendees in lieu of the change notification shown in Figure 165. The process of accepting or declining an added-attendee notification is precisely the same as described in Section 2.4.1.5.

Each removed attendee receives a meeting delete notification, as described above near Figure 169. The only difference in the deleted-attendee notification is that the first line of text is changed to "User ... has deleted you as an attendee of the meeting" instead of "User ... has deleted the meeting". This notification is sent to removed attendees in lieu of the change notification sent to retained attendees.

2.5.2.2.4. Group Calendar Changes

When a meeting scheduler confirms a change or delete, the effects are reflected immediately in all attending group calendars. As explained in Section 2.4.1.6.1, only a group leader can schedule a meeting for a group. Accordingly, only changes made by a group leader affect the group calendar.

The set of categories defined for a group calendar consists of the union of the categories for all items appearing in the calendar. When a scheduler changes or deletes the category for a meeting, the change or deletion is reflected in the set of defined categories as necessary. Specifically,

1. if a category change leads to the definition of a new category, that category is added to the group calendar;

2. if a meeting deletion is for the last group calendar item that contains a particular category, that category is deleted from the group calendar.

Group calendars are "virtual" in the sense that they are not directly editable. Change and delete on group calendars is effected by a group leader when the leader changes or deletes on the leader's own calendar. Calendar Tool system administrators can purge items from a group calendar, as described in Section .

2.5.2.2.5. Non-Scheduler Changing and Deleting Meetings

Non-scheduler change or delete of a meeting is performed in basically the same manner as appointment change or delete. Non-scheduler change or delete affects only an individual user's local calendar and no attendee notifications are sent. As noted earlier, the item for any meeting is stored as an individual copy in each user's local calendar. This means that scheduler and non- scheduler changes are performed on separate copies of the same meeting. The scheduler and non-scheduler copies are merged whenever an attending user accepts a scheduler's changes.

The only meeting fields that a non-scheduler can never edit are `Scheduled By', `On', and `Host. This is because, as noted above, the set of values for these three fields constitutes the unique identification of a meeting on all users' calendars. All other fields are editable, subject to the following conditions:

1. the general data-entry rules in Section must be followed

2. the edit restrictions for recurring appointments in Section 2.5.2.1 must be followed;

3. if an item has not-yet-accepted scheduler changes, the data fields that the scheduler has changed are not editable in an item-level display until the user accepts or declines the scheduler changes.

Given the reasonably liberal policy for non-scheduler edits, it is possible for a user to make imprudent changes to a meeting. For example, changing the date or location is typically not prudent, unless the user has information of the change from outside the context of the Calendar Tool. When a non-scheduler executes the change operation, the system displays a general warning in the confirmation dialog, but imposes no further restrictions on the change. The alternative to this liberal change policy would involve a potentially complicated definition of what constitutes "legitimate" change to a meeting by a non-scheduler. The developers of the Calendar Tool requirements decided to avoid the complications of such a definition.

Change and delete operations are executed from the item-level view of a meeting. Examples of these views are shown in Section 2.5.1.2. The examples in that section show regularly scheduled as well as not-yet- accepted meetings. There are two additional forms of item view for meetings with not-yet-accepted scheduler changes or deletion. Items with not-yet- accepted scheduler changes appear in the form illustrated in Figure 171.

The display in Figure 171 contains the same information as the regular item- level view in Figure 137, with the addition of accept/decline command buttons at the bottom. For added clarity, the banner of the display is augmented with the "SCHEDULER CHANGED" text. The additional command buttons have the same functionality as in a change notification dialog, such as Figure 166. That is, the buttons allow the user to accept, decline, or view details of the scheduler's changes.

The data values in Figure 171 are those most recently entered by the user, independent of the scheduler changes. Hence, the not-yet-accepted changes to the `Duration' and `Details' fields do not appear. To see these changes, the user can select the `View ...' command, in response to which the system displays the detailed change notification dialog of Figure 166.

To prohibit conflicting changes, the system disables editing in data fields that have scheduler changes not yet accepted by the user. Hence, the `Duration' and `Details' fields are disabled in Figure 171. These are the same fields shown with blue highlight in the unedited notification dialog of Figure 166. The user can edit and confirm changes to any of the other editable data fields in Figure 171. The purpose of disabling scheduler-changed data fields in the item view is to force the user to edit such fields in the notification dialog, where they are clearly indicated as having been changed by the scheduler.

As explained in a preceding scenario, the scheduler-changed copy of the meeting is not officially a scheduled item in the user's calendar. As such, it does not appear separately in calendar views, only the user's copy so appears. The only access to the scheduler-changed copy is through the `View' command in the item-level view of the user's copy (Figure Figure 171 ) or in the meeting change notification ( Figure 165 ).

Once any scheduler-generated changes to a meeting are dealt with, the use may make any desired changes to a meeting. When the user presses `Change' in the item view of a non-recurring meeting, the system displays the confirmation dialog in Figure 172.

The change confirmation dialogs for recurring meetings differ in the first sentence of the dialog text. The first sentences are:

"Are you sure you want to change this instance
          of the recurring meeting?"

"Are you sure you want to change all instances
          of the recurring meeting?"

"Are you sure you want to change this instance and
  all future instances of the recurring meeting?"

When a user views an item with not-yet-accepted scheduler deletion, the display appears as shown in Figure 173.

The two groups of command buttons in Figures 171 and 173 correspond to the two different copies of a meeting with not-yet-accepted scheduler changes or deletion. The change/delete buttons operate on the pre- accept copy. The accept/decline buttons operate on the notification copy with the scheduler's not-yet-accepted changes.

Meeting deletion by a non-scheduler is processed in the same manner as appointment deletion, as explained in Section 2.5.2.1 The only difference is that the word "appointment" in the confirmation dialogs of Figures 155 and 156 is replaced with the word "meeting".

A non-scheduler deleting a meeting has no effect on any other users' copies of the meeting. In particular, a user who deletes a meeting is not removed from the attendees list in any one else's copy of the meeting.

After an attending user deletes a meeting, that user does not receive any subsequent change or delete notifications from the scheduler of the meeting. Operationally, this can mean that the notifications are never sent to the local computer, or are deleted upon receipt by the local computer. The effective behavior is that a user never sees change/delete notifications for a locally deleted meeting, i.e., a meeting deleted by an attending user but not by the scheduler.

It is possible for a meeting in the user's local calendar to be in the not-yet- accepted state when the scheduler makes (further) changes, or deletes the meeting. This is the case where the user has not yet accepted the original scheduling of the meeting, but the scheduler has made a later change or deleted the meeting. Operationally, there is no difference in such cases compared to that described above (around Figures 171 and 173 ), except that the banner of the item-level display window reflects the not- yet-accepted state of the original meeting. Specifically, when the scheduler changes a not-yet-accepted meeting, the item-level banner is "Not-Yet-Accepted Meeting -- SCHEDULER CHANGED" (cf. Figure 171 ). The banner for a scheduler-deleted not-yet-accepted meeting is "Not-Yet-Accepted Meeting -- SCHEDULER deleted" (cf. Figure 173. ).

2.5.2.2.6. Offline Scheduler Change and Delete

As noted in Section 2.5.2.2.1, the scheduler must be connected to the originating central host in order for meeting attendees to be notified of changes or deletions. If the scheduler is not so connected, she cannot change any critical meeting field or delete the meeting until a connection is re-established. If the scheduler attempts to confirm such a change or delete, the system displays the error message described in Section . The scheduler may change non-critical meeting fields when not connected to the originating host. When the scheduler confirms such a change, the system displays the warning dialog shown in Figure 174.

If the scheduler subsequently connects to the originating host, the attendees are not then notified. The scheduler must make and confirm additional changes in order to have the opportunity to notify attendees. When a subsequent change is confirmed while connected, it is based on the cumulative editing that has been performed, both online and offline, since the last time the meeting was synchronized.

2.5.2.2.7. Offline Non-Scheduler Changes

A non-scheduling user may make changes to her local copy of a meeting whether or not she is connected to the originating central host. The only operational difference when not connected is that the user may change a field that has also been changed by the scheduler. Such a change is possible when a scheduler change notification has not yet been received due to the lack of connection, or having set the notification option to `never'. When a scheduler change notification has been received, the system is able to prevent conflicting changes by disabling edits to scheduler-changed meeting fields, as shown in Figure 171. The system can continue to prohibit conflicting changes any time after the change notification has been received, even when subsequent changes are made offline. This is the case because the system retains the change notification on the local computer once received.

2.5.2.2.8. Conflicting Scheduler and Non-Scheduler Changes

A conflicting meeting change occurs when a non-scheduling user changes a meeting field that has also been changed by the scheduler, before the scheduler change notification has been received. As discussed in the preceding scenarios, the Calendar Tool system is designed to avoid conflicting meeting changes insofar as is possible. As long as a non-scheduling user remains up to date with scheduler change notifications, the system prohibits conflicting changes. The user can accomplish this up-to-datedness by retaining or establishing a central host connection any time prior to editing a scheduled meeting, and by not setting the meeting notification option to `never'.

A conflicting change becomes apparent to the non-scheduling user when the user reconnects to the originating host and then receives the scheduler's change notification. In this case, conflicting data fields are shown with red highlights. For example, suppose the user had made a conflicting change to the `Details' field of the meeting shown in Figure 166. In such a case, the change notification dialog would appear as shown in Figure 175.

Depending on the state of an attendee's connection to a central host, it is possible for a scheduler to send one or more change/delete notifications before an attending user accepts or declines any of them. The system retains only a single change/delete notification for any given meeting. The retained notification corresponds to the most recently confirmed change or delete executed by the meeting's scheduler. To be clear, there is a single notification for any particular meeting, corresponding to the most recent change or delete operation. There is not a separate notification for change and for delete. By the nature of the delete operation, once confirmed it is be the last notification produced by the scheduler. Hence, once a delete notification is sent, no further notifications will follow. The definition of a "particular meeting" is based on the unique identification provided by its `Scheduled By', `On', and `Host' values.

Pending change and delete notifications are stored in the same queue as initial meeting scheduling notifications, as described in Section 2.4.1.6.8. Change and delete notifications are commingled with initial scheduling notifications, in confirmation time order. For a change or delete operation, the confirmation time is defined as the time at which the scheduler presses the `OK' button in the change or delete confirmation dialog. For any given meeting, the system removes any existing notification from the queue before entering a later notification. If notification for a particular meeting is sent to a user at the same time the user is viewing a previous notification for that meeting, the newer notification is not added to the queue until the user makes the accept, decline, or delay decision for the earlier notification. If the circumstance arises where a scheduler sends two or more notifications while a user continues to view a previous notification, the system maintains the policy that at most one change/delete notification appears in the queue for any given meeting. When the user ultimately acts on an earlier notification, the system adds the single most recent notification to the user's queue.

2.5.2.3. Changing and Deleting Tasks

Changing and deleting tasks is much the same as appointments. The task fields that differ from an appointment are:

1. `Priority', which is numeric for a task

2. `Completed' and `Completion Date', which are not present in appointments

The change and delete confirmation dialogs for tasks are the same as they are for appointments, with the word "appointment" replaced with "task". When a task change or delete is confirmed, the calendar and display affects are as described for appointments.

2.5.2.4. Changing and Deleting Events

As with the other types of item, change and delete of an event is executed in the item-level display. For example, Figure 177 shows the user having edited the event scheduled in Figure 141.

When the user confirms an event change or delete, the user's calendar and active display windows are updated accordingly. Change of a multi-day event affects all of its days. Deletion of a multi-day event deletes all of its days. The effect of deleting one or more days of a multi-day event is achieved by changing the start or end date values. The start and end dates of a multi- day event always represent a contiguous range of days. Hence, the system provides no means to delete one or more middle days of an event, between but not including a start or end date.

The user cannot change or delete the system-defined events presented in Section There is an option to hide these events if the user does not want to see them.