[Design] Which inbound changes should be considered/ignored for marking an item unread or moving to the NOW section

[Mimi Yin]

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070917/fb89a760/attachment.html