Description
I wanted to subscribe to the events when a user is put on hold and then put back into a meeting to see if i can customize my application behavior. I faced several issues and tried to find workaround but in the end the way the SDK is designed now make it impossible to react correctly on an event.
I won’t enter into the details, so long story short, if you want to apply a behavior on a specific user when he receive an event, and because the zoom web SDK broadcast a single event to all the meeting participants, you must apply some filtering based on the participant identity on the event handler to ensure the behavior is applied only to the related participant.
This means that you need consistent identity data between events, or you won’t be able to filter correctly. This is quite basic but i prefer to make sure that we are on same page before explaining the problems.
I found two problems:
- Identity data provided in event data handled by inMeetingServiceListener() is inconsistent between events.
- Data obtain by using getCurrentUser() is inconsistent over the “life cycle” of a user in a meeting.
1. Identity data on events
From the documentation, we can listen to 4 different events.
Let’s skip the event related to the connectivity for now and focus on the other ones, especially the two related to the putOnHold and putBack functionalities. When you look at the content of the data received:
- both have a userId (internal userId inside the meeting, set up by Zoom web SDK i guess and renewed every time a user leave & re-join that meeting)
- one have a userName (the user name visible on the UI), but the other do not have it.
The first issue here is that identify data across events should always be the same, for the reasons i mentioned earlier. So we can wonder which data is the identity data, the user id or the user name, or both ? I think (please correct me Zoom if this was not your intention) that the user id is supposed to be the identity data since the user name might not be unique (there is the possibility to rename yourself in a meeting for example, having two participant with same user name would then break identity of a user)
If the user id is not the identity data but the user name is, then please provide the user name on all events.
This first issue is not really much an issue if the userId is the identity data. But because of the following second issue, currently the userId cannot be the identity data and therefore i can state that in current version, there is NO identity data enabling us to identify an event as something related to a specific participant on our applications.
2. Inconsistencies of getCurrentUser during a meeting (putOnHold/putBack)
The second problem is that getCurrentUser() do not return the identity data for a participant that has been moved to the waiting room and then put back in the meeting.
Here are the data returned by getCurrentUser() after joining a meeting;
- In light green : the sequence of joining with SDK component initialization
- In blue : call & log of getCurrentUser()
- In green : the user data are there
Here are the data returned by getCurrentUser() after being put on the waiting room and then put back on the meeting:
- In light green : the sequence of reconnecting when being put back in the meeting
- In blue : call & log of getCurrentUser()
- In red : the user data are missing
As you can see, you cannot get the user information anymore after being moved back on the meeting due to the re connection system.
What the problem you may ask ? Well… if you pay attention, the userId generated by zoom after re-connecting is now different than the one you obtained the first time after joining the meeting. Therefore, the userId attached to this participant’s event after reconnecting to the meeting is a different one.
Because of that new id generation and the fact that we cannot get the user information anymore, it’s now impossible to say whether a received event is for that user or not. Event filtering is completely broken.
Note: You might have noticed that i refresh the user information every time i receive an event before processing it. This is because i could not obtain the user information data at the time i receive a meeting status change event with the value ‘connected’ (status ‘2’). I first though it was a meeting status event versus re-connection sequence issue, but the fact that the user information are not available at all event when receiving another event after being re-connected show that the problem is somewhere else.
Which version?
1.8.5
To Reproduce(If applicable)
Just test it
