Sub tasks

[x] #293
[ ] Add new entities for Chat, Chat post
[ ] Implement chat component on Angular

This facilitates communication between parties involved in a job: source partner, destination partner and candidates

It replicates what we currently do in Slack with job related channels (eg #emp-au-iress), job/candidate related channels (eg #emp-au-iress-atheer), and job/candidate cohort channels (eg #emp-uk-mersey-cohort3). Slack channels are replaced with "chats" associated with the following:

Destination partner on admin portal

Source Partner chat - they will have a separate chat with each source partner who is proposing candidates to them. They will see these chats under a new Chat tab on each job. There will be a sub tab for each source partner. (This is like the Slack job related channel, but it allows the destination partner to have separate chats with each source partner).
All Source Partners chat - Chat with all source partners proposing candidates to them. This chat will appear on the each job's Chat tab - in a sub tab called "All Partners".
Candidates chat - as above , but in addition candidates from a certain opportunity stage can also post - in a sub tab called "Candidates"

Associated with each candidate case on the TC they see:

Recruiting Candidate chat - source partner, destination partner and the individual candidate can communicate (like Slack job/candidate channel) - CV Review or later

Source partner on admin portal

Associated with each job that they are working on they see on the TC:

Destination partner chat - The same as the "Source Partner chat" above
Candidates chat and All Source Partners chat - as above

Associated with each candidate case that they are working on they see on the TC:

Prospect Candidate chat - source partner, individual candidate - early relationship prior to CV Review stage
Recruiting Candidate chat - as above for destination partner

Candidate on candidate portal

Associated with each job that the candidate is going for (has gone for) they see on the TC:

Prospect chat - The same as the "Prospective Candidate chat" above
Recruiting chat - The same as the "Recruiting Candidate chat" above
Group chat - The same as the "Candidates chat" above

Another possible chat

One more chat - source/candidate unassociated with any job. Trigger for creation is when source does first post. Email sent to candidate.

Implementation

Note that there are:

two chats associated with each job opp.
one chat associated with each partner/job opp
two chats associated with each candidate opp.

In database terms:

two links in the Job entity: All partners chat, and candidates chat
one link in the PartnerJob entity: Source Partner chat (the source partner sees this renamed to "Destination parter chat" but it is the same chat)
two links to the candidate chats will be in the CandidateOpportunity entity: Candidate chat and Prospect chat

Websocket config

Endpoint /websocket (do we need to append it now?) Application destination prefix "/app" Destination prefix "/topic"

api/chat/ChatPublishAPI @MessageMapping("/chat/{chatId}") @SendTo("/topic/chat/{chatId}") public PublishedPost sendPost(Post post, @DestinationVariable chatId) { //PublishedPost has some extra stuff added to incoming post - eg date }

Chat implementation

app destination: We need every post to go to a Controller because that is where the post is persisted on the database.

JOIN/LEAVE: Some sample implementations which allow for users to identify and add themselves or remove themselves from a chat. We don't need this because we know the user posting from their logon.

MQ implementations: we don't need this because we are using our database to store chat posts. We just need the in memory.

Similar to ViewCandidateNote component

Need to add file upload capability - photos, docs - similar to what Slack can do. Docs either are associated with candidate or Job

On subscription, chat history retrieved from DB, then updates from messages.

API

ChatPublishAPI - WebSocket/STOMP controller handling incoming posts and multi casting out to subscribers
ChatAdminAPI - Normal RestController for creating, configuring, chats, handling uploads, post deletion etc

ChatService supports both the above

Angular

Two subscriptions for each chat associated with a user:

App globally subscribes to all updates to provide notifications of any posts
When a particular chat is on display, it adds a subscription to update the display while it is visible. Initially, historical chats are uploaded - then kept up to date based on subscription updates. Subscription closes when no longer displayed.

I believe that multiple subscriptions only need a single WebSocket connection.

DB

Job Chat - id (works as topic), definition includes type of chat, participants and associated job, case etc
Post - id (unique can be used to identify duplicates), timestamp (sort by timestamp), rich text, poster (user), job chat id

Access

TBB admins need special access - eg for training. Potential access on a job by job basis to other partners - eg IOM, UNHCR, Pathway Club

Doc

A "Job Chat" is a TC version of a Slack channel where participants in the channel can make posts and do uploads.

This facilitates communication between parties involved in a job: source partner, destination partner and candidates - plus other "fourth parties" such as TBB Global, UNHCR, IOM, Pathway Club etc

Job chats will replicate what we currently do in Slack with job related channels (eg #emp-au-iress), job/candidate related channels (eg #emp-au-iress-atheer), and job/candidate cohort channels (eg #emp-uk-mersey-cohort3). Slack channels are replaced with "job chats" associated with the appropriate job and candidate opportunities.

Why is it needed

There are partners without access to Slack. That is a challenge that we are already facing, with mixed success. This functionality is also essential for employer and recruiter direct access, which is currently under development. That is what has been the immediate driver for delivering this new functionality now.

Advantages:

auto creation of communication channels, standardized, on TC,
linked to opps,
automated posting for stage changes etc, standard way of distributing alerts to all parties,
multicast: something that Slack not have. Ability to send same message to multiple channels. Useful for communicating to, for example, lists of candidates - each on their own private channel

We won't be able to replicate everything people can do in Slack - and Slack will continue to be a useful tool for TBB and other partners who use it. However, we should be able to provide a pretty close match to Slack, with the advantage that it is built into the TC. Apart from meaning that all partners don't need to use Slack, having this basic functionality in the TC allows for increased automation and better standardisation and organisation. It is also valuable to have the chats tightly linked to the job and candidate opportunities they are associated with.

Chat definitions

The following sections describe for each of the 5 chats: chat name, participants, fourth party participants (in addition to normal 3 participants: candidate, source partner, destination partner), creation trigger and purpose.

Note that all chats receive automatic posts, as appropriate, by the TC for things like stage changes or updates to job details.

To clarify the main participants in each chat we will use the following abbreviations for the normal chat participants:

S - source partner
C - candidate
J - job creator (destination partner)

When more than one participant of a given type can be involved in a chat, we will add a plus (+). So, for example, 'S+ J' means more than one source partner and a job creator.

Source Partner Chat (S J)

Participants: job source and destination partner associated with prospects for the job in a particular source location 4th party participants: Trainer - eg TBB Global, local UNHCR Created: On job publication Purpose: Source specific communication related to the job Example: The destination partner may post questions relating to conditions in the particular source location.

All Source Partners Chat (S+ J)

Participants: All source partners, job destination partner Created: On job publication Purpose: All general partner communication related to the job. Example: The destination partner can make any post that they believe will be of general interest to source partners. Source partners can communicate with each other on this chat about the job, as well as with the destination partner - for example general questions to the destination partner about the job that could be of interest to everyone could be posted here.

Prospective Candidate Chat (S C)

Participants: Source partner and candidate in source location who is a prospect for the job, but who has not yet reached the stage (after CV Review) where they will be communicating directly with the destination partner. 4th party participants: Trainer - eg TBB Global, local UNHCR Created: When candidate opportunity is created Purpose: Private communication between source partner and each prospective candidate. Example: Early communication between source partner and a potential candidate. This can also be used in later stages for more private communication between the candidate and the source partner - not involving the destination partner.

Recruiting Candidate Chat (S J C)

Participants: Source partner, destination partner and candidate in source location whom the employer has expressed interest in (ie post CV Review) 4th party participants: Trainer - eg TBB Global, Pathway Club, IOM, local UNHCR Created: When a candidate's opportunity stage passes the CV Review stage Purpose: This brings the destination partner into direct communication with the prospective candidate for the first time. Example: Now that the employer has expressed interest in the candidate, the employer's recruiting process begins - arranging interviews, testing etc. The destination partner can use this chat to communicate directly with the candidate, and source partner, to arrange interview times etc. Later on the candidate can post questions about the job, destination country, etc directly to the destination partner. This chat can also be used by the candidate to upload required documents as requested by the destination partner.

All Candidates Chat (S+ J C+)

Participants: All source partners, job destination partner, all candidates who have passed a certain stage (eg job offer) Created: When first candidate passes the job offer stage Purpose: Communication with successful candidates, and all partners who have worked on the job. Example: Candidates can help each other through the process of getting ready to relocate. Partners are also there to help. The key partners will be in the candidates' locations, and the destination partner of course. But other source partners may also have useful advice and experience to share.

User perspectives

Although the different kinds of chats might seem complicated if you try to imagine their use for all different types of user, it will hopefully seem intuitive and natural in the way it is exposed to each individual type of user. They will see the chats associated with jobs and candidate cases in a natural and easily accessible way which assists their normal daily work.

Source partners see all 5 chats.
Destination partners see 4 types of chat (all except the early "Prospective candidate" chat between source partner and candidate).
Candidates see the 3 chats that specifically involve them (all except the chats just between partners: the "Source partner" and "All Source Partners' chats).

WebSockets and Stomp are the tech we need.

In the end, I created a Spring Server based on https://spring.io/guides/gs/messaging-stomp-websocket/ and an Angular client based on https://stomp-js.github.io/guide/rx-stomp/rx-stomp-with-angular.html

The main extra learnings to get it all going were in this post https://stackoverflow.com/questions/54578800/spring-boot-error-during-websocket-handshake

This works - on old versions of Spring as well.

However, extra complexity is added when Spring Security is added. Then additional complexity associated with Token authentication. Lastly, note that we calculate the token in a special login controller rather than in the filters.