Displaying of bounced emails #36.

[will-molloy]

Solution to #36. This PR builds on #114 and contains the front-end changes. I used a new package (sweetalert), please run npm install and maybe npm install --save sweetalert.

Changes:

• Added alert system that indicates when email addresses have bounced. The alert works asynchronously; it comes up when the service processes the bounced mail so the user can be browsing another page and receive the alert. Hopefully this is helpful for #26. The alert contains a link to view the study.
• Changed study entity to include bounced mail and save bounced email addresses to database.
• Change study detail component to show bounced email addresses. This only shows when there are bounced email addresses. This only updates after sending an invitation.

Screenshot: Alert:

New study detail component field:

Test:

1. Login as admin (admin:admin).
2. Create some participants (some with invalid emails e.g. invalid123123123123123123@gmail.com). (invalid address will throw an exception; this is another issue.)
3. Create a study and add the participants.
4. Send the study.
5. Wait for it to be sent.
6. The alert should come up (whether you stayed viewing the study or went to another page).
7. Viewing the study should show the bounced participant email address field.
8. Editing out the bad participants and resending the invitation should remove the bounced participant email address field from the study view. (Make sure you include at least one good email address.)

Limitations:

• The initial spec of #36 said to display success or failure. I only indicate failure because I think having async alerts for all sent invitations would be annoying to the user; especially when #26 is implemented and the user is likely busy doing something else.
• I noticed Gmail sub delivery system is sometimes slow so not all bounced email is retrieved. This could be fixed by having a dedicated service continuously checking the inbox and using a listener. However, this rarely happens and I feel its too much effort for a medium issue.
• Currently the database is recording bounced mail in the Study entity. It probably should be in the participant entity as if a participants email bounced for once study it probably will for other studies. Could then have a permanent alert when viewing the participant saying their email is bad.

[will-molloy]

@Karim-C @AprajitGandhi test and review code thanks :)