...
- An ACT member navigates to a subject A (entity or team) that they want to apply new AccessRequirement to.
- S/he creates an AccessRequirement B for the subject, setting up the terms, and specifying all requirements.
- Later new data C is added to Synapse.
- An ACT member determines that the new data should have the same AccessRequirement with A. S/he navigates to A and list A's AccessRequirement to find the one they are looking for.
- S/he changes the existing AccessRequirement, extends it to also apply to C.
For team, an ACT member can navigate to a Team page and create an AccessRequirement for that team.
Problems
- Currently, each AccessRequirement can be applied to multiple subjects. Every time a subject is added or removed from the AccessRequirement, the AccessRequirement is updated.
- Since applying an AccessRequirement to a subject is a relationship between AccessRequirement and subject, adding or removing subjects from AccessRequirement should only change the relationship between the subjects and the AccessRequirement, and do not update the AccessRequirement.
- Entity's creator needs to contact ACT to apply an existing AccessRequirement to their entity.
- Also, changing this relationship may make the subject more or less accessible to users. The change should trigger a change message on the subject itself so that we can correctly authorize users' actions on the subject.
...
- AccessRequirement itself can have similar terms. AccessRequirements do not have name. Without the context of which subject it applies too, it is hard for user to identify which AccessRequirement they wants.
...
After discussion on July 7th, 2017, we decided that the cons in option 2 can be addressed by the client presenting the same workflow to users, and handle more API calls in the background. This made option 2 a better choice since it addresses both problem #1 and #2. It also allows us to address #3 later.
New Services
These are new APIs for option 2.
| Action | Intended Users | Method | URI | Request Params | RequestBody | ResponseBody | ||
|---|---|---|---|---|---|---|---|---|
| 1 | Apply an AccessRequirement to a list of subjectssubject | ACT | PUT | /accessRequirement/{id}/associationsubjectRestrictableObjectDescriptorList | subjectId, subjectType | |||
| 2 | Removing a list of subjects from Remove an AccessRequirement from a subject | ACT | DELETE | /accessRequirement/{id}/associationsubject | RestrictableObjectDescriptorListsubjectId, subjectType | |||
| 3 | Listing a page of subjects that an AccessRequirement directly applies to | Authenticated UsersAll users | GET | /accessRequirement/{id}/associationsubjects | nextPageToken | RestrictableObjectDescriptorResponse | ||
| 4 | Listing a page of AccessRequirements that applies to a subject | Authenticated UsersAll users | POST | /accessRequirement/batch | BatchAccessRequirementRequest | BatchAccessRequirementResponse | RestrictableObjectDescriptorList
| List<RestrictableObjectDescriptor> subjects |
| RestrictableObjectDescriptorResponse |
|---|
| List<RestrictableObjectDescriptor> subjects |
| String nextPageToken |
| BatchAccessRequirementRequest |
|---|
| RestrictableObjectDescriptor subject |
| String nextPageToken |
...
Jira Legacy server JIRA (sagebionetworks.jira.com) columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId ba6fb084-9827-3160-8067-8ac7470f78b2 key PLFM-4476 Jira Legacy server JIRA (sagebionetworks.jira.com) columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId ba6fb084-9827-3160-8067-8ac7470f78b2 key PLFM-4512 Jira Legacy server JIRA (sagebionetworks.jira.com) columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId ba6fb084-9827-3160-8067-8ac7470f78b2 key SWC-3709 Jira Legacy server JIRA (sagebionetworks.jira.com) columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId ba6fb084-9827-3160-8067-8ac7470f78b2 key PLFM-4518