search

hitrust / google-wave-resources

Automatically exported from code.google.com/p/google-wave-resources
1 stars 0 forks source link

Feature-Request: Groups and Access Levels #7

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Hey !
Yet another very nice project you are building there, looks promising.
One thing I have been missing while watching the keynote was some kind of
"group" implementation.
I've read something in the Wave Protocol about "groups" but there are not
defined in detail.
So I would like to see groups of participants/robots in wave that have
different access rights so I can limit read/write operations on certain
waves or wavelets.
Thanks in advance

Original issue reported on code.google.com by bergze...@gmail.com on 30 May 2009 at 4:20

GoogleCodeExporter commented 9 years ago 
I totally agree on this. We need a better authorization framework. In many 
cases you
will want people to edit everything but the first post (for example a 
CHANGELOG)

Original comment by jorge.vargas on 30 May 2009 at 9:49

GoogleCodeExporter commented 9 years ago 
I would like to chain approvals, with final authorizations and a lock, at least 
partial on some of the data once it is approved.  Ok I am not a wavo(logist) 
yet, but 
that is what I will build when I get the chance.

Original comment by bkrui...@gmail.com on 2 Jun 2009 at 4:03

GoogleCodeExporter commented 9 years ago 
I see group management being a critical feature for Wave to be adopted by 
businesses.
 If I have a project with 20 people, I do not want to add all 20 of them individually
to the Wave.  

More importantly, let's say 10 of them are contractors and I fire one of them.  
I do
not want to go through every Wave they were added to to remove them.  I will 
want to
remove them from the group and know they can no longer see any of the waves 
assigned
to the group.

Original comment by drewburl...@gmail.com on 3 Jun 2009 at 3:43

GoogleCodeExporter commented 9 years ago 
Yep we agree that Group feature is very important and it's something we intend 
to
provide.  Again, this is a developer preview release, it's still a little rough
around the edges :)

Thank you for the patience, we will update you guys on any latest development.

Original comment by austin.c...@gmail.com on 9 Jun 2009 at 12:45

GoogleCodeExporter commented 9 years ago 
Some thoughts on the implementation of the groups feature mentioned here

http://code.google.com/p/google-wave-resources/issues/detail?id=48

Original comment by james.mdb@gmail.com on 16 Jun 2009 at 9:23

GoogleCodeExporter commented 9 years ago 
http://code.google.com/p/google-wave-resources/issues/detail?id=48
should help

Original comment by jonah.be...@gmail.com on 29 Sep 2009 at 9:44

GoogleCodeExporter commented 9 years ago 
Issue 16 has been merged into this issue.

Original comment by pamela.fox on 5 Oct 2009 at 11:29

GoogleCodeExporter commented 9 years ago 
I would like to be able to group participants in different access permission 
levels. Maybe using something like CC, BCC would be nice:

Email -> Wave

??? -> Admin: The creator of the wave. An admin can invite other users to be 
participants or admins.

To -> Participants: Can change anything in the root wavelet and any wavelet 
they are participants on.

CC -> Observers: Can only add new blips but not edit the root wavelet.

BCC -> Hidden observers: Nobody but admins can see who is in this list.

Some other considerations:

1. In public waves users should be only able to join as observers (so they can 
post their own comments, etc)
2. When adding a comment or replying to a wave the user in fact converts to a 
participant of the new wavelet and all other users are observers of that 
wavelet.
3. Private replies convert the user as a participant (or maybe admin?) of that 
wavelet and the other user as a participant.

Original comment by cesar.iz...@gmail.com on 12 Oct 2009 at 6:23

GoogleCodeExporter commented 9 years ago 
4. If a "hidden observer" changes the wave it is converted to a normal 
"observer" before doing so.

Original comment by cesar.iz...@gmail.com on 12 Oct 2009 at 6:45

GoogleCodeExporter commented 9 years ago 
Rather than try & recycle the email "to, cc, bcc, etc..." I still think we 
should 
keep it simplistic.

i.e. a default "add contact" button... and perhaps a secondary "add as _____" 
option 
that gives a popup defining admin/participant/observer/hidden....

Whatever they're named... should be irrelevant... but rather add them to the 
wave 
just like a group... and define permissions to the group in the wave.

Of course... groups... is one thing highly dependent on how ACLs get 
implemented.  I 
can honestly say, however, that there should be some sort of 
end-user-intervention... 
when subscribing to a wave... or you may get "added" to a million viagra ads.  
Once 
the user is added to the wave... the OP/admin can move from group-to-group 
within 
that wave... 

at the end of the day... ACLs are going to be a nightmare to implement... and 
probably even more of a nightmare to manage.... but necessary so we don't end 
up with 
another insecure technology like SMTP.

Original comment by thecompwiz@gmail.com on 20 Nov 2009 at 3:00

GoogleCodeExporter commented 9 years ago 
I agree with http://code.google.com/u/jorge.vargas/ that an email parameter 
should be passed with only the ability to make replies and not edit the 
original wave post. Perfect for embedding into a blog/site.

Original comment by denver.p...@gmail.com on 9 Jun 2010 at 6:51