I think we can kill two birds with one stone here: blip level permissions and groups: Consider the following. To allow all participants of a wavelet access to another, simply add the wavelet as a participant: [domain]/[waveid]/[domain]/[waveletid]@group Which allows all participants of that wavelet access to the wavelet they are added to. They retain the intersection of their permissions on the addressed wavelet and the permissions given to the group.
--Nathanael Abbotts On 22 Apr 2011 14:01, "Paul Thomas" <dt01pqt...@yahoo.com> wrote: > I just thought of something. What if you could could be a participant once with > different options? So therefore if you create blip under "edit only" than blip > is only yours to edit. Then if you want to create blip that is open to > collaboration you use your incarnation with participant editing). There should > be a simple way of switching between incarnations. > > > There could be a edit only super where the default for participants is edit > only. Depending on other supers (public/private) you may or may not be able to > add yourself, or be invited under that guise. > > > I think though could be a decent way of dealing with the blip level issue. > > > > > ________________________________ > From: Paul Thomas <dt01pqt...@yahoo.com> > To: wave-dev@incubator.apache.org > Sent: Fri, 22 April, 2011 13:45:40 > Subject: Re: Access Control > > Yep that make sense. > > I was thinking "edit own only" after that. It would be nice to explicitly allow > editing of your content to others. However blips don't have participant level, > merely authors. "edit own only" has been asked for many a time. It is perhaps a > bit archaic/antisocial on it own but has it uses. With explicit control of > editing that would be really versatile addition. > > > Also probably should be discussion about how AC is actually implemented. We have > > super users like public and they could have options, also users can have > options, and the notion of who has to right to make changes to the AC, with the > complication of the originator not necessarily being a participant. > > > > > > > ________________________________ > From: Arlen Beiler <arlen...@gmail.com> > To: wave-dev@incubator.apache.org > Sent: Fri, 22 April, 2011 13:08:01 > Subject: Re: Access Control > > I agree. Read-only should definitely be the third. > > On Fri, Apr 22, 2011 at 5:43 AM, Thomas Wrobel <darkfl...@gmail.com> wrote: > >> Read only? Personally I'd love per-wavelet level settings for >> individual users but that might be quite complex for now. >> >> On 22 April 2011 10:47, Paul Thomas <dt01pqt...@yahoo.com> wrote: >> > Following Yuri's Poll I noticed that Access control wasn't listed other >> then >> > public waves. A while ago that issue was discussed. I'll admit I was >> probably >> > the first to caution. That is becuase I didn't want access control to >> become >> > inflexible by design, and I was theorising custom access control where in >> a >> > broader sense you are enabling interaction control. >> > >> > >> > However I think at a more basic level it would be nice to have some of >> the more >> > common broader use cases. After private, public the next most desirable >> access >> > control (not suggesting pubic or private are exclusive of these). If >> there are a >> > handful of common access control options, that are implemented in such a >> way >> > that won't limit flexibility in the future, I think that will serve to >> broaden >> > WAIB's appeal. >> > >> > >> > What would be the next desirable ACs? >> > >>
