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.
Figure 143: Initial state of command buttons in all item- level displays.
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.
Figure 144: State of command buttons after user edits one or more data fields.
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.
Figure 145: Date and time changes to the dentist appointment.
Figure 146: Change confirmation dialog.
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.
Figure 147: Updated view after confirmed appointment change.
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:
Figure 148 shows the user having edited an instance of a recurring appointment.
Figure 148: Edits made to a recurring appointment.
Figure 149: Confirmation dialog for changing one instance of a recurring appointment.
Figure 150: Updated view after another appointment change.
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.
Figure 151: Additional edits made to a recurring appointment.
The user proceeds to press `Change' in Figure 151, in response to
which the system displays the confirmation dialog in Figure 152.
Figure 152: Confirmation dialog for changing all instances of a recurring appointment.
Figure 153: Updated view after further appointment change.
If the user changes an appointment with `all future' selected, the
system displays the dialog of Figure 154.
Figure 154: Confirmation dialog for changing all future instances of a recurring appointment.
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.
Figure 155: Delete confirmation dialog.
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.
Figure 156: Delete confirmation dialogs for a recurring appointment.
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.
Changed By
Scheduler |
Changed By
Non-Scheduler | Color |
no | no | black |
yes | no | blue |
no | yes | green |
yes | yes | red (a conflict) |
Table 9: Color Coding of Meeting Changes in Change
Notification Display.
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.
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 | any, with warning if conflicts detected | yes |
Details | any | no |
Minutes | any | no |
Scheduled By | none | |
On | none | |
Host | none |
Table 10: 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
Figure 157 shows edits made by the scheduler to the staff meeting confirmed in
Figure 88.
Figure 157: Duration and details changes to the staff meeting.
Figure 158: Confirmation dialog when scheduler changes critical meeting field, with conflicts.
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:
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 159: Scheduler edits a recurring meeting.
Figure 160: Confirmation dialog when scheduler changes non- critical meeting field in a recurring meeting.
Figure 161 shows another change to the lecture meeting, this time to future
instances, at and beyond the October 1 instance.
Figure 161: Location change to future lecturer meetings.
When the scheduler presses `Change' in
Figure 161,
the system displays the dialog of Figure 162.
Figure 162: Confirmation dialog when scheduler changes critical field for future instances.
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:
"The change will create a time conflict for the following users:"with the IDs of all affected users listed below the message.
"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?"
"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.
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.
Figure 163: Confirmation dialog for scheduler-deleted meeting.
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.
Figure 164: 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
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.
Figure 165: Meeting change notification.
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).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 165,
the system responds by displaying the notification details dialog in Figure
166.
Figure 166: Viewing details of a meeting change notification.
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.
Figure 167: Change notification details dialog edited.
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.
Figure 168: Scheduler changes merged into meeting.
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
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.
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"
Figure 169: Delete notification dialog.
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.
Figure 170: Viewing details of a meeting delete notification.
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.
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,
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:
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.
Figure 171: Item-level view of meeting with not-yet-accepted scheduler changes.
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.
Figure 172: Non-scheduler change confirmation dialog.
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 instancethe appropriate one of which appears based on the user's setting of how many instances to change.
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.
Figure 173: Item-level view of meeting with not-yet-accepted scheduler deletion.
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.
Figure 174: Warning when changing a meeting while not connected to the originating host.
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.
Figure 175: Conflicting change.
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:
Figure 176: Edits made to a recurring task.
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.
Figure 177: Birthday event changed.
Figure 178: Event change confirmation dialog.
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.