Connecting Users to your Initiatives

Short Description: This will provide detailed information about which users are in which groups.

This endpoint must be run for each of the initiatives within the CCH account. One of two data sets will be returned. Either the JSON body will return a set of brackets "[]" showing that there are no parent-child relationships for that particular initiative, or at present the JSON body will return an array of initiatives.

NOTE: In the future we will have an endpoint that just holds the join table information. However, at this point in time everything about the nested User is returned and you'll have to create your own join table, only adding the information you need to create and maintain the table.

JSON Calls documentation:

This object is comprised of the following simple objects:

Name Object Category Object Type Nullable Description
_href JSON Reference string 0

The URL to request that document from the API.
id CCH Structure integer 0

ID of the record.
address1 Content string 1

First address line.
address2 Content string 1

Second address line.
city Content string 1

The city the address is located in.
country Content string 1

The country the address is located in.
date_created Content date 0

The date the record was created.
date_updated Content date 0

The date the record was updated.
postal_code Content string 1

The postal/zip code for the address.
state Content string

The state/province for the address.
status UCF Structure string

This field represents the status the document is in within the UCF’s document mapping process. The status fields are (in information flow order):

• Suggested meaning the document is at an early stage in the process. Much of the needed information is still missing but UCF staff are reviewing the document to decide if it should become “recommended” (see below).

• Recommended meaning the document has been recommended for inclusion in the UCF, but not yet verified.

• Queued meaning the document has been queued to be added to the UCF soon.

• In Research meaning the document is somewhere between being recommended and us figuring out what to do with it (or even find it in English).

• In Edit meaning the document is being worked on.

• Released meaning the document has been added to the UCF and should have an applicable release date.

• Not Applicable meaning the document has been verified to be a real authority document, however, the UCF mapping team have made the decision not to include the document in the UCF (for any number of reasons).

• On Hold Every so often we are sent an authority document for mapping that, during the mapping or research process, goes into change. Therefore, when that happens, we mark the authority document as being "On Hold" until we hear otherwise.

• Redacted means the record is no longer live. If the record belongs to an authority document (versus either a category record or originator record), then all the control citations within the UCF’s main tables will also be redacted.
time_created UCF Structure string

The date and time the record was created.
time_updated UCF Structure string

The date and time the record was last updated.
account.id CCH Structure integer

ID of the account record.
active_status CCH Structure string

The status of the list. 'A' = active. 'D' = deprecated.
check_digit CCH Structure integer 0

We humans have to use numbers. However, when entering numbers, we humans also have a tendency to screw up the entry or copying of those numbers. A Dutch mathematician named Jacobus Verhoeff conducted a study of 12,000 numerical errors J. Verhoeff, Error Detecting Decimal Codes, Mathematical Centre Tract 29, The Mathematical Centre, Amsterdam, 1969, cited in Wagner and Putter, "Error Detecting Decimal Digits", CACM, Vol 32, No. 1 (January 1989), pp. 106-110. and from that, proposed a check digit calculation scheme http://www.augustana.ab.ca/~mohrj/algorithms/checkdigit.html#verhoeff that catches all single errors as well as all adjacent transpositions and most other errors.

To ensure that the IDs assigned by the system have integrity during input as well as distribution while being transferred into various formats (such as Excel, Word, Text, XML), each ID will also have its own checksum value stored in a checksum field.

Currently, the methodology for creating and verifying the checksum follows the Verhoeff calculation format.

The CheckDigit is created along with the record's ID as a calculation by the UCF database system. As such, once assigned it should never change because the ID will never change. A sample calculation format is shown in the use case scenarios.
groups._href JSON Reference URL 0

URL to get the list's groups from.
initatives._href JSON Reference URL 0

URL to get the list's initiatives from.
account._href JSON Reference URL 0

URL to get the list's account information from.
ad_lists._href JSON Reference URL 0

URL to get the list's Authority Document information from.
ad_lists_created._href JSON Reference URL 0

URL to get the records' associated Authority Document Lists from.
agreement CCH Structure integer

if the user has read and accepted the agreement 0 = no 1 = yes
email Content string

Electronic Mail address.
first_name Content string

A person's first name.
groups_created._href JSON Reference URL 0

URL to retrieve the groups created by this record.
initiatives_created._href JSON Reference URL 0

URL to retrieve the initiatives created by this record.
invited_by._href JSON Reference URL 0

The URL to retrieve the person who invited this record to join the CCH.
invited_by.id CCH Structure integer

ID of the person who invited this record to join the CCH.
job_title CCH Structure string

A person's job title
last_login CCH Structure Datetime

The date and time of the last login for this record.
last_name Content string

A person's last name.
phone Content string

A telephone number.
profile_picture Content algorithm 1

A profile picture for the associated record stored in Base64 format.
reseller_access CCH Structure integer

Boolean Value where 0 = no access, and 1 = Reseller Access
type string

If this is describing users, then the type is either a = admin , u =regular user, i = invited user.

If this is describing Authority Documents, the choices of elements within UCF_AD_Type are listed in their legal hierarchical status, as defined within the UCF_AD_Type_Type, documented below.

• Bill or Act

• Regulation or Statute

• Contractual Obligation

• Self-Regulatory Body Requirement

• Audit Guideline

• Safe Harbor

• International or National Standard

• Best Practice Guideline

• Organizational Directive

• Vendor Documentation

• Not Set

Use Cases

What is an Initiative without Users? - a productive initiative (that’s a joke). Initiatives have to have users or they wouldn’t exist. And within the UCF, Initiatives can have groups. Which means that the subgroups within an initiative will have users as well. To see these initiative settings, click HERE and you’ll be taken to the appropriate part of the CCH.

The Initiative to User structure we create

Because of this nesting of groups within initiatives, the CCH creates an initiative structure that must utilize a parent-child join table to connect each initiatives with its various sub groups, and therefore, the Users belonging to those subgroups. In order to capture all of the Users, you’ll need to create a couple of join tables for your initiatives and the child groups Users belong to. A simple ERD for this structure looks like the one below:

  1. These are the Initiatives that you’ll retrieve with the my-account endpoint.
  2. This join should already exist.
  3. You’ll be using the new Initiatives-to-Users join to connect the child Group to its Users.
  4. These are the Users assigned to the child Group.
  5. You’ll use the Initiatives-to-Users to connect directly to the original Initiatives table to connect it to the Users.
  6. This is the Users table as it connects to the join.