2.5.2. Changing and Deleting Scheduled Items

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

Figure 140: Initial state of command buttons in all item- level displays.


What this means is that `Change' and `Clear' are not applicable until the user edits one or more data fields. Furthermore, the `Delete' command is only applicable prior to any data field editing, or after the user presses `Clear' to remove the edits.

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

Figure 141: State of command buttons after user edits one or more data fields.


The command buttons remain in the Figure 141 state until the user executes `Change' or `Clear', or re-edits all edited data fields back to their original values. Executing the `Change' command changes the item in the affected calendar(s) and all affected displays. Executing the `Clear' command clears all edits, restoring the data fields to their original values when the item-level view was initially displayed. No calendar changes are made when `Clear' is executed. When either `Change' or `Clear' is executed, the command button state returns to that of Figure 140. The command buttons also return to this state when the user re-edits all edited data fields back to their original values.

When the user executes and confirms `Delete', the system removes the item from the affected calendar(s), 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 all attending users.

As noted in Section 2.4.1.5, the system maintains a separate copy of a meeting item for the scheduler and for each attendee. Further, 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 requirements presented in Sections 2.5.2.2 through Section 2.5.2.5 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 142 shows the user having edited the date and time fields of the dentist appointment scheduled in Figure 7.

Figure 142: Date and time changes to the dentist appointment.


The changes are to the date, from September 25 to 29, and to the start time, from 8 AM to 8:30. When the user presses `Change' in this display, the system responds with the confirmation dialog shown in Figure 143.

Figure 143: Change confirmation dialog.


When the user presses `OK', the system changes the item per the edits made to the data fields. If the user presses `Cancel', the changes are not made. In either case, the confirmation dialog is removed from the screen and the item-level display again becomes current. In the `OK' case, the command button state is returned to its initial configuration ( Figure 140 ). In the `Cancel' case, the buttons remain in the edits-performed state ( Figure 141 ).

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 22 is changed to that shown in Figure 144, where the dentist appointment has been moved from 8-9:30 on the 25th to 8:30-10 on the 29th.

Figure 144: Updated view after confirmed appointment change.


All other display windows that contain the dentist appointment are updated to reflect the confirmed change. Further details of dynamic view updating are covered in Section 2.5.6

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 2.11.3. 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:

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

Figure 145: Edits made to a recurring appointment.


Here the start time for the September 29th instance of the racket ball appointment has been changed from 8-9 AM to 7-8 AM. When the user presses `Change', the system responds with the change confirmation dialog in Figure 146.

Figure 146: Confirmation dialog for changing one instance of a recurring appointment.


The user selects `OK' whereupon the system proceeds with the single- instance change and all necessary view updates. For example, the month view in Figure 144 is updated to that in Figure 147.

Figure 147: Updated view after another appointment change.


The figure shows the time change to the September 29th instance of the racket ball appointment. The times of the other instances on the 1st, 8th, 15th, and 22nd remain the same.

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

Figure 148: Additional edits made to a recurring appointment.


Here the user has changed the end date from December 31 to December 10. Of note is that the user moved to an instance other than the edited September 29. If the user had remained at September 29 to make the all-instance change to the end date, then the September 29 start-time change would be made to all instances as well. Since this is not what the user wants, the end-date change is made in another instance. Even after an individual instance has changed, it remains an instance of the same recurring appointment. Therefore, it may be used to effect changes to all other or all future instances. This issue is discussed further in Section 2.5.3.5.

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

Figure 149: Confirmation dialog for changing all instances of a recurring appointment.


When the user presses `OK', the system performs the change, which the user then inspects by opening the month view for December, shown in Figure 150.

Figure 150: Updated view after further appointment change.


The previously scheduled racket ball instances for December 15 through 31 are now gone.

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

Figure 151: Confirmation dialog for changing all future instances of a recurring appointment.


The dialog contains the appropriate wording change to reflect the `all future' selection.

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

Figure 152: Delete confirmation dialog.


The user presses `OK' to proceed with the delete, in response to which the system deletes the appointment from the user's calendar and removes both the confirmation dialog and item-level display from the screen. The system also updates any affected display windows by removing the deleted item. If the user 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.

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

