Hi, Mimi
More inline ...
On 30 Mar, 2007, at 14:01, Mimi Yin wrote:
Y would U ever look in the sharing spec for stuff on conflict
resolution?
http://wiki.osafoundation.org/Journal/NoDataLossProposal
Aha ... I figured it was somewhere, but didn't take the plunge from
Specland into Wikinia ...
On Mar 30, 2007, at 11:11 AM, Grant Baillie wrote:
While fixing/working around Bug 8597, I looking in the Sharing
spec about how conflicts in recurring events should be handled by
the conflicts dialog, but I didn't see anything. Is it in another
document somewhere?
FWIW, here's what I think we should do here:
It's possible for an occurrence (a.k.a. modification) and its
master both to have conflicts. Since we never show masters in the
UI, I think it makes sense to show both the occurrence and the
master's conflicts in the dialog. It might require a little bit of
footwork to get this right, but I don't think it's too difficult.
Can you give a specific example? I still get confused re: master
events. Do they look like the 1st occurrence even if the 1st
occurrence was modified? Or are they the 1st occurrence as it
looked before it had any modifications. If it's the latter, I can't
remember why we don't show the master occurrence anymore. If it's
the former, then ick.
It's the latter; we don't show it because it largely duplicates the
first occurrence.
As an example, if someone shares a brand-new recurring series, say a
weekly meeting at 1:15PM every Tuesday, a conflict in the master
would occur if 2 users made ALL changes to one attribute. So, if 1
person changed all meetings to 1:00PM on Tuesday, and another to
1:15PM every Thursday, those users would have a start-time conflict
to the master.
A conflict to an individual occurrence happens when two people change
the same attribute of a particular occurrence (a THIS change). So,
two people might add different agenda items to the start of the body
of next week's meeting.
For bonus brownie points, we could not duplicate conflicts on a
given attribute. In other words, if a modification had a conflict
on "displayName", and the master did, too, we would only show the
modification's conflict.
Or wouldn't ever occurrence in the series have that conflict? That
might be a better way to represent 'conflicts on master events'.
Every occurrence would have that conflict. Technically, ones that had
a modification of the conflicting attribute(s) don't really have that
conflict, but maybe this is splitting hairs (or is a case that's nice
to have).
--Grant
Does that sound reasonable?
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
