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.