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.
First address line.
Second address line.
The city the address is located in.
The country the address is located in.
The date the record was created.
The date the record was updated.
The postal/zip code for the address.
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
Electronic Mail address.
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.
A person's last name.
A telephone number.
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
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
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:
- These are the Initiatives that you’ll retrieve with the my-account endpoint.
- This join should already exist.
- You’ll be using the new Initiatives-to-Users join to connect the child Group to its Users.
- These are the Users assigned to the child Group.
- You’ll use the Initiatives-to-Users to connect directly to the original Initiatives table to connect it to the Users.
- This is the Users table as it connects to the join.