shettima / bigbluebutton

Automatically exported from code.google.com/p/bigbluebutton
0 stars 0 forks source link

DynamicInfoModule no longer sends meetingID to infoURL #1009

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
In 0.8 release, if the infoURL configured to something like 
"meeting-info?userID={userID}&role={role}&meetingID={meetingID}", the meetingID 
will not be sent to the infoURL. 
Looking in firebug, the url that the DynamicInfoModule creates has the right 
userID and role, but has 'undefined' for the meetingID parameter. 
meeting-info?userID=299&role=MODERATOR&meetingID=undefined

Original issue reported on code.google.com by cba...@gmail.com on 19 Sep 2011 at 1:48

GoogleCodeExporter commented 9 years ago
Actually, there's seems to be more broken than I thought.

I adjusted my code to return valid xml without the meetingID. However, now I 
see the valid xml being returned in firebug, but the flash client is not 
creating the gui elements.

Loading the flash debugger, it seems that globalDispatcher is null at line 145 
here:
https://github.com/bigbluebutton/bigbluebutton/blob/293ba451e65bd563298d090846e8
cfbee5298781/bigbluebutton-client/src/DynamicInfoModule.mxml#L145

Original comment by cba...@gmail.com on 21 Sep 2011 at 3:21

GoogleCodeExporter commented 9 years ago
The attached patch is a quick hack to fix the problem with the dynamic info not 
showing up at all. (I probably should have created a separate issue for this.)

However it does not fix the issue where the meetingID is undefined.

Original comment by cba...@gmail.com on 21 Sep 2011 at 3:38

Attachments:

GoogleCodeExporter commented 9 years ago
Fixed it here
https://github.com/bigbluebutton/bigbluebutton/commit/a30f100ec8b04640583e9f5abd
6b8d342ad341da

Can you please try and confirm it works?

Original comment by ritza...@gmail.com on 21 Sep 2011 at 4:17

GoogleCodeExporter commented 9 years ago
I tested it. The dynamic info module works now good now - it shows all my 
labels and comboboxes. 

I found a work around and no longer require the meetingID - so I'm happy with 
this fix. However, I just want to mention that the meetingID is now working, 
but it's a different meetingID. It used to be the same as the meetingID that 
was passed as a parameter to the join API. But now it is something that looks 
like this: 0cb90d9a7719830fbcec3e474b97aea4a619bd66-1316623652286

Thanks!

Original comment by cba...@gmail.com on 21 Sep 2011 at 11:02

GoogleCodeExporter commented 9 years ago
I see what you mean. That's the "internal" meeting id while what you pass is 
the "external" meeting id. We had to convert (by hashing) the external meeting 
id into an internal one to generate a unique meeting id for each session for 
recording. 

We may need to pass the external meeting id to the client to make it available.

Changing status back to Accepted from Fixed to track enhancement.

Original comment by ritza...@gmail.com on 22 Sep 2011 at 1:58

GoogleCodeExporter commented 9 years ago

Original comment by ffdixon@gmail.com on 24 Jun 2012 at 5:51

GoogleCodeExporter commented 9 years ago

Original comment by ffdixon@gmail.com on 11 Nov 2012 at 4:41