Figure 153: Delete confirmation dialogs for a recurring appointment.


When the user presses `OK', the system deletes the one or more instances as selected, removes the item display from the screen, and updates all affected display windows by removing the deleted item(s). If the user selects `Cancel', no deletions are made and the item-level dialog is made current. In either case, the confirmation dialog is removed from the screen.

2.5.2.2. Scheduler Changing and Deleting Meetings

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

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 9 summarizes what changes, if any, are allowed by the scheduler and which field changes require attendee notification.


Data Field Changes Allowed Notification Required
Title any except empty no
(Start) Date any future date, with warning if conflicts detected yes
End Date same as Start Date yes
Start Time any, with warning if conflicts detected yes
Duration same as Start Time yes
Recurring any, with warning if conflicts detected yes
Category any no
Security any no
Location any available at time(s) of meeting yes
Priority any no
Remind any no
Attendees none  
Details any no
Minutes any no
Scheduled By none  
On none  

Table 9: Summary of allowable changes to meeting data fields by the scheduler.


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

Figure 154 shows edits made by the scheduler to the staff meeting confirmed in Figure 85.

Figure 154: Duration and details changes to the staff meeting.


The changes are to increase the duration from 1 hour to 1.5 hours and to update the agenda. When the scheduler presses `Change', the system responds with the confirmation dialog in Figure 155.

Figure 155: Confirmation dialog when scheduler changes critical meeting field, with conflicts.


The contents of this dialog reflect two conditions of the change:
  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.
If the scheduler chooses `OK', the system proceeds with the change on the scheduler's calendar and notifies all attendees of the change, except for the scheduler. If the scheduler chooses `Cancel', the system performs no changes. In either the `OK' or `Cancel' case, the confirmation dialog is removed from the screen and the item-level meeting display becomes current.

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

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 156 shows the scheduler having edited an instance of the recurring lecturer meeting scheduled in Figure 88.

Figure 156: Scheduler edits a recurring meeting.


The change is to the `Minutes' field for a single meeting instance. In this scenario, the current date is assumed to be after the first occurrence of the lecturer meeting, so the change to the `Minutes' field is considered a normal operation. When the scheduler presses `Change' in Figure 156, the system displays the dialog in Figure 157.

Figure 157: Confirmation dialog when scheduler changes non- critical meeting field in a recurring meeting.


Because no critical data field has changed, the dialog provides the option of whether or not to notify all attendees. In this case, the scheduler leaves the default `Notify' setting on and presses `OK', whereupon the system updates the scheduler's calendar, updates any affected displays on the scheduler's screen, and notifies all attendees of the change.

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

Figure 158: Location change to future lecturer meetings.


The figure reflects the scheduler having navigated to the October 1 instance, i.e., the scheduler did not change the instance date. The changes are to the `Location' and `Details fields. Location is a critical field that requires attendee notification. The `Details' field has a textual note indicating the location change. This is an example of using `Details' for a slightly different purpose than may be typical, viz., a note about a change. Since this change will appear in all future instances, the scheduler may later perform individual edits to the `Details' field.

