allow simultaneous drawing on the whiteboard for non-moderators/all users / rework Moderation Role

[GoogleCodeExporter]

once the Issue 471 is solved we can start making the whiteboard available
for everybody.

You can think about different scenarios:

1.) We remove the Moderation role completely
2.) We make Moderation optional. Meaning that the Moderation Role can be
added in the Room configuration.
If there is a Moderation role, the Moderator decides who is allowed to draw
on the whiteboard besides him. 

In addition to Option 2 you can think about different scenarios for
Moderation also:
a.) Moderation changing is only possible if the Moderator accepts the
changing, not everybody.
b) Moderation can only be a user who has Moderation-Role in the
USER-SETTINGS! There are 3 roles in the current User-Administration:
User, Moderator, Administrator. We could use this User-Settings so that a
Userr who has Moderation Role in the User-Settings is automatically
Moderator. If two Users with Moderation Role enter a Room they can decide
by a simple PopUp who is now moderator. Who to deal with simple Users in
this scenario? Can they get Moderation Role?

I think the second option is necessary as in an E-Learning scenario it is
necessary to control the access to the whiteboard. And also in an
Audience/Event Modus with 100 Partizipants you need at leasst some control
of the Whiteboard.

Original issue reported on code.google.com by seba.wag...@gmail.com on 8 Jun 2008 at 2:13

[GoogleCodeExporter]

++ for my bad english but I type faster then thinking sometimes

Original comment by seba.wag...@gmail.com on 8 Jun 2008 at 4:36

[GoogleCodeExporter]

In my opionion is important that in Audience/event modus the moderator can
give/revoke the possibility to work on whiteboard to every user. 
the same for the audio.

Roberto

Original comment by err...@gmail.com on 8 Jun 2008 at 8:33

[GoogleCodeExporter]

Original comment by seba.wag...@gmail.com on 14 Jun 2008 at 9:52

• Changed title: allow simultaneous drawing on the whiteboard for non-moderators/all users / rework Moderation Role

[GoogleCodeExporter]

I think the moderator should be able to allow a non-moderator to do certain 
things,
such as draw on the whiteboard without giving them moderator status. That way, 
the
moderator remains the moderator, and is still in complete control of the room, 
and
can give or revoke certain rights.

In addition, I think only a user who has moderator rights in the user settings 
should
be able to moderate a room (as stated above). If there are multiple moderators 
under
different organizations in the same room, then the moderator whose organization
matches the organization the room belongs to should be the moderator.

Original comment by kristend...@gmail.com on 1 Jan 2009 at 5:41

[GoogleCodeExporter]

... I forgot to add that the moderator should also be able to give moderator 
status
to someone else... so they can either hand the moderation status to another 
person
completely... or simply give them a certain right, such as drawing on the 
whiteboard
or uploading files, then revoke that right once the person is finished.

Original comment by kristend...@gmail.com on 1 Jan 2009 at 5:45

[GoogleCodeExporter]

Fixed for Conference Rooms in r1863
=> the Moderator can grant access to whiteboard to anybody in the Conference
Room, for Event Rooms in will be a different behavior

Original comment by seba.wag...@gmail.com on 28 Jan 2009 at 5:48

• Changed state: Fixed

[GoogleCodeExporter]

Could you please explain why was it needed to add the following lines to the 
conferenceView in rev. 1863?

//reset the right to draw on WHiteboard as the RoomClient Object will be 
destroyed 
also
//on server-Side the canDraw status will be false again when you relogin the 
same 
room
        canvas.isAllowedToDraw = true;

Because they are entitled as a fix to this issue and I don't see any useful 
meaning 
for them...

Original comment by volkov.r...@gmail.com on 18 May 2009 at 11:04

[GoogleCodeExporter]

I think this is just a reset to default value. By default its true. I think I 
did
that because the first one is always the moderator. In other cases he will 
receive an
*ondrawAllowStatus* Event that will set this flag to the correct value when he 
enters
the Room.

Original comment by seba.wag...@gmail.com on 18 May 2009 at 11:31

[GoogleCodeExporter]

If by onDrawAllowStatus event you mean the so-called handler from 
participents.lzx, 
I've inserted the Debug.write there and noticed the handler is never called, be 
it 
moderator joining the conference room, or just a simple user. In addition, the 
issue 
724 is caused by the above code - because it makes any user that leaves the 
room 
being able to draw next time he joins the room. So, there is some malfunction 
there. 
Please take a look at the patch I've made on issue 724 and you might be able to 
offer 
some better solution, like making handler to work or something.

