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.

Proposed Solution

This section is open for discussion.

...

It is not clear that the association between a subject and an AccessRequirement is not a part of the AccessRequirement.

Option 2 - Allow AccessRequirement to be created

...

Remove the list of RestrictableObjectDescriptor from AccessRequirement DTO.
Create & Update AccessRequirement will not associate the AccessRequirement to any subjects.
Add new set of APIs to associate a subject to an AccessRequirement and to remove the association.
Add new APIs to list AccessRequirement one creates and have access to.

...

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.
ACT members have to adapt to a new way to use AccessRequirement.

...

These are new APIs for option 2.

	Action	Intended Users	Method	URI	Request Params	RequestBody	ResponseBody
1	Apply an AccessRequirement to a subject	ACT	PUT	/accessRequirement/{id}/subject	subjectId, subjectType
2	Remove an AccessRequirement from a subject	ACT	DELETE	/accessRequirement/{id}/subject	subjectId, subjectType
3	Listing a page of subjects that an AccessRequirement directly applies to	All users	GET	/accessRequirement/{id}/subjects	nextPageToken		RestrictableObjectDescriptorResponse
4	Listing a page of AccessRequirements that applies to a subject	All users	POST	/accessRequirement/batch		BatchAccessRequirementRequest	BatchAccessRequirementResponse

RestrictableObjectDescriptorResponse
List<RestrictableObjectDescriptor> subjects
String nextPageToken

BatchAccessRequirementRequest
RestrictableObjectDescriptor subject
String nextPageToken

BatchAccessRequirementResponse
List<AccessRequirement> results
String nextPageToken

Related JIRA tickets:

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