Update mentor, moderator and students views

[njsfield]

Changes

• After joining/creating a room, the Student, Mentor and Moderator are all served a single ‘main’ view (to fullfill the Single Page App requirement for this sprint).
• All users will have a cookie set, which includes the roomid, roomname, endpointsid, username, and permissions (the mentors cookie will also hold the roompin)
• When a users socket registers/disconnects, a message is sent back to all endpoints with the names, endpointids, and permissions of all users in the chatroom. This information is both saved in the client side comms module and used to update the DOM to display current users in the room.
• The browser views visible in each file are simple (dissimilar to Noga's designs), so that they simply represent the elements that would exist on the page without styling (just to demonstrate which elements are visible)
• For a single main view to work, all client side JavaScript modules should be given to Mentors, Moderators and Students.
• DOM manipulation would need to occur in order for an ‘ENTER PIN’ window to switch to a Video element.
• In the Moderator View, I’ve added notes at the end to resolve cases where clients disconnect.

[njsfield]

Can we actually store this many key value pairs inside a cookie 🤔? (Genuine question! I just don't know)

hapi cookie auth docs states an object can be set in the cookie (a session). Browsers can accept cookies with thousands of bytes worth of data, and a UTF-8 character takes between 1-4 bytes, so our cookie size will be fine.

the permissions will always include "av"...

Yes the permissions always includes av, but that's not the point here. The point is to demonstrate that the view file has 'if' logic to determine what it needs to inject into it (as this view will also get served to the student/moderator later). I've added a change to clarify that.

rather than globalMessage(msg), we would need something like globalMessage(app, from, method, params). params will just have been updated by chat.updateParams

This should clarify the server side signalling method here, the globalMessage(app, from, method, params) pattern is not needed because the server is sending along the packaged up message (JSON stringified), which the client receives and parses to see who it's from.

But in this journey, no one else will be in the room yet, as the mentor has only just created it. So we don't even need to call the getActiveUsers method.

getActiveUsers should be called every time a (global)CHATROOM JOIN message is received, so that a reply is sent from the server to the client (student/mentor/moderator) with names of everyone in the room, so the client can update their DOM with names of users. Yes, it seems a little cumbersome for this method to be called when the Mentor has just joined, but this message will be received by them every time a new user enters a room, so this method needs to be set up for them to ALWAYS be up to date with users in the room.

But the chat app does need to call some kind of method e.g. updateParams(endpointId, username, permissions)

See the moderator view, the comms module fires a message when the student submits the pin 'comms.send('APPLICATION', 'UPGRADEPERMISSIONS', 'SERVER', '1234')'

for each user, if the user has 'av' and 'chat' permissions This is not relevant if the mentor is the one sending the message at no. 13. In this journey, the mentor created the room, so how would there be no mentor? "if...there is no current 'Mentor' then add as mentor, else add as student"? (Until a mentor has created a room, the room doesn't exist.)

This is purely logic in the view file, which has no idea about the role of the Mentor (or how many people are in the room).

[jsms90]

@njsfield @esraajb A lesson for next time, not to use balsamiq I think :(

As beautiful as these look, and as much as I intensely appreciate all the time that went into these, it's much too difficult to alter these as we go. And especially in a project like this, where we are referring to this client/server model so frequently, it's really important that we can update these on the fly.

We need to update these! But keeping this un-merged isn't helpful