Original comment by volkov.r...@gmail.com on 18 May 2009 at 12:23

[GoogleCodeExporter]

no I mean the handler *ondrawAllowStatus* in mainMethods.lux Line 392 that gets
called from hibRtmpConnection.lzx Line 722 => case *updateDrawStatus*

Original comment by seba.wag...@gmail.com on 18 May 2009 at 12:35

[GoogleCodeExporter]

Unfortunately, I've placed my Debug.write there as well and this handler isn't 
called 
on user joining the conference room as well - it is called only when a 
moderator 
changes the draw allow status for a user. 

Original comment by volkov.r...@gmail.com on 18 May 2009 at 12:43

[GoogleCodeExporter]

*isn't called on user joining the conference room* => what kind of User? An 
initial
User (the one that is the initial Moderator) or whatever user (so somebody that
should have no drawing rights by default.

Back to the initial problem: the right is set to TRUE if the user leaves the 
tab. So
in general it has no influence on conference. It is set to true right before
logicalRoomLeave is called.

 It may only be problematic if you re-enter the Room. What effect do you expect when
you set this to false?

Original comment by seba.wag...@gmail.com on 18 May 2009 at 12:52

[GoogleCodeExporter]

In your comments to the code above you say "on server-Side the canDraw status 
will be 
false again when you relogin the same room" - and I assumed there is some 
drawAllowStatus change on user joining the room - because, when anyone leaves 
any 
room there is that ontabcontentleave event which makes canvas.isAllowedToDraw 
to be 
true, but there is nothing that changes this attribute back to false, which 
causes 
user to have drawing rights on joining back the room as described in issue 724. 
So I 
added Debug.writes to every possible piece of code changing the isAllowedToDraw 
attribute and none of them are called on user joining the room, be it an 
initial user 
or whatever user. So the above code gives drawing rights to any user that has 
left 
any room.

Original comment by volkov.r...@gmail.com on 18 May 2009 at 1:07

[GoogleCodeExporter]

yes but I don't think that this is the full story. You can read my comment also 
like
that: Pay attention, on server side there is an attribute called 
drawAllowStatus in
the RoomClient. Changing it here on the Client Side does not mean that it is 
true or
false on server side too.

I think we should look inside the mechanism that sets this value to true for the
initial moderator and send an event to all connected users in case its false or 
true.

Original comment by seba.wag...@gmail.com on 18 May 2009 at 1:40

[GoogleCodeExporter]

I am afraid, there is no mechanism that sets this value to true for the initial 
moderator at all. The case is, in newWhitePanel every instruments panel, be it 
drawpanel or whatever, has visible="${ ((canvas.ismoderator) ? true : 
((canvas.isAllowedToDraw) ? true : false )) }, and the first user that joins 
the room 
has canvas.ismoderator equal to true, so he sees the drawing panel even without 
having canvas.isAllowed to draw equal to true. Any other user has no 
canvas.ismoderator so he faces whatever isAllowedToDraw value he had before, be 
it 
false (by default) or true (after leaving a room and the code above)

Original comment by volkov.r...@gmail.com on 18 May 2009 at 1:55

[GoogleCodeExporter]

So lets add this mechanism and broadcast / update every new user's value.
The mechanism should take place in the RPC-Call *setRoomValues*

Original comment by seba.wag...@gmail.com on 18 May 2009 at 2:53

[GoogleCodeExporter]

This is exactly what I did in the patch for issue 724 - in the RPC call 
*setRoomValues*, more correct - in its getCurrentModerator.doCall() we set the 
canvas.isAllowedToDraw to returned value's canDraw value.

Original comment by volkov.r...@gmail.com on 19 May 2009 at 9:01

[GoogleCodeExporter]

I've made a patch that places the mechanism exactly to the setRoomValues RPC 
call, in 
case previous solution doesn't seem good to you, its again located in issue 724

Original comment by volkov.r...@gmail.com on 19 May 2009 at 10:59

[GoogleCodeExporter]

I am depressed for I do not know how to combine a whiteboard with skype

Original comment by uoc...@gmail.com on 14 Jul 2009 at 9:03

[GoogleCodeExporter]

Original comment by seba.wag...@gmail.com on 29 Aug 2011 at 8:02

• Added labels: Restrict-AddIssueComment-Commit