When the scheduler presses `Change' in Figure 158, the system displays the dialog of Figure 159.

Figure 159: Confirmation dialog when scheduler changes critical field for future instances.


When the scheduler confirms the Location change, the system checks that the new location is available at all meeting times, that is, the times of all future instances. If it is not available, an error message is issued, as discussed in Section 2.12.4.4 The system also performs the appropriate calendar and display changes.

Figures 155, 157, and 159 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:

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

Figure 160: Confirmation dialog for scheduler-deleted meeting.


Scheduler deletion of a meeting always requires attendees notification. Therefore the delete confirmation provides no notification option.

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

Figure 161: Confirmation dialogs for scheduler-deleted recurring meeting.


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 cancelled 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. The cancellation text will be visible to users in bold red type in the notification details dialog, as described in the next section.

2.5.2.3. Meeting Change and Delete Notifications

When the scheduler changes a meeting, the system notifies each attendee, except the scheduler, with a dialog of the form shown in Figure 162.

Figure 162: Meeting change notification.


This is a notification for the change made in Figure 154. The message indicates the scheduler's ID plus the time and date of the changed meeting.

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

NOTE: this change conflicts with N existing item(s).
where N is the number of scheduled items that have overlapping times with the changed meeting and "item(s)" is singular if N = 1, plural otherwise.

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 162, the system responds by displaying the notification details dialog in Figure 163.

Figure 163: Viewing details of a meeting change notification.


The changes made by the scheduler (in Figure 154 ), are highlighted in boldface red font. If the scheduler has changed the `Category' field, the category name is highlighted in boldface font, but in the normal color of the category. There is no category change in this scenario. For all other changed data fields, the entire field value is displayed in bold red, not just the individual characters or lines to which edits were made.

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

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 162 ) and the larger details dialog ( Figure 163 ) 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 made.

To delay the accept/decline decision, the user can close the notification dialog window, using the `View Windows Close' command. 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 163, 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 164.

Figure 164: Change notification details dialog edited.


In this scenario, the viewing user is one of those for whom the scheduler's change has created a conflict, as indicated in the small notification dialog in Figure 162 Therefore, the user re-edits the duration to avoid the conflict. This is an example where a user legitimately edits a scheduler-generated data value. The issue of what constitutes a "legitimate" user edit of a meeting is discussed further in Section 2.5.2.5.

When the user presses `Accept' in Figure 164, 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 110 ). The `Duration' field was edited by the scheduler ( Figure 154 ), but then subsequently edited by the user in the notification dialog ( Figure 164 ). 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.

The detailed notification dialog reflects change merging when it is initially displayed. Hence, the `Title', `Category', and `Remind' fields in Figure 163 contain the values most recently entered by the user, not the older values that appeared in the scheduler's view in Figure 154. Any user edits made in the notification dialog are reflected in the ultimately accepted changes. In this case, `Duration is so edited. Hence, when the user executes `View Item' after pressing `Accept' in Figure 164, the system displays the item-level view shown in Figure 165.

Figure 165: Scheduler changes merged into meeting.


This item-level view contains exactly the same data values as Figure 164. The item view has a date banner at the top, with `Change' and `Delete' command buttons instead of `Accept' and `Decline'.

The policy to merge only the most recent changes may not be optimal in all circumstances. For example, if the user changes a data field and the scheduler subsequently changes the same field, the user might prefer her own less-recent field value. Such circumstances are presumed to be uncommon, so 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.

To be clear, there are two separate copies of a not-yet-accepted meeting for each user who has not yet accepted or declined scheduler changes. The copy in the item-level display reflects the unchanged version of the meeting, as it is stored in the user's local calendar. The copy shown in the change notifcation details reflects the scheduler's changes. The scheduler-changed copy is stored in the Calendar Tool central repository. Details of the central repository are covered in Section 2.14.

To undo any edits made after the change confirmation dialog is initially displayed, the user can press `Clear'. As illustrated in Figures 163 and 164, 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"
The user ID is the ID of the scheduling user. In the one-instance and future-instance messages, date is the instance date. For the all- instances message, date is the start date.

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

Figure 166: Delete notification dialog.


This is the notification for the meeting scheduled in Section 2.4.1.4. For deletion of a recurring meeting, the dialog text is changed in the same way as for a change notification, with the word "changed" replaced with "deleted".

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

Figure 167: Viewing details of a meeting delete notification.


To the left of the command buttons is a label explaining that the buttons apply to a deletion performed by the scheduler. The user may edit any data fields accept `Scheduled By' or `On'. Performing edits is only meaningful if the user plans to decline the deletion. The user may choose to do so if she wants to retain a copy of a cancelled meeting.

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 169 of Section 2.5.2.5. 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 111. 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.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. 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.5. Further details of dynamic view updating are covered in Section 2.5.6. When the `hide' setting is selected, meeting items changed by the scheduler appear in normal form, not penciled-in.

It is possible for a scheduler to produce multiple change or 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' and `On' values.

