...
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
Will only discuss Web client workflow since we are deprecating scripts that are using these services.
- 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.
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.
...
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.