create
This call creates a user, which is equivalent to a user registering in your project. This call would apply to creating a parent or an individual; you would use create_child to create a child in a family system.
The arguments that would be included in the doc are described below:
Name | Type | Required | Description |
action | string | true | create |
clogin_id | integer | false | This is a central login ID that identifies a user within your organization. Organizations can have multiple projects that the same user can register in. If you know the clogin_id from a separate project, you can use it to connect the accounts. clogin_id should be false for a user who is being created for the first time within your organization. |
group_id | integer | true | This designates which project the action should be applied towards. |
doc | array | false | See doc parameters below. |
submit_forms | boolean | false | This prevents the user's forms from submitting. This is generally advised if you want to prevent the update from activating triggers that are set in your project. false will prevent the forms from submitting, but true is the default. |
disable_email_sending | logical | false | This specifically prevents any emails from automatically sending as a result of an API call. true will prevent the emails from sending, and false will allow emails to be sent. Although false is the default, it is generally advised that you set this to true if you're not sure which emails might trigger. |
Name | Type | Required | Description |
username | string | false | This is the user name that users will log in to the project with. The project will default to requiring an email format. If you would like to turn the email requirement off, you can do that by editing the login widget within your project. If left blank, the system will... 1) Confirm main_email isn't taken and use it. 2) Check for any existing email (and confirm this email has not already been taken) 3) If there is no email available, the system will generate a value of the form {uuid}{groupid}@regpacks.com. If desired, username can be something other than main_email. It is not recommended to deviate from an email as the username as a system-generated email will prevent users from receiving important communications such as forgot password. |
password | string | false | Passwords can be alphanumeric or special characters with a minimum length of 6. If not provided, the system will autogenerate a password that you can access by running a report in your project. |
first_name | string | false | This is an important field that is responsible for the presentation of the first name on the user management page. It is strongly advised to include this. |
last_name | string | false | This functions like first_name |
org_name | string | false | Similar to first_name but allows an organization name to display on the user management page. Note that in a family project, it is still advised to include first_name and last_name in addition to org_name. |
main_email | string | false | This is similar to first_name and often serves as username as well. Note that email addresses are both validated and checked against a DNS database, however the DNS check can be disabled in the Project Settings if desired. ***article on project settings |
_application_date | string | false | This will default to the creation date if not supplied. This is included in case you want to back-date an applicant's creation date. Should be formatted in MySQL date format ("YYYY-MM-DD" or "YYYY-MM-DD hh:mm:ss"). |
fields | string | false | These are the fields in your project, such as multiple choice fields, short answer fields, etc. See "Referencing fields in API calls" for more information on how to supply fields in the API. |
This is an example which would create a new user in your organization. The key things to note are that username, password, main_email, org_name, first_name, and last_name are all supplied while clogin_id is false. Altogether, this is the equivalent of an end user registering and answering the yes/no question.
This is an example of creating a user who exists in a previous project. Because clogin_id is present, the system will pull username, password, main_email, org_name, first_name, and last_name whether they are provided or not (if the fields exist). What this means is that any values you provide will overwrite the previous values. If clogin_id cannot be found within your organization, the system will create a new user and return a new clogin_id. The system will disregard username and password if clogin_id is provided and will not overwrite them with the values you provide in the doc. Note that in a family system, only an existing parent can be created, and all child users will be assigned a new clogin_id.
When you create a user, the "User Account Created" trigger will fire. This trigger is the essential mechanism that causes the user to have their forms added to their profile. That said, it is possible that other actions in the system are triggered, and these can potentially have unanticipated consequences. If you would like to limit these second-order effects, it is advised that you include the following parameters:
It is important to note that, if you are creating a user in a project that was copied from a previous project and that user is also both present and not archived in that previous project, then it will port over all of the user's data. Any fields you provide answers for in the docs will then overwrite that data.
As an example, if Roger registers in "Color-con V", picks "blue" as his favorite color, and then you create him in "Color-con VI" with {"favorite_color":"green"}, then it will overwrite his answer in the new "Color-con VI" project; otherwise, his favorite color will show as blue.
Data cannot be overwritten with empty strings, so the correct way to prevent data from porting would be to archive the user in the original project (from which the new project was copied). This will prevent any fields from porting over except for the special user fields (such as first_name, last_name, etc.).
