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. 

...

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 three listsa 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).

...

The submission will have the same three lists 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