Yup, that'd be neat. Then just add a little locked / unlocked padlock icon in the ui (like the osx settings panel), so users can see at a glance what elements of the document they can modify. That'd be quite easy to add.
I think the tricker side of things would be to make the server reject document modify events that don't comply to the lock settings of the document; and gracefully handle federated updated from clients that (for example) don't honor locking... ~ Doug. On Nov 28, 9:23 am, Tad Glines <[email protected]> wrote: > This is certainly doable. We could put a <locked></locked> element at > the beginning of the document to indicate that it's locked. Only the > document author would be allowed to insert or delete a locked element. And > if the element is present, only the document creator would be allowed to > modify the document. This wouldn't be that hard to implement. > > Instead of a locked element we could add an "owner" element at the > beginning, or maybe add "owner" and "locked" attributes to the contributor > element. > > -Tad > > > > > > > > On Sat, Nov 27, 2010 at 4:56 PM, dougx <[email protected]> wrote: > > Probably the single most requested feature from the people I work with > > was the ability for a user to lock a blip so no one else could edit it > > until they unlocked it (and, incidentally, that new blips were created > > in a locked state). > > > I know that breaks the whole collaborate wave thing a bit, but a lot > > of people I know were _really_ uncomfortable with having their > > messages edited by other people (it only takes one prankster. :P), and > > it made embedded waves a real mess. Having sections of a wave that > > were collaborative, and sections that weren't was something that > > people asked me about a lot. > > > I think it'd be relatively simple to modify the document model to > > support a locked field for blips; federating that might be difficult, > > but it'd work reasonably well for groups too. > > > I definitely think that locking at a blip level rather than a wavelet > > level is needed. > > > ~ > > Doug. > > > On Nov 27, 1:38 am, Tad Glines <[email protected]> wrote: > > > I'm working on adding group support to WiaB and also looking at the issue > > of > > > wavelet permissions. > > > > As a starting point I want to propose some group and wavelet roles and > > > solicit feedback. > > > > For groups the roles I'm proposing are: > > > > - Reader > > > - May read waves on which the group is a participant. > > > - Contributor > > > - Includes Reader capabilities > > > - May submit deltas to wavelets for which group is a participant. > > The > > > delta author must be the submitter. > > > - Manager > > > - Includes Contributor capabilities > > > - May add/remove members to/from the group and modify the role of > > > existing members, but only if: > > > - The member is self > > > - The member is NOT a manager > > > - The member is NOT an owner > > > - Owner > > > - Includes Manager capabilities > > > - May add/remove members to/from the group and modify the role of > > > existing members, but only if: > > > - The member is self > > > - The member is NOT an owner. > > > > For wavelets the roles I'm proposing are: > > > > - Reader > > > - May read wavelet content > > > - Contributor > > > - Includes Reader capabilities > > > - May add new wavelet content. In the context of a conversation > > > wavelet, this implies adding new blips. > > > - May edit own content. In the context of a conversation this > > implies > > > editing or deleting own blips. > > > - Editor > > > - Includes Contributor capabilities > > > - May add/edit/delete any content. > > > - Manager > > > - Includes Editor capabilities > > > - May add/remove participants and modify the roles of any exiting > > > participant if: > > > - Participant is self > > > - Participant is NOT a Manager > > > - Participant is NOT an Owner > > > - Owner > > > - Includes Manager capabilities > > > - May add/remove participants and modify the roles of any exiting > > > participant if: > > > - Participant is self > > > - Participant is NOT an Owner > > > > For both groups and wavelets the creator would be granted the owner role. > > > > -Tad > > > -- > > You received this message because you are subscribed to the Google Groups > > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/wave-protocol?hl=en. -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
