Current Work Flow
ACT has been using an R script to create Access Requirement on a set of entities (data set). On some data set, there will be multiple Access Requirements: ACTAccessRequirement, and SelfSignAccessRequirement.
Dataset A has ACTAccessRequirement. User B wants to download dataset A, s/he needs to email the ACT to request access to data set A. Via emails, an ACT member would ask the user to complete some forms. The forms are different for each dataset. A form includes the information that Sage and data contributors requires. It is an agreement between Sage and data contributors, so it will not change after it's established for a data set. When there is updated on the data set, we have the data in a different project/ folder and have a new set of Access Requirements on that data.
...
Finally, all fields are required. The requestor will be shown an error if they try to submit the form without filling in every field.
Sample
email message to ACT after a user A requestor can save their form without submitting, in case they realize they need to gather other information or have their accessors become certified while they are filling out the form. To load the data they save, they will visit the dataset as they did to create the request, and click "Create Request"; the information they saved will automatically be loaded into the form upon opening.
Sample email message to ACT after a user requests access (with links to the page that has the table storing access requests - this link will have the Access Requirement and Access Request ID parameterized so that visiting the page will automatically filter the table to only show that request):
...
To view all requests made on the dataset, an ACT member can navigate to the page for managing the Access Requirement associated with that dataset and inspect the table of requests.
Features of the table view:
Users that have been certified and verified (?) or had their profile validated will have a symbol next to their synapse id (in this case a trophy, though will likely be a shield) as an indicator. Users who have previously been approved for access to the dataset will have a check mark next to their name.
The ACT member can query the table to only show requests that are awaiting approval, or only ones that were approved or rejected. The latter requests will have their approve/reject buttons disabled.
If the requestor updates their request, the fields they change will be highlighted for the ACT to more easily see. The version of the request will be incremented.
After a year, an access request will need to be renewed. An email will be sent out to the list of accessors one month before the expiration date.
<TODO: add sample email for one month before expiration>
If the request is not updated, then it will expire. The version in the table will be incremented, access for all accessors will be revoked, and the status will change to EXPIRED:
An email will be sent to the accessors (and ACT) notifying them of the revocation of their access.
<TODO: add sample email for revocation of access due to expiration>
After a year The ACT member viewing the table will be able to view all previous versions of the request by clicking the "View Versions" button. Doing so will open a dialog with the previous versions of a request:
After the set expiration length of time has passed, an access request will need to be renewed. An email will be sent out to the list of accessors one month before the expiration date.
...
<TODO: add sample email for revocation of access due to expiration>The ACT member can query the table to only show requests that are awaiting approval, or only ones that were approved or rejected. The latter requests will have their approve/reject buttons disabled.
Now the ACT member can view the user request and their submitted form before approving their request with the approval button. Approval may grant access to one user, or to many (ACT will decide based on request). Clicking approve will open a dialog with a summary for the ACT member to double-check before approving, including the ability to edit the email being sent out upon approval:
...
____________________________________________________________________________________________________________________________________
Hi:
The Synapse Access and Compliance Team has approved your application for use of the MayoGWAS data distributed through Synapse.
To use this data you must adhere to the Terms of Use as described in the MayoGWAS DUC: https://www.synapse.org/#!Synapse:syn2910256
The MayoGWAS data can be accessed through the following Synapse project:https://www.synapse.org/#!Synapse:syn3219045
Please note that the first time you download a datafile you will also be asked to agree to acknowledge the AMP-AD Partnership in publications derived from any of the AMP-AD data. This approval must be performed through the website.
For a review of the AMP-AD Data Terms of Use, please see here: https://www.synapse.org/#!Synapse:syn2580853/wiki/78604.
Please note, this email is sent from an unmonitored account. Send any questions to act@sagebase.org.
Sincerely,
The Synapse Access and Compliance Team
...
____________________________________________________________________________________________________________________________________
Hi:
The Synapse Access and Compliance Team has rejected your application for use of the MayoGWAS data distributed through Synapse, because you did not sign the DUC.
To submit another request, please visit the MayoGWAS dataset at: https://www.synapse.org/#!Synapse:syn2910256.
Please note, this email is sent from an unmonitored account. Send any questions to act@sagebase.org.
Sincerely,
The Synapse Access and Compliance Team
____________________________________________________________________________________________________________________________________
...