Modeling of Sharing Invitations/Reponses

Publishing and Sharing invitations are (at least internally) two completely separate notions, and need to be modeled/tracked.

We need to model a SharingInvitation^?; it's an item which tracks the lifetime of a particular invitation between sharer and sharee. There will be one of these items per collection-sharee pair, i.e., if a sharer shares a collection with three sharees, then three SharingInvitation^? items are created.

Kind SharingInvitation^?

• sharer
• collection
• sharee
• state:
  • NotSent^? (haven't attempted to SMTP it)
  • Sent (successfully got past SMTP)
  • Failed (failed to get past SMTP)
  • Bounced (successfully got past SMTP but bounced later on)
  • Rejected (invite made it to sharee, but they rejected the invite)
  • Accepted (invite made it to sharee, they accepted the invite)
  • AcceptedButProblem^? (accepted, but sharee couldn't fetch collection)

To aid in verification, the UUID of the actual SharingInvitation^? item could be sent in the invite email, and when the sharee replies to the invite it could include that UUID as a sanity check for matching the response to the invite.

Not sure yet if we have a story on how to match a bounce with the original outgoing email.

Also, one important thing we need to change is the way receiving invites is handled. In order to model the sharee's side of the invitation process we should add a SharingInvitationResponse^? kind -- when an invite is received, an item of this kind will be created, and displayed to the sharee somehow (inbox?):

Kind SharingInvitationResponse^?

• sharer
• collection
• sharee
• state:
  • NeedsResponse^? (we recieved it but haven't put in a response; the initialValue)
  • ReadyToSend^? (we've put a value in the response field and it's ready to be sent to sharer)
  • Failed (failed to get past SMTP)
  • Bounced (successfully got past SMTP but bounced later on)
  • Acknowledged (response made it to sharer, they acknowledge the response)
• response:
  • None (initialValue)
  • Accepted
  • Rejected

So now we have a framework for tracking invites and responses. What does the user see? What "sharing state" is the collection in throughout this process?

I suggest that the user be aware of the separation: the collection is either published or it isn't. Separately, the fact that invites have gone out and the various states of those invites/responses should be reflected in the UI. Both of these operations are triggered by the single Notify button. The sharer should be able to add/remove sharees at any time and re-click Notify. If a sharee already has accepted an invite, then that invite email won't show up in their inbox (our code will silently remove it).

-- MorgenSagen - 25 Oct 2004