Page Comparison

...

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 three lists:

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 three lists for both first time submission and renewals.