...
We want to provide a solution where a researcher can request a participant roster, which will kick off a worker process to gather all participants into a CSV, and email that CSV to researchers.
Minimum Viable ProductMilestone 1: We upload this email the CSV to an S3 pre-signed URL, then email this link to as an attachment to the researchers, similar to what the User Data Downloader currently does. This link will expire in 12 hours.
Stretch Goal: We attach the CSV to the email directly and send that email to researchers. For security, this zip file will be password protected by a password provided by Milestone 2: The CSV will be placed in a password-protected zip file before emailing it to the researcher.
Stretch Goal: By default, we will return all participant’s in the caller’s org. As a stretch goal, the participant can specify a study ID. We will need to verify this participant has access to this study ID, and then instead fetch all participants enrolled in this study.
...
| Code Block | ||
|---|---|---|
| ||
{
"service":"DownloadParticipantRosterWorker",
"body":{
"appId":"<app ID>",
"userId":"<caller's user ID>",
"password":"<password used to protect the zip file, see StretchMilestone Goal above>2>",
"studyId":"<optional study ID, see Stretch Goal above>"
}
} |
...
Once this CSV is complete, we’ll want to upload it to S3 as a pre-signed URL and email it to the caller’s email address (as provided by the previous Bridge call). See the following examples:
...
Note: You may need to create your own versions of these methods and/or refactor some of them to make them more general.TODO: Update the above with information about stretch goals.
Milestone 2
Instead of email the CSV, we put the CSV into a password-protected zip file and email that. Note that for UserDataDownload, we use Java’s built-in ZipOutputStream, which does not have password protection capability. Kelly to investigate Zip libraries that allow password protection.
Stretch Goal
TODO
Testing the Worker Changes
...
We will need to create an API in ParticipantsController, probably POST /v3/participants/emailroster. Initially, the POST body will be empty, but stretch goals will add a string password and an optional string studyId.
BridgeServer will then post a message to the worker SQS queue with the format above, passing in the caller’s app ID and user ID.
In Milestone 2, BridgeServer will generate a password to provide to the Worker and return the password to the caller for their reference. We will need to generate a password with minimum strength, such as 8 characters minimum, capital and lowercase letters, and numbers.
In Stretch Goal, the POST body will optionally include a studyId, which BridgeServer will then pass into the Worker request.
See for example UserDataDownloadController and UserDataDownloadService.