...

May Summary

By May 2017, we have completed #1-4, #7 & #8 under Solution sections. We have implemented all APIs listed under Services. The feature is under alpha in stack-180.

From user's feeback, we still need to provide the following:

1.  Need notifications - may only get 1-2 requests a week.
     Require broadcast messenger refactor (redesign)
2.  Revoking access - when user is removed in an updated request, revoke user access.  System should send a message to the people removed (Amy to help with messaging).
     Only remove - auto approve
     Remove & Add - ACT approve —> remove
     Require an accessor only be in one submission for a single access requirement
3.  Bundle submission together (like Brian suggested) to see latest + history.  May be able to work around if we have ability to sort by institution, and filter by Submitted By.
     Extend sort and filter
4.  RENEWAL SUPPORT.  ACT currently manually revokes user access.  We need to help support the existing process in the new system, or automate it.
To help support, they need ability to filter by the date granted access, and ability to get the list of emails.  Alternatively, system could automatically send out emails at specific reminder dates, and auto-revoke access after expiration.  
     Add worker to send message
     Add worker to revoke access 

As a path moving forward, we decided that when we bring the feature out of alpha, an ACT member can continue managing access outside of Synapse, or switch to use the new system. To be able to achieve this, SWC needs to know if an ACTAccessRequirement was configured to use Synapse to keep track of Submission. 

After a discussion, we conclude on:

• Making AccessRequirement version-able. 
• An access approval grants a user access to a specific access requirement version.
• On download, if a user have access approval for one version of the access requirement, the user meets the conditions specified by that access requirement.
• A new API need to be added to retrieve a version of an access requirement.
• Retrieving restriction information API needs to be generic (taking an ID and subject type instead of being specific for entity only)
• A submission points to a particular access requirement version. 
• Retrieving Access Requirement Status always include information about whether or not a user have met the conditions specified by the access requirement regardless of version.