Page Comparison

...

We have two tables, one for ACCESS_REQUIREMENT, with a foreign key to a node (object) and one for  ACCESS_APPROVAL, having foreign keys to ACCESS_REQUIREMENT and principal.  The first imposes a requirement for access to the node.  The second fulfills the requirement, for a given principal. ACCESS_REQUIREMENT has a 'REQUIREMENT_TYPE' field along with a variable 'REQUIREMENT_PARAMETERS' blob, allowing it to be used for Tier 2 or Tier 3 requirements.  (The 'parameters' field could be a Eula, a form to be filled out, or something else.)  The ACCESS_APPROVAL table has an APPROVAL_TYPE and an APPROVAL_PARAMETERS blob, allowing it to Both tables have an "ENTITY_TYPE" field (populated from an ENUM) and a "SERIALIZED_ENTITY" field, a BLOB, allowing them to have variable content, so they can be used for Tier 2 or Tier 3 approval.  (The 'parameters' field could be some form contents, user's IRB information, information from the ACT, or something else.)requirements.

Below we omit the primary key and foreign key constraints for simplicity.

CREATE TABLE `ACCESS_REQUIREMENT` (
  `ID` bigint(20) NOT NULL AUTO_INCREMENT,
  `ETAG` bigint(20) NOT NULL,
  `CREATED_BY` bigint(20) NOT NULL,
  `CREATED_ON` bigint(20) NOT NULL,
  `MODIFIED_BY` bigint(20) NOT NULL,
  `MODIFIED_ON` bigint(20) NOT NULL,
  `NODE_ID` bigint(20) NOT NULL,
  `ACCESS_TYPE` varchar(256) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
  `REQUIREMENT`ENTITY_TYPE` varchar(256) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
  `REQUIREMENT`SERIALIZED_PARAMETERS`ENTITY` mediumblob,
 )

CREATE TABLE `ACCESS_APPROVAL` (
  `ID` bigint(20) NOT NULL AUTO_INCREMENT,
  `ETAG` bigint(20) NOT NULL,
  `CREATED_BY` bigint(20) NOT NULL,
  `CREATED_ON` bigint(20) NOT NULL,
  `MODIFIED_BY` bigint(20) NOT NULL,
  `MODIFIED_ON` bigint(20) NOT NULL,
  `REQUIREMENT_ID` bigint(20) NOT NULL,
  `ACCESSOR_ID`  bigint(20) NOT NULL,
  `APPROVAL`ENTITY_TYPE` varchar(256) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
  `APPROVAL`SERIALIZED_PARAMETERS`ENTITY` mediumblob
)

Data Access Object (DAO)

...

• AccessRequirementDAO.getForNode(), which returns all the AccessRequirements associated with a Node/Entity
• AccessApprovalDAO.getForNode(), which returns all the AccessApprovals associatd with a Node/Entity.  This allows us to find all the users who have been given access to an entity via a single database query.
• AccessApprovalDAO.getForAccessRequirementsAndPrincipals() which returns the AccessApprovals for a given list of AccessRequirements and Principals.  This method allows us to look up the approval of all the access requirements for a given node (focussing on user of interest) with a single database query.

...

We introduce JSON schemas for the generic interfaces AccessApproval and AccessRequirement, mirroring the tables above, BUT omitting the variable fields.  This is because the json schema cannot know the a priori the schema of such variable fields, which are managed separately.  We intoduce ENUMs for AccessRequirementType and AccessApprovalType (e.g. ("TOU_Agreement", "ACT_Approval").We introduce TermsOfUseRequirementParameters to hold the Terms of Use document for an AccessRequirement whose type is TOU_Agreementand schemas for specific types, TermsOfUseAccessRequirement, TermsOfUseAccessApproval (for tier 2 data), ACTAccessRequirement, and ACTAccessApproval (for tier 3 data).

Services

AccessRequirement: Create, Read, Update, Delete

...