Background

Current Object Models

Current APIs

• POST /accessRequirement
• GET /accessRequirement/{requirementId}
• PUT /accessRequirement/{requirementId}
• POST /entity/{id}/lockAccessRequirement
• GET /entity/{id}/accessRequirement
• GET /team/{id}/accessRequirement

These services take and/or return an AccessRequirement object that contains a list of RestrictableObjectDescriptor.

Current Database

CREATE TABLE `ACCESS_REQUIREMENT` (
 `ID` bigint(20) NOT NULL,
 `ETAG` char(36) NOT NULL,
 `CURRENT_REV_NUM` bigint(20) DEFAULT '0',
 `CREATED_BY` bigint(20) NOT NULL,
 `CREATED_ON` bigint(20) NOT NULL,
 `ACCESS_TYPE` enum('DOWNLOAD','PARTICIPATE') NOT NULL,
 `CONCRETE_TYPE` varchar(100) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL,
 PRIMARY KEY (`ID`),
 KEY `ACCESS_REQUIREMENT_CREATED_BY_FK` (`CREATED_BY`),
 CONSTRAINT `ACCESS_REQUIREMENT_CREATED_BY_FK` FOREIGN KEY (`CREATED_BY`) REFERENCES `JDOUSERGROUP` (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `ACCESS_REQUIREMENT_REVISION` (
 `OWNER_ID` bigint(20) NOT NULL,
 `NUMBER` bigint(20) NOT NULL,
 `MODIFIED_BY` bigint(20) NOT NULL,
 `MODIFIED_ON` bigint(20) NOT NULL,
 `SERIALIZED_ENTITY` mediumblob,
 PRIMARY KEY (`OWNER_ID`,`NUMBER`),
 KEY `ACCESS_REQUIREMENT_REVISION_MODIFIED_BY_FK` (`MODIFIED_BY`),
 CONSTRAINT `ACCESS_REQUIREMENT_REVISION_MODIFIED_BY_FK` FOREIGN KEY (`MODIFIED_BY`) REFERENCES `JDOUSERGROUP` (`ID`),
 CONSTRAINT `ACCESS_REQUIREMENT_REVISION_OWNER_FK` FOREIGN KEY (`OWNER_ID`) REFERENCES `ACCESS_REQUIREMENT` (`ID`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `NODE_ACCESS_REQUIREMENT` (
 `SUBJECT_ID` bigint(20) NOT NULL,
 `SUBJECT_TYPE` enum('ENTITY','EVALUATION','TEAM') NOT NULL,
 `REQUIREMENT_ID` bigint(20) NOT NULL,
 PRIMARY KEY (`SUBJECT_ID`,`SUBJECT_TYPE`,`REQUIREMENT_ID`),
 KEY `SUBJECT_ACCESS_REQUIREMENT_REQUIREMENT_ID_FK` (`REQUIREMENT_ID`),
 CONSTRAINT `SUBJECT_ACCESS_REQUIREMENT_REQUIREMENT_ID_FK` FOREIGN KEY (`REQUIREMENT_ID`) REFERENCES `ACCESS_REQUIREMENT` (`ID`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Current Workflow

ACT member used to create AccessRequirements via a script. We are deprecating the script and encouraging users to use the web client implementation. 

Creating an AccessRequirement and applying it to an entity works as following:

1. An ACT member navigates to a subject A (entity or team) that they want to apply new AccessRequirement to.
2. S/he creates an AccessRequirement B for the subject, setting up the terms, and specifying all requirements.
3. Later new data C is added to Synapse.
4. 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.
5. S/he changes the existing AccessRequirement, extends it to also apply to C.

Problems

1. Currently, each AccessRequirement can be applied to multiple subjects. Every time a subject is added or removed from the AccessRequirement, the AccessRequirement is updated. 
2. 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.
3. 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.

Option 1 - Keep the workflow, separating updating AR and applying it to subjects.

• Add an API to change the relationship between an AccessRequirement and a list of RestrictableObjects. This action will trigger a change message for each subjects.
• Create will work the same.
• Update AccessRequirement APIs will only populate ACCESS_REQUIREMENT and ACCESS_REQUIREMENT_VERSION table. 
• This option will keep the list of RestrictableObjectDescriptor in AccessRequirement DTO.

Pros:

• Friendly to users since their workflow will stay the same.

Cons:

• 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 without specifying Subjects

• 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. 

Pros:

• The API make it clear that the association between a subject and an AccessRequirement doesn't change the AccessRequirement itself. 

Cons: 

• 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.

Update:

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.

Related JIRA tickets:

• PLFM-4476 - Getting issue details... STATUS
• PLFM-4512 - Getting issue details... STATUS