Add GitHub login and opt-out service

[softeng-701]

Currently, users can't login using their GitHub accounts. GitHub is the key resource and interaction point for this site and thus the site requires an interface for GitHub users.

Once logged in to QualOpt, GitHub users should be able to opt-in/out of studies and limit the number of invitations they receive from researchers. They should be able to restrict what kind of studies they would like to receive emails about by what the incentive is (the redesign in #5 will help quantify the incentives). This should then affect what searches they appear in when looking for participants.

Also, a permanent signature needs to be added to the bottom of every email from QualOpt which links back to the QualOpt opt-out service.

[lilcham]

I want to claim this one. Working in collaboration with Dylan Hall (Group 5 - Auka)

[lilcham]

Hi @softeng-701 and @kblincoe. After working on this issue and finally reaching a conclusion, I wanted to ask if I could bump the scope of this issue from a large to a very-large. The scope of this issue could be broken into two parts; adding the login functionality through Github and then creating an opt-in and opt-out service for the participants.

Github Login This was a relatively straight forward change. The frontend was changed to add a "login through Github button" and adding a bit of styling to the button. The backend changes involved setting up and adding the necessary Github OAuth keys, adding dependencies to the maven file and then incorporating the GithubFactory into the application to facilitate the login process.

Opt-in and Opt-out Service This is where the true depth of the issue was shown. When looking at the application, there was initially no way for a user to login as a participant; they could only login as a researcher or as an admin (through the pre-made admin account). This meant the notion of a "participant" only existed in the admin role (as they could create participants for testability). This introduced the first hurdle; the participant role.

Before creating the service, I had to introduce the notion of "logging in as a participant" into the application. This firstly brought about numerous conversations about the workflow of the application as it was pretty vague on how we would distinguish between logging in as a participant and logging in as a researcher. After discussing and coming to an agreement, the backend changes that were made included:

• Addition of the role: ROLE_PARTICIPANT
• Altering the REST application to add a query for getting participants by email so that when logging in, we could check if a participant with that email existed
• Altering the existing login flow to allow for distinguishing between logging in as a participant and then logging in as a researcher
• Assigning roles to different areas of the application to hide functionality to participants (e.g. they shouldn't see the studies tab or the participants tab)

After the inclusion of logging in as a participant, the item of interest was creating a view for the participants. A whole new view of the application had to be made for a user logged in as a participant. This view would include a tab for the participant settings (opt-in/opt-out and incentives) and then a list of all the studies that the participant had been opted into. For this, there was a major change to both the frontend and the backend.

For the participant settings tab, the changes that had to be made included:

• Creating the frontend for the form to fill out the settings (including the alerts and routing to allow the frontend to be connected to the rest of the application)
• Changing the participant data structure to include the new bits of information that would be stored with the participant (have they opted in to future studies or opted out, what incentive choice did they make etc.)
• Adding the necessary event handlers to be able to get the data from the form and then make a database call to update the required participant
• Changing the way the participants are listed in the main application (only list them as potential participants if they have opted-in when creating a new study)

For the list of studies tab, the changes that had to be made included:

• Creating the frontend to show all of the studies (this was a table, similar to the existing studies table)
• Adding the ability to query the database to eagerly fetch all of the studies pertaining to the one participant (this involved altering the database queries)
• Routing in the frontend to send a query and then list all of the studies pertaining to that one participant (using the database change above)
• Adding routing and roles to allow the participants to click the study and see the information about it without giving them the permissions to edit and delete the study
• Adding the routing for a popup which would come up if the participant wanted to opt-out of the desired study (to make sure they don't do it by accident)
• Adding a database query to allow for deletion of one relation in the many to many join table to emulate the opting out of a single study

All in all, I had to add a lot to the application and I had to change a lot of files. Because I had to know how the full application worked, there was a lot of pre-learning and discussions to help me get on the correct path. Because of the amount of changes that had to be made in conjunction with the amount of pre-learning and discussions, I think that this issue should be bumped to a very-large. More pictures and comments can be found on the pull request #113.

Cheers, Chamara Ratnayake (crat019)

[kblincoe]

OK