Skip to end of banner
Go to start of banner

Separating Subjects from AccessRequirement

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Background

Current Object Models

AccessRequirement (interface)
Long id
String createdOn
String modifiedOn
String createdBy
String modifiedBy
String concreteType
String etag
List<RestrictableObjectDescriptor> subjectIds
Long versionNumber
ACCESS_TYPE accessType

Current APIs

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;

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.

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.

  • 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 & Update AccessRequirement APIs will only populate ACCESS_REQUIREMENT and ACCESS_REQUIREMENT_VERSION table. 
  • No labels