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

[Mimi Yin]

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

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