Meeting to get update on Edit/Update workflows

• Understand where we are
• Given the work that has been done so far, are there any questions

Update on status and discussion on issues

• Grant
  • Stuff done
  • Most of the work to date has been done by Grant
  • Added stuff to the domain model to track if items have been edited, updated, queued
  • Added something for an error status
  • Was going to add a status for created but there was a problem with recurrence so we left out created state for now
  • When you create something for the first time is says created by, as soon as you make and edit (commit out of the field), it changes to edited by
  • Call inside domain model - now making this edited by this user at this time
  • The communication status column now understands this stuff...send and email and get an error - it shows up in the table with an icon.
  • Added the by-line field to the detail view
  • Not done yet
  • Nothing done with last modified by - always me
  • Still some work to be done on recurrence
  • UI still rough
  • Read/unread/needs reply is already done

• BKirsch
  • Email merging - talked about architecture with PJE
  • PJE came up with a concept of using 2 states of an item (before and after changes) that are serialized as XML
  • Added as attachments to the email
  • We receive this in Chandler and pass it off to be deserialized - unpack and do the right thing.
  • PJE - clarify assumptions
    • Sharing that doc with a group and you can keep track of state within that group - sharing via email
    • Which version is the before state, how do we keep track of this.
    • Keeping track of this before version allows you to determine what has changed and to see if there is a conflict
  • Mimi - question about problem of storing whole history. How many versions can get created before it's an issue.
  • Jeffrey - keep unique id for a revision and keep a list of all the particular revisions. PJE - problem with this, it's not unique. Still have the order issue.

• Need to handle some conflict resolution for email updates
• Present info to user - they make the decisions manually
• Adding a UI and if I conflict is detected, the UI comes up that shows what just got overwritten
• Mimi - in edit/update, how do we figure out which update to show in the detail view and what to show in the conflict dialog.
• Seems wrong to just accept the email changes. Mimi wants to have us discard updates in favor of your local changes - if there is a conflict.
• We could have updates all come into the dialog and not overwrite what's in the detail view.

• PJE - idea for addressing these issues
• When we receive updates to an item that we can't apply - we keep some kind of note (fyi) about this and users can choose to reject, apply.
• Rather than having a pre-emptive UI for handling this, you can see this information - who changed what, when to make the decision.
• Message could be out of order and really aren't a conflict.
• This sounds alot like what we are trying to accomplish with clusters.
• Which change wins if the user doesn't take any action. By winning we mean what appears in the detail view.
• We could use the rule to apply changes to the detail view based on the sent date of the email.
• This will apply changes consistently to everyone.
• If someone doesn't get an email, we can't really do anything about this.
• FYis that weren't conflicts won't show up in the dialog.
• Instead of FYI, we should call these pending changes.
• The rules to determine what appears in the detail view and what appears as a pending change should be the same for both sharing and receiving email updates.
• We will do some more research to determine which route we want to take ie pending change= update+server vs pending change=user's local change.

• Are there still some issues that people are concerned about?
  • BKirsch - wants to work through some very complex use cases. Is worried about cases when users get info out of band. Look at Mimi's use cases on the wiki.
  • Our proposed solution should handle most of these.

-- SheilaMooney - 09 Jan 2007