Initializing help system before first use

insightapi2~update_user

Purpose
The payload contains the updates to apply to the user. They are all optional. The first name, last name, email and status fields are optional. The status cannot be DELETED. The user id attribute is optional, but if it is supplied then it must match the id in the URL. The user's app membership will be updated to the supplied list of apps. Their membership is unchanged if this attribute is missing or null. If authority groups are supplied, they will replace the existing ones. The objectType is optional, but if it is supplied then it must be USER. All other attributes are ignored. When using SAML2 authentication, the first name, last name, email and status fields can only be edited in the Identity Provider - if specified here they will be ignored. Attempting to change the current user's status to a non ACTIVE status will result in a 422 error. Updating the current user's authority groups so that they no longer have the SYS_USER role will also result in a 422 error. Security: SYS_USER is required to edit a user.
Synopsis
function update_user(client:insightapi2~insightconfig, req:insightapi2~httprequest, resp:insightapi2~httpresponse):insightapi2~user
function update_user(client:insightapi2~insightconfig, id:text, body:insightapi2~user, resp:insightapi2~httpresponse):insightapi2~user
function update_user(client:insightapi2~insightconfig, id:text, body:insightapi2~user):insightapi2~user
Arguments
client 
An initialized insightapi2~insightconfig to call
req 
An initialized insightapi2~httprequest record. The body field may be populated with a value of type insightapi2~user. The params field may contain these indexes:
id 
The user ID
id 
The user ID
body 
The user with its updated fields
resp 
A insightapi2~httpresponse record into which will be written a description of the response
Return value
The response body of the request, if it was of type insightapi2~user
Further information
1. Use the status field of the resp record to distinguish between different status codes returned by the operation, or the success attribute to check for 2xx status codes. If the resp record is not passed to this function, the model will abort with a runtime error if the response's status code does not indicate success. The expected responses from this operation are:
HTTP Status Code Response body type Description
200 insightapi2~user The updated user
403 The current user was not authorized to update this user,or cannot deactivate themself, or cannot remove SYS_USER from themself
404 insightapi2~error_response The user did not exist or was unavailable to the current user
409 insightapi2~error_response The updated name was already in use
422 insightapi2~error_response Validation of the requested changes failed. e.g. the name was too long or an app or authority group did not exist.

2. If the response body could be read into a Mosel variable, it would be written to the body field of the resp record (and also returned from this function if it was a insightapi2~user), and the bodyfilename field of the resp record will be an empty string.
3. If the bodyfilename field of the resp record is set to a non-empty value on return, this will be a file containing the response body; the caller is responsible for deleting this file when it is no longer required.
Related topics

© 2001-2025 Fair Isaac Corporation. All rights reserved. This documentation is the property of Fair Isaac Corporation (“FICO”). Receipt or possession of this documentation does not convey rights to disclose, reproduce, make derivative works, use, or allow others to use it except solely for internal evaluation purposes to determine whether to purchase a license to the software described in this documentation, or as otherwise set forth in a written software license agreement between you and FICO (or a FICO affiliate). Use of this documentation and the software described in it must conform strictly to the foregoing permitted uses, and no other use is permitted.