https://bugzilla.osafoundation.org/show_bug.cgi?id=10799
To quickly summarize, I believe there are actually 2 EIM / end-user
modeling issues to be worked out. I will address 1 here and start a
2nd thread about the other.
1. There isn't a 1:1 mapping between EIM fields and end-user
attributes (as in the fields you see in the detail view for any given
item).
For example the 'From:' field in the Detail View corresponds to the
'Originators' field in EIM. the 'fromAddress' field in EIM is used to
determine the value of the 'Originators' field, but does not itself
have a corresponding end-user DV field. See https://
bugzilla.osafoundation.org/show_bug.cgi?id=10788#c16 for a more
detailed discussion.
Currently however, if an item's 'fromAddress' (EIM field) changes,
the item is marked as edited and moved to the top of all subscribers'
NOW sections regardless of whether the change in 'fromAddress'
actually resulted in a corresponding change in 'originators'. As a
result, when subscribers view the details of the item, they often
can't see that anything has changed.
Bug 10799: https://bugzilla.osafoundation.org/show_bug.cgi?id=10799
is about scenario #1
Morgen has provided a list of the EIM fields and wanted to know which
fields should be *excluded* when deciding whether or not to mark a
shared item as edited. The short answer to that question is that any
EIM field which does not directly result in a change in a end-user
visible DV field should be excluded.
Additionally we've concluded that all non-shared end-user attributes
should be excluded. This includes 'read/unread/needs reply' and
'appears in' should be excluded as well.
I also think it would make sense to *not* mark an item as edited and
*not* record that an user edited an item if the 'edit' essentially
consists of the item moving to the top of the NOW section because a
*shared alarm* fired or because the *event start date/time* rolled
around. That's something that will happen to all subscribers
independently.
Who would know best the details around how EIM maps to Detail View
fields? Stearns? BKirsch?
Stearns also raised an issue about DisplayAlarm if events are in
floating time zones: https://bugzilla.osafoundation.org/show_bug.cgi?
id=10799#c2
Finally, re DisplayAlarm, I don't know how sharing of alarms is
supposed to
work: If you're in an earlier timezone than me, a floating event's
alarm will
fire for you before it fires for me. If you sync, then I sync, does
that
prevent the alarm from going off for me?
Hopefully shared events in floating time zone will be an edge case,
given all the 'turn on time zones' dialogs we pop up when people
publish and subscribe to shares. However, in the event that it
happens, alarms should probably *not* be prevented from going off for
the 2nd user who is in a 'later' time zone.
===
Item Record:
title
triage
createdOn
hasBeenSent
needsReply
read
Note Record:
body
icalUid
icalExtra
Event Record:
dtstart
duration
location
rrule
exrule
rdate
exdate
status
lastPastOccurrence
DisplayAlarm (Reminders) Record:
description
trigger
duration
repeat
Mail Message Record:
messageId
headers
fromAddress
toAddress
ccAddress
bccAddress
originators
dateSent
inReplyTo
references
mimeContent
rfc2822Message
previousSender
replyToAddress
messageState
On Sep 17, 2007, at 1:46 PM, Morgen Sagen wrote:
I filed a bug *** on myself to track the need for a mechanism which
would allow certain inbound changes to be ignored when determining
whether an item should be marked unread or moved to the NOW section.
Mimi asked me to move the requirements discussion of this bug to the
design list. See the bug report for the list of fields that are
shared, and let me know which of these should be ignored.
*** https://bugzilla.osafoundation.org/show_bug.cgi?id=10799
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
