Open Registry Disclosure Design

Owned by Omer Almatary
Last updated: Aug 04, 2011Version comment
4 min read

General Concepts

Disclosure settings help users and administrators control which OpenRegistry data elements should be displayed to the public and which should be hidden. The proposed implementation allows to set an "overall" disclosure flag which refers to a general policy, and also to hide or show individual fields, as long as the selected policy permits both states.

Based on many discussions by the Rutgers team, it was decided that it would make sense to store the flags that control access to fields that are part of OR domain model within OR. OR will provide service calls allowing to view and change such settings. The overall setting will also be stored in OR, however, the rules for reconciling it with individual settings, which are very organization-specific, can be implemented through an XML file. The proposed implementation contains a repository class for parsing the XML with JAXB and a sample XML implementation is included with unit test configuration. The settings for access to data that is not part of OR domain model (for example, in the case of Rutgers, academic data for students, such as program of study) should remain outside of OR.

Currently, access to the following elements is set individually:

  • Addresses (with three separate settings for street address, city/state/zip or region, campus building and room)
  • Email addresses
  • Phone numbers
  • URLs

The flags are keyed by affiliation, address type and, when applicable, phone type (land line, cell etc). For example, the same person may have the home address for the faculty role set to be private, but the office address for faculty role set to be public.

All changes to the Disclosure data will occur through service calls or by manipulating OR domain objects, never through direct DML. This will ensure the internal consistency of overall and individual settings, as well as consistency across multiple roles of the same individual.

Service Calls

The following new service calls will be implemented:

  • Get/Set overall disclosure setting for SOR person (accomplished by manipulating SorPerson domain object)
    • Include logic for calculating overall disclosure flag for Person based on SOR Person
    • Include logic for updating individual flags based on the overall setting - an XML-based service with organization-specific configuration files
  • Set individual disclosure settings for person, affiliation and address/phone/email type
    • The API has the format: DisclosureService.setXYZDisclosure(String identifierType, String identifierValue, String affiliation, Type addressType, boolean newValue), where XYZ is Address, Email, Phone or URL
    • Phone has additional parameter Type phoneType
    • Address disclosure update takes a map instead of a single boolean, because parts of address (street address, building/room, region) are controlled separately
  • Get individual disclosure settings for person, affiliation and address/phone/email type
    • The API has the format: DisclosureService.getXYZDisclosure(String identifierType, String identifierValue, String affiliation, Type addressType), where XYZ is Address, Email, Phone or URL
    • Phone has additional parameter Type phoneType
  • Get individual disclosure settings for person and affiliation, for all types
    • The API has the format: DisclosureService.getXYZDisclosure(String identifierType, String identifierValue, String affiliation), where XYZ is Address, Email, Phone or URL, returns a map of DisclosureSettingsForXYZ, keyed by type
    • In case of phone, a map of maps is returned, keyed first by address type, then by phone type

Data Model

Proposed data model - the main Disclosure table

create table prc_disclosure (
 id number(19,0) not null,
 disclosure_code varchar2(10 char),
 updated_date timestamp not null,
 within_grace_period number(1,0) not null,
 person_id number(19,0) not null,
 primary key (id),
 unique (person_id)
 );

Proposed data model - the main Disclosure table for SoRs

create table prs_disclosure (
 id number(19,0) not null,
 disclosure_code varchar2(10 char) not null,
 updated_date timestamp not null,
 within_grace_period number(1,0) not null,
 sor_person_id number(19,0) not null,
 primary key (id),
 unique (sor_person_id),
 unique (sor_person_id, disclosure_code)
 );

Proposed data model - the tables for field-level disclosure settings

create table prc_disclosure_address (
 id number(19,0) not null,
 bldg_room_date timestamp not null,
 bldg_room_ind number(1,0) not null,
 address_date timestamp not null,
 address_ind number(1,0) not null,
 city_region_date timestamp not null,
 city_region_ind number(1,0) not null,
 address_t number(19,0) not null,
 affiliation_t number(19,0) not null,
 disclosure_record_id number(19,0) not null,
 primary key (id),
 unique (address_t, affiliation_t, disclosure_record_id)
 );

create table prc_disclosure_email (
 id number(19,0) not null,
 public_date timestamp not null,
 public_ind number(1,0) not null,
 affiliation_t number(19,0) not null,
 disclosure_record_id number(19,0) not null,
 address_t number(19,0) not null,
 primary key (id),
 unique (address_t, affiliation_t, disclosure_record_id)
 );

create table prc_disclosure_phone (
 id number(19,0) not null,
 public_date timestamp not null,
 public_ind number(1,0) not null,
 address_t number(19,0) not null,
 affiliation_t number(19,0) not null,
 disclosure_record_id number(19,0) not null,
 phone_t number(19,0) not null,
 primary key (id),
 unique (address_t, phone_t, affiliation_t, disclosure_record_id)
 );

create table prc_disclosure_url (
 id number(19,0) not null,
 public_date timestamp not null,
 public_ind number(1,0) not null,
 affiliation_t number(19,0) not null,
 disclosure_record_id number(19,0) not null,
 address_t number(19,0) not null,
 primary key (id),
 unique (address_t, affiliation_t, disclosure_record_id)
 );

Discussion

  • It was suggested during the meeting on 06/16/2011 that the public indicator could be implemented using enumeration rather than a boolean type. This would allow the user to set preferences more flexibly, for instance, to show a certain field only to logged in users (an option available at SFU). It would still support the binary true/false model employed at Rutgers. Each organization should be able to define its own enumeration.