I think Pamela Fox mentioned at the summit talks that they were thinking about adding ability to lock any component in the wavelet, be it blip, form or gadget. Maybe some kind of "locked" annotation...
On Nov 28, 7:15 am, dougx <[email protected]> wrote: > 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.
