Here is an addendum to the 0.7 Sharing Spec: http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Sharing-0.7.html

I'm attempting to pull together everything that has changed, been added since the 0.7 Sharing Spec was written for 0.7Alpha4. That includes:

• New Default sharing account
• New EIM Sharing filters
• Weird Item Soup on the Server and Read-only scenarios via Sharing and Edit/Update
• 1st time subscribe versus subsequent sync
• Unpublishing shares from the server
• Conflict resolution

Default sharing account

Previously, we had a notion of user-defined default Outgoing mail and Sharing accounts.

For various reasons, we no longer have a notion of user-defined default accounts. Although we still have default, OOTB accounts. They are merely default because:

• They appear OOTB
• They cannot be deleted
• They always appear at the top of account pulldowns:
  • Sharing account pulldown when publishing shares
  • Send as: or Edited by: pulldown when selecting an email account to send a message from

If an user does not fill out an OOTB account, but instead creates a new one of their own. The OOTB account will be skipped in the pulldowns and the new user-defined one will be used instead. This behavior is also described in the Email Spec, under 'Default account behavior': http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Email-0.7.html

For list discussion, see: http://lists.osafoundation.org/pipermail/design/2007-April/006981.html

---

Sharing filters

The following sharing filters are set by default on all Desktop clients:
Share:
[x] Triage status
[x] Event status
[ ] Alarms
[ ] Needs reply status
[ ] BCC

Publishers and Subscribers can check and uncheck sharing filters at will. In other words, Subscribers are no longer at the mercy of Publishers when it comes to deciding what attributes to share.

The Hub UI won't have this capability in the Preview timeframe, so I'm proposing that we 'hard-code' the default sharing filter settings into Hub UI. Triage status and Event status will appear in the Hub UI and will be shared amongst all Hub UI users, even if Desktop users opt out of sharing Triage status. The other attributes: Alarms, Needs reply status and BCC simply won't appear in the UI.

For list discussion: http://lists.osafoundation.org/pipermail/design/2007-April/007027.html

Known issues:

• As soon as a Desktop user changes the OOTB default sharing filter settings, Hub users will get out of sync with Desktop users.
• Desktop subscribers may also get out of sync with Publishers because for Preview, subscribers will not be able to see the what attributes the publisher would like to share. We are hoping to mitigate this problem by 'hiding' the sharing filters from subscribers in the 'Manage share' dialog.

Note: Previously I had thought that in order to share Triage status, users should also be required to share Alarms, because Alarms govern when items are triaged to NOW, this is also known as the Tickler workflow. But I no longer think this is serious enough to warrant preventing users from setting their own alarms.

Workflow

• Desktop User A publishes a share and customizes the sharing filters to share everything.
• Desktop User B subscribes and by default is only sharing Triage Status and Event Status. If Users A and B communicate out of band, User B can find out that User A actually wants to share everything.
• Hub users can only share Triage Status and Event Status. They cannot see Alarms, Needs reply status or BCC.

Note: If users decide to share Triage Status, under the hood, they are only sharing buttonTriageStatus, never sectionTriageStatus.

• User A triages a DONE item to LATER, but keeps the item in the DONE section.
• User B syncs and sees the item in the NOW section (because it has been recently changed), and also sees that the item has been triaged to LATER.

---

Weird Item Soup on the Server and Read-only scenarios via Sharing and Edit/Update

To prevent users from accidentally editing read-only items, we are going to make the rules around read-only access stricter than they have previously on the Desktop: If an item exists in one read-only collection, then it will be read-only in all collections.

Known issues:

• There will be some weird edge cases where users will be 'locked out' of their own items. ie. User A shares a collection with user B. User B adds some items from User A's collection and shares them back with User A read-only in a separate collection. User A can no longer edit items that they created.
• There will still be weird edge cases around Edit/Update:
  • User A shares a collection read-write with User B using Chandler Hub Sharing.
  • User B sends some of these items to User C.
  • User C edits one of them and then uploads the item to Chandler Hub in a completely different collection that neither User A nor User B knows about.
  • User A and B see User C's edits, even though neither of them are aware of the fact that they are 'sharing' with User C, just that User C has received the item via Email.
  • User C is unaware of the fact that User A and B can see their edits, even without them explicitly hitting the Update button.

• For background on how we came to this proposal: http://lists.osafoundation.org/pipermail/design/2007-May/007074.html
• For more on weird item scenarios, see: ReadOnlySecurityHoleScenarios

Open issues:

• Can we replicate this behavior on the Hub UI?

---

Enhancements

• 1st time subscribe versus subsequent sync
• We added behavior so that the first time you subscribe to a share, all items are marked as Read. Only on subsequent syncs are newly created and edited items marked as Unread. bug#8809
• Items will also be automatically filed into the appropriate sections on import and first-time subscribe as well. bug#9212

• Unpublishing shares from the server
• When unpublishing shares from the server (and removing shares from the server via the Account Browser), only items that 'only belong to the collection that is being unpublished' should be deleted. If an item also belongs in a different collection on the server, then it should not be deleted.

• Automatically sync when starting up Chandler

---

Conflict Resolution

See: NoDataLossProposal

-- MimiYin - 04 May 2007