Thanks for writing this up Philippe. See comments in-line. I think
there may be some misunderstandings about what prompts the switch to
'Updated by'. 'Updated by' only happens for message items that are
Sent when users click the 'Update' button in the toolbar. It never
applies to non-message items and sharing and syncing itself doesn't
result in the byline displaying 'Updated by'.
Mimi
On Mar 7, 2007, at 3:14 PM, Philippe Bossut wrote:
Hi,
Leaving the title with the erroneous "bi-line" spelling so that
your email reader thread this correctly...
Sheila Mooney wrote:
On Mar 1, 2007, at 8:29 PM, Mimi Yin wrote:
I also realized that there is a separate issue of what to show in
the Send as: pulldown as alternatives. I have edited the Email
spec with the following. (See bold paragraph for section what to
show in the pulldown.)
*What appears by default in the byline?*
For non-message items: Created by, Edited by
* User name associated with 1st Sharing account; if there are
no Sharing accounts;
* Don't show the byline
Open issue: What if the user has multiple Sharing accounts and
the same item is shared on multiple accounts?
For draft message items: Send as, Edited by
* Email address associated with 1st Outgoing email account
user has successfully filled out; if there are no Outgoing email
accounts...
* Email address associated with 1st Incoming email account
user has successfully filled out; if there are no Incoming email
accounts;
* User name associated with 1st Sharing account; otherwise
* Don't show the byline
* Note: If you receive a Draft item via server sharing,
Chandler does not change the Send as / Edited by field to your
email address unless you actually click into the Draft item and
make an edit.
*What are the options in the Send as:/Edited by: pulldown?*
*
*
* * If the user has filled out an Outgoing email account, only
show email addresses associated with Outgoing email accounts;
otherwise*
* * Only show the email address associated with the Incoming
email account or the Sharing account user name. Clicking on
either will spawn the Configure email account... dialog, so there
will be no opportunity to select alternatives.*
For sent/received message items: Sent by, Updated by
* Email address the item was sent with.
Philippe, does this provide more clarity on this issue?
Somewhat I still feel I have to read between the lines to make
sense of this. So, to cut through the chase, I'm reformulating the
whole thing the way I understand it. I'm using the email spec
(http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/
Email-0.7.html) rather than the here above extracted text since the
spec gives more context. I also incorporated changes suggested by
Bryan and agreed upon by Mimi later in that thread (namely, that we
will display a byline containing the date even if there's no
identity to be found, e.g. "Edited on 03/05/07").
Correct what is described above is specific to a few contexts:
+ User creates a new item
+ User edits an item
It doesn't describe what happens when you receive an item from a
sharee. Presumably the sharee's Chandler will assign the right value
to the byline before they sync.
First, I'd like to clarify that the text here above doesn't refer
so much to what goes into the byline than to what must be saved
into the item's lastModifiedBy attribute. It's clear for instance
that, if you sync the Office Calendar and select an item (say an
event) created by Helen the Hub on Monday, you are expecting the
byline to say "Created by Helen on 03/05/07". The problem with the
byline as implemented right now in the trunk (a placeholder for the
real thing for sure) is that because the lastModifiedBy attribute
is always set to None, all item say "Created by me on
<displayDate>", even when, clearly, I've nothing to do with their
creation.
So the byline text should be something like:
<edit type> <lastModifiedBy> on <displayDate>
- <edit type> must be chosen as appropriate within the following
list: Created by, Send as, Sent by, Edited by, Updated by
- if <lastModifiedby> is None, then the "by/as <lastModifiedBy>"
section is not displayed (that's the change suggested by Bryan IIUC).
Yup.
- displayDate being always present, I don't think there's a case
where we don't display the date... or is there?
Correct, there is *always* a displayDate.
(Note: for l10n reasons, the code shouldn't try to be too subtle
and join pieces of strings together but, rather, adopt a more brute
force approach so that translation of all the combinations can be
done with correct grammar in various languages. I'll add something
about this in the spec since it's off topic for this thread).
Now, onto my interpretation of Mimi's paragraph:
"""
*What the <lastModifiedBy> attribute should be: when creating or
editing an item, the <lastModifiedBy> attribute is updated as follow:
*
For non-message items:
- if the user has Sharing accounts: user name associated with 1st
Sharing account
- else if the user has no Sharing account: None
Yup
Open issue: The user may have several sharing accounts with
different user name. In such a case, the program should be able to
pick the correct user name but that could become tricky if the item
is shared multiple times or if the item is not shared at all. For
Preview, we'll simply pick the 1st Sharing account. Post preview,
the lastModifiedBy attribute should use the one of the user's
identities described in his/her contacts.
Yup
For message items (any item stamped as a message):
- if the user has outgoing email accounts: email address of the
1st outgoing email account
- else if the user has incoming email accounts: email address of
the 1st incoming email account
- else if the user has sharing accounts: user name associated
with 1st Sharing account
- else if the user has no account of any kind: None
Yup
Notes:
- "emailness prevails": that is to say that if an item is stamped
as a message, the message items rules apply
- If the user tries to send a message with no account set, the
"Configure email account" prompt will display. Once the account is
set, the item is updated (so that the message can be sent) and the
<lastModifiedBy> attribute should be modified accordingly
Yup, thanks for clarifying that.
- for message created/edited by the local user, the byline is
editable so the default here above described can be overwritten by
the user (who can choose an alternative email address from another
smtp account for instance). The <lastModifiedBy> should reflect
whatever account has been chosen.
Yup, ditto from above.
*What the <edit type> text should be: when displaying in the detail
view, the byline uses the following text:
*
For non-message items:
- if the item has never been modified: Created by
- else if the item has been edited locally by the user but not
synced: Edited by
- all other cases: Updated by
Non-message items can never be Updated by.
For message items:
- if the item has never been sent: Send as
- else if the item has been sent (or received) and has never been
edited: Sent by
- else if the item has been edited locally but never sent or
synced: Edited by
- all other cases: Updated by
Yup
Notes:
You mean these are additional Notes, not a reference to the Note Kind?
- a non shared item can have only "Created by" or "Edited by" as
text, it never turns to "Updated by"
'Updated by' happens when the item has been sent. A non-message item
can only have 'Created by' or 'Edited by', but never 'Updated by'.
- ideally, Chandler should have a notion of "edit session" and be
able to share that state so that a shared item could be seen as
"Edited by". I'm not sure we can get to that for Preview, can we?
I feel like there are a few scenarios where we want this.
Particularly wrt editing recurring events: http://
bugzilla.osafoundation.org/show_bug.cgi?id=8242.
"""
Issues:
- For an item I (local user) edit, it appears that the transition
from "Edited by" to "Updated by" happens after the next sync
(manual or background). Is that correct?
The item byline should display ;Updated by' as soon as the user Sends
the Update?
- For an item which is both shared and emailed, I suppose the
emailness overwrite the shareness and then the byline should say
"Send as <lastModifiedby>" rather than "Edited by <lastModifiedby>"
when editing. What if the item is synced but not sent? I still
think it should say "Send as" and not switch to "Updated by" (i.e.
emailness always win). Is that ok?
Then the item remains 'Send as'. 'Updated by' only appears if an
email has been sent. Sync by itself never prompts a switch to
'Updated by'.
- Ideally, Chandler should have a notion of "edit session" and be
able to share that state so that a shared item could be seen as
"Edited by". I'm not sure we can get to that for Preview, can we?
There's some domain model change here (if we need to share that
state) so I'm expecting Grant to pipe in
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
