Add ability to create multiple direct messages at different classification levels

[bbrockman]

Acceptance Criteria:

• User can have multiple direct messages with different classifications with someone else.
• Display under 'Direct Messages' needs to show label. Possibly partial label with full label visible over hover.

[douglasrapp]

Created branch feature/chat-locker-68

[douglasrapp]

This is turning into an interesting issue...

In order for this to work, the 'chatRoomItem' template needs to know the security banner text for a room (in order to display it in the left pane), and also the other member of the direct message (so it knows whether or not there are multiple direct messages with the same person).

Unfortunately, the template only has access to the ChatSubscription document, which only contains the room id, room type, and some timestamps. Further, since the client does not maintain Meteor subscriptions to all ChatRooms, this information cannot be easily looked up without jumping through some hoops.

1. One solution is to defer completely to the server and make async calls to Meteor methods. This should work fine, but could turn into a lot of calls, especially since obtaining security banner data would entail two chained calls - one to obtain the access permission ids for a room, and the other to call the 'getSecurityBanner' method. Further, I don't know how to make it reactive to label changes - what could trigger a new call to the server if nothing in the data context changes? And how would it know to start displaying the security info when a new message is created?
2. Another solution is to modify the ChatSubscription document that gets created when a direct message is created so that it already includes the banner text and the username of the other person. This makes it very fast/easy to get and use the needed information within the template, and also ensure reactivity. The downside here is that whenever a room is relabeled, we also need to make sure we update any associated subscriptions. Further, the structure of ChatSubscription documents would vary depending on what type of room they pertain to.

For now, I've (mostly) gotten it to work with the second option, but I don't know if that's the best way to go. I'll push my changes to the branch once I've ironed out a few kinks. In the meantime, any input would be appreciated.

[bbrockman]

Can we not just load all the users rooms and subscriptions at login and keep them reactive? That way we don't have to go back to server multiple times or duplicate object values like Reid mentions we have now.

[douglasrapp]

Yes we can. I had attempted to do just that when I was working on the search capability, but was unsuccessful. However, I just figured it out :)

[bbrockman]

Awesome!

[douglasrapp]

Merged branch feature/chat-locker-68