Hi, Mimi
I went over the changes you outlined and those make sense.
I've quoted the newly added "Sending, Editing and Updating Recurring
Events" section below, and added comments inline.
--Grant
In the Preview timeframe: Send, Update, Forward and the Addressing
fields will only apply to the entire event series.
In order to achieve this simplification, we need to be able to keep
track of edits on a per attribute basis. Grant and Jeffrey are
working through the details of this as I write.
This will be new functionality.
Currently if I change the Title of a single instance of an event
series, the event becomes 'detached' from the series, which means
that if I then go to edit the Location of that event, I can no
longer apply my change to the entire series.
Similarly, if I apply a global edit to the Location field from a
different instance in the event series, that global edit will not
apply to this 'detached' instance.
As of a couple of weeks ago, this feature landed in Chandler trunk.
So, I guess all the future tenses need to become past (i.e. move from
LATER to DONE :).
Open issues:
1. When/if we support per instance, per attribute modifications
to recurring events, then we will be able to do things like modify
an attribute on a single instance, while still applying global
edits to the series on all other attributes.
Yes.
Also, the answer to
6. If so, can we mark individual instances of a recurring event
or the 'This and Future' subset of a recurring event series as
'Needs reply'?
is Yes.
As a general comment to 2--5 and 7--8 below, I'm wary of trying to do
things like replying to individual instances of events. While the
domain model can handle (or be made to handle) this kind of thing,
ICalendar isn't very well suited to yanking individual occurrences
out of recurring series, so I'm concerned we'll have trouble with non-
Chandler clients. In oither words, I think it's a similar situation
to allowing individual occurrences within a series be in different
collections.
2. How should forward work on recurring events? What do we
display in the Notes field when forwarding a recurring event series
that has modified instances in it?
3. Can we just display the attribute values from the Master event?
4. How should reply work on recurring events?
5. Can we reply to individual instances of a recurring event, or
the 'This and Future' subset of a recurring event series?
7. Replying to an individual instance or the 'This and Future'
subset of a recurring event series would mean the following:
8. Displaying the right thing in the Notes field of Reply message:
* If you are replying to the entire series, display the
metadata from the master event
* If you are replying to a single instance, display the
metadata from that single instance
* If you are replying to the 'This and Future' subset of the
recurring event series, display the metadata from the
* Allowing users to choose between All, Just this event, and
This and Future when marking an item as 'Needs reply'.
* Post-preview, it will mean keeping track of which instances,
or which subset of instances have been 'Replied to'.
Please see the Preview email spec for more details about what
'display the metadata from' means: http://svn.osafoundation.org/
docs/trunk/docs/specs/rel0_7/Email-0.7.html
On 13 Feb, 2007, at 18:53, Mimi Yin wrote:
Please review and reply with comments/questions. In particular, I'm
not sure if there have been changes in thinking around edited by/
last modified that should be captured in the spec. Grant?
http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/
Stamping-0.7.html
I have updated the Stamping Spec from the following wiki documents:
+ http://wiki.osafoundation.org/bin/view/Journal/EmailStamping20061121
+ http://wiki.osafoundation.org/Journal/
DashboardSharingCommunicationsRecurrence
I did not incorporate: http://wiki.osafoundation.org/Journal/
NoDataLossProposal. I think we should let that proposal solidify
before adding it to the Sharing spec and then cross-linking from
the Stamping spec. For now, I have a link in the Stamping spec to
the wiki spec.
Most of the changes are just documenting things we've already
agreed on in meetings and on the list. Hopefully, nothing here is
surprising :o)
+ Calculating whether message items are Inbound or Outbound, aka
fromMe, toMe and attendant UI behavior
+Nit-picky scenarios about what to do when replying to a message
where the Sender is *not* mentioned in Addressing fields. (Answer:
automatically add Sender to the CC: list).
+ Nit-picky scenario about what to do when the Sender of a message
*is* mentioned in Addressing fields. (Answer: don't pull down
duplicate message from server.)
+ Sending, Editing and Updating Recurring Events (same as what was
in the Dashboard spec).
There is also a body of material around how to package up Chandler
items in Emails. I will track that in the Email spec with a cross-
link from the Stamping spec.
Thx!
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
