| Table of Contents | ||
|---|---|---|
|
...
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.
...
If there is no existing AccessRequirement associates with associated with the entity, an ACT member will be asked to create one.
...
If there is one or more AccessRequirements associate associated with the entity, an ACT member will see the following view:
...
An ACT member can also enter the Access Requirement Manager with a fix URL.
From there, an ACT member can Create a New Access Requirement, Search for one, and Manage access request.
An ACT member can search for Access Requirements that applies to an entity or a team:
An ACT member can see all ACT Access Requirements that have submissions that need to be reviewed:
When an ACT member choose to create a new Access Requirement, they will be asked to provide the necessary information:
...
For TermsOfUseAccessRequirement:
For ACTAcessRequirement:
After creating an AccessRequirement, an ACT member will be directed to a page to manage the created AccessRequirement:
For an ACTAccessRequirement, an ACT member will find the DataAccessSubmissions that need to be reviewed:
Requesting Access
From a controlled entity page, a user will see the "Show unmet conditions" button:
User B goes to any entity A with an AccessRequirement associated with it, and clicks Clicking on "show Show unmet conditions" to get to the data access request form (if one has been set up. If not, the process will be the same as it is currently for requesting access). If they are not logged in, then they will be met with this view:
Once they log in, then they will have the option to "Create Request":
Upon clicking Request Access, the user will be shown a form to fill out, and upon submitting the form, an email will be set to notify the ACT.
The person requesting access is automatically included in the list of accessors. They can remove themselves using the "x" next to their name.
The requestor can add multiple users for the access request by clicking "Add Accessor"
The requestor then will input the synapse id in order to add the user to the request.
Additionally, if there exists a restriction on what kind of users can be added (i.e. they must be certified users or have a validated profile), then an error will be shown if the requestor tries to add a user that does not meet the requirements, and the user will not be added to the list of accessors.
Finally, all fields are required. The requestor will be shown an error if they try to submit the form without filling in every field.
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.
User B can see the status of their request on the dataset.
Possible statuses for a request include: SUBMITTED, APPROVED, REJECTED, EXPIRED.
The user can cancel their request while it is awaiting approval from the ACT (status=SUBMITTED), but they may not update it.
takes user to a page that shows all AccessRequirements applied to the entity. For a TermsOfUse Access Requirement, user will be asked to sign:
For ACT Access Requirement, user will be asked to create a request:
If someone has submitted a request on the user behalf, they will see the status of the request:
If the user has submitted a request and awaiting for an ACT member to review, they can also cancel their submission.
After the submission is approved, a user will be able to update (add/remove user):
After a submission is rejected, a user will be asked to update information to complete the request:
Clicking on "Create Request," a dialog will ask the user to provide information about their project:
After entering the information about the research project and clicking "Next", user will be prompt to enter the list of accessors and upload required documents:
Once user provided all required information & document, they will be able to submit their request.
If a user choose to Cancel, we will ask if they want to save their changes:
Granting Access
After a user submits a request, an email will be sent to the ACT team:
...
An ACT member can click on the link provided in the email to go to the Access Requirement Manager page, or navigating to this page from other options described above. The link in the email take an ACT member directly to a location that manages submissions for a particular Access Requirement.
From here, an ACT member can use the provided tools to view the requirements:
After reviewing a submission, an ACT member would click "Approve" to approve the request. This action will create an AccessApproval for each accessors in the approved request.
...
The requestor can use the provided link to navigate to his/her request and start making changes.
After the request has been approved/rejected/expired, the requestor can opt to update their request:
The requestor will be able to edit all submitted fields:
On clicking Update, if anything is not filled in, the user will be shown an error message instructing them to fill in any fields they left blank.
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 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. 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 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>
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:
Sample email message to researcher after their request has been approved:
____________________________________________________________________________________________________________________________________
...
____________________________________________________________________________________________________________________________________
...
____________________________________________________________________________________________________________________________________
Exporting Information
The data contributor wants to know who has access to their data. Sage has been given report about approved requests including the following information: Principal Investigator, Institution, Date, and Intended Data Use Statement.
Brian has a script that update this wiki: https://www.synapse.org/#!Synapse:syn4993293/wiki/392026
For auditing purposes, ACT member could query requests (find requests that need to be processed, find requests that have been approved and see when they were approved, etc). ACT member could export set of files (associated with the dataset requests) For renewal request, user will be prompt to provide summary of use after they update the existing info:
Exporting Information
ACT member could export set of files associated with the requests as zip file, to be sent to data contributor.
...