Problems

1. The current design allows user to create a ResearchProject for an AccessRequirement. Using the created ResearchProject, a user can then create a DataAccessRequest. After filling in the information for a request, the user can submit the request. This action creates a DataAccessSubmission which will be reviewed by an ACT member. While ResearchProject and DataAccessRequest are mutable, a DataAccessSubmission captures a snapshot of the associated ResearchProject and DataAccessRequest. So that the ACT can review later what have been approved.
   To make it easy for the user to add a new accessor, we allow user to create a new submission based on an approved request, or more accurately, the current ResearchProject and DataAccessRequest. So in the case, after a submission is approved, the user came back to add a new accessor, s/he will start with all information that s/he filled in before. It's ambiguous if s/he should keep the accessors who has already been approved. These questions may come up: will removing the accessors who already have access revoke their access?
2. An AccessRequirement is highly mutable. An AccessApproval is a record of a single user meets an AccessRequirement. However, it doesn't contain information about which conditions or which terms the user has met. An ACT could create an AccessRequirement requires A, then approve a user under A. Then the ACT can changed the AccessRequirement to require B. Now looking at the AccessApproval for an approved user, there is no information about whether a user has met A or B.
3. The ACT wants to mark an AccessRequirement as requiring renewal because the data contributor wants user to come back and update us on how they have been using the data. With this use case, we only capture if an AccessRequirement requires renewal. If so, we ask the user for additional information (publication, ...) anytime they come back to add a new accessor. However, existing dataset which already established different expiration periods needs support on when a lab's approval is expired. 

Proposed Solution

1. We need to make it clear to the user that every submission is independent of the last while still allowing them to come back an continue their work. User needs to be able to see the accessors that have been in previous submission and still need to add them to the new request if they choose to do so. Also, user needs to be able to download the last DUC (with other accessors' signatures) and update it, then include the updated on in the new request. To discuss: should the DataAccessRequest be mutable after a submission is approved?
   Revoking accessor's access should be separately designed. 
2. AccessRequirement must be immutable and version-able. All current AccessRequirement will be version 0. Any changes to an AccessRequirement will increment the version and the new version will be stored. An AccessApproval must also store the version of the AccessRequirement the user has met. 
   This means a user can have multiple AccessApproval for a single AccessRequirement. Each approval is sufficient for the user to download the data the AccessRequirement protects.
3. To be able to support expiration with various periods, we need to keep track of the expiration period in the AccessRequirement. Once a user is approved, an AccessApproval must keep track of when it is expired. A user may have multiple AccessApproval for the same AccessRequirement (as mentioned above). When one expires, as long as the user still have at least one AccessApproval for a given AccessRequirement, they meet the conditions.
   We can also keep track of with which ResearchProject, an AccessApproval is created for a given user, AccessRequirement, and requirement version. This allows the ACT to easily remove a user from an approval for a ResearchProject without considering if the user has access to the data via a different ResearchProject. 

Changes to Request and Submission

In the original request, the user would provide a list of accessors, and a renewal would also provide a list of accessors.  Per our discussion with the team, renewals will now have a list of different changes to an accessor:

1. Accessors to Renew (users that had access before and should continue to have access).
2. Accessors to Add (new users that should be added and granted access for the first time).
3. Accessors to Revoke (accessors that used to have access but should no longer have access).

When a renewal is requested for and and a previous approved request exists, a renewal request will be created with all previous accessors added to the renew list. Upon approval of a renewal the following will occur:

1. For Accessors to Renew - The existing approval for each renewed accessor will have its modifiedOn, and modifiedBy fields updated, and if there is an expiration date, a new expiration date will be calculated (approval date + the requirement's expiration period).
2. For accessors to Add - A new approval will be added with the same expiration date as set for renewals (see: 1).
3. For accessors to Revoke - Change the state to of an approval to be REVOKED.

The SUBMISSION_ACCESSOR table will need to changed to only include accessors that are being renewed or added (users that are being revoked will be excluded).

The submission will have the same list for both first time submission and renewals.

Changes to existing API

• Only submitter can view submission status. Accessors who are not submitter will not be able to see status of submission they did not submit.
• AccessApproval will no longer be deleted. An ACT can revoke all AccessApprovals a user have for a given AccessRequirement. This API is also deprecated and will be removed.

New APIs