[Design] Reconciling sharing privileges with the Edit / Update workflow

[Mimi Yin]

Jeremy's scenario brings up another wrinkle in the collaboration  
scenario. We would like to allow users to be able edit and any item  
that they receive explicitly via a capital-N notification.

For example: A shares a collection with B and grants B read-only  
priveleges. However, there is 1 item where A and B are collaborating  
heavily (e.g. Restaurant recommendations for SF). A stamps it as a  
communication and addresses it B and expects B to be able to edit the  
list, even though B only has read privileges on the collection the  
item lives in.

We need this to work in order to make the Stamping/Edit/Update  
workflows consistent across all scenarios. Otherwise, we will end up  
in the confusing situation where Chandler users who aren't sharing at  
all will have more flexibility wrt editing and updating items than  
Chandler users who are sharing (read-only).

Question: Is it possible to grant users edit privileges on items  
where they are specifically called out in the Addressing fields?

On Jul 11, 2006, at 1:30 PM, Jeremy Epstein wrote:

> you dont have to.  The permissions you assign have everything to do  
> with how you stamp events:
> "invitations" only allow "reply actions" for the invitees
> "meetings" may allow "accept" "reject" "tentative" and "schedule"
> if you are not on the list for an event you can only look at it.  
> Maybe not even that.
> etc...
> that and the rule "you can never touch someone else's event" unless  
> you are made an "owner" of the calendar.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060711/5e3cc44b/attachment.html