Pending change and delete notifications are stored in the same queue as initial scheduling notifications, as described in Section 2.4.1.6.7 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.

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 dialog is allowed to appear, the notification is removed from the queue and the system never displays it.

2.5.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.6.7.1.3.

2.5.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 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 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. What it means to have separate copies of the "same meeting" is that values of the `Scheduled By' and `On' fields are the same. The pair of values for these two 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 only meeting fields that a non-scheduler can never edit are `Scheduled By' and `On'. All other fields are editable, subject to the following conditions:

  1. the general data-entry rules in Section 2.11.3 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 until the user accepts of declines the scheduler changes.
Of note is that the scheduler editing restrictions in Table 9 do not apply to non-schedulers.

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

Figure 168: Item-level view of meeting with not-yet-accepted scheduler changes.


This is the item-level view of the changed staff meeting before the changes have been accepted by the user, and before any changes have been made in the change notification dialog. That is, it is the result of a `View Item' command for the meeting changed by the scheduler in Figure 154, before the user has performed any action in the change notification dialog.

The display in Figure 168 contains the same information as the regular item- level view in Figure 134, 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 163. That is, the buttons allow the user to accept, decline, or view details of the scheduler's changes.

The data values in Figure 168 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 163.

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 168. These are the same fields shown in bold red type in the unedited notification dialog of Figure 163. The user can edit and confirm changes to any of the other editable data fields in Figure 168. 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.

When the user presses `Change' in the item view of a non-recurring meeting, the system displays the confirmation dialog in Figure 169.

Figure 169: Non-scheduler change confirmation dialog.


The dialog informs the user that changing an individual copy of a meeting is likely to result in differences with other users, namely the scheduler and other attendees. It is "likely" in the sense that the user's version will differ from other users unless all of them make exactly the same changes. When the user presses `OK', the system proceeds with the change on the user's local copy and updates all affected displays. Pressing `Cancel' in the confirmation dialog results in no calendar or display changes.

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?"
the appropriate one of which appears based on the user's setting of how many instances to change.

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

Figure 170: Item-level view of meeting with not-yet-accepted scheduler deletion.


As in Figure 168, there are both change/delete and accept/decline command buttons. In this case, the label beside the accept/decline buttons indicates that they apply to a not- yet-accepted scheduler deletion.

The two groups of command buttons in Figures 168 and 170 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 a copy reflecting 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 152 and 153 is replaced with the word "meeting".

After a non-scheduler deletes a meeting, that user will not receive any subsequent scheduler change or delete notifications for the meeting.

2.5.2.6. 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
Editing functionality for all other fields is the same as for appointments. Figure 171 shows the user having edited an instance of the recurring task shown in Figure 137.

Figure 171: Edits made to a recurring task.


Here the `Completed' check box has been turned on by the user. When the user turns `Completed' on, the system responds immediately by entering today's date in the `Completion Date' field. The user may edit the completion date to any legal, non-empty date value. The system imposes no range restrictions on the completion date, meaning a task can be completed any time before, on, or after its due date. In the case of Figure 171, the user changes the system-entered value of September 23 to September 21 and presses `Change'. If the user turns `Completed' off after having turned it on, the system clears and disables the `Completion Date' field.

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.7. 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 172 shows the user having edited the event scheduled in Figure 138.

Figure 172: Birthday event changed.


The edits are a change of the start date from September 23 to September 25, and a change from private to public security. When the user presses `Change', the system displays the dialog in Figure 173.

Figure 173: Event change confirmation dialog.


The event delete confirmation dialog is the same as that for change, with the word "change" replaced with "delete". Since events do not recur, there is only a single form of change and delete confirmation dialog. There is no distinction between single-day versus multi-day events in either confirmation.

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 2.11.12 There is an option to hide these events if the user does not want to see them.



Prev: item-level-viewing | Next: recurring-details | Up: finer-points | Top: index