Morgen, is the funkiness with the 'from' attribute a bug? As in a
change from the EIM from-field isn't being passed correctly to the
'originators' field and so nothing is changing in the detail view?
Or is the problem just that we need to exclude the 'from' field from
the list of attributes that when they are changed, mark an item as
having been edited?
If it's the latter, I'm wondering if it would be quick to first fix
the 'from' field while we're working through the other EIM-to-user
attribute translation issues.
Mimi
On Sep 17, 2007, at 2:49 PM, Mimi Yin wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
