These components allow users and user groups to be managed through creating nodes. They are suitable for users that are private to an application (such as survey users), when user management should be delegated to application users, and when user management needs to be integrated into application functionality.
User
The User type is a simple wrapper for the underlying system user record, and does not of itself provide any processing support. It references the user using the System user node or User id field, the System user node taking precedence if both are set. From the user it sets both these fields and the name in a validation script, and also derives the name, User Logon Reference, System user node, Email Address, User enabled fields. This means that the fields are automatically populated, and the important fields (such as name and user id) are retained even when the underlying user is deleted.
A user node can be set up before the underlying user has been defined. In this case, the name, email and user enabled fields are used to define how the user should be set up.
The Status field describes the status of the user. If this is not set, it is derived as one of the following:
- Not set up – no User id has been set, or it has but does not exist.
- Enabled – user exists and is enabled.
- Disabled – user exists but is disabled.
- Error – an error, most likely that the owner of the user node can not read the details of the underlying user. The Error field will be set to describe the error.
A status of Deleted can also be set (but not derived).
The user statuses, and the user group statuses may have two tags set:
- Active – indicates the user or user group is active, i.e. it is not deleted or in error.
- Exists – indicates that the underlying user or group exists, which implies it is active.
These are added as tags to the user or user group.
Owning user group
The Owning User Group is a wrapper for an owning user group, acts as a package for user nodes, and provides support to manage the user group and the users within it. It references the user group using the User group reference field. The processes are invoked using the execute method with an action parameter, and is supported by a Process library bound to the dynamic reference owningUserGroupProcess. The Default Owning User Group Process provides the main actions that an owning user group requires, but solutions may vary or extend this as required.
Like a user node, an owning user group node can be set up prior to the creation of the underlying user group. The Status describes the status of the user group:
- Not set up – no User group reference has been set.
- OK – user group exists.
- Error – an error, most likely that the owner of the user group node can not read the details of the underlying user group.
- Deleted – the user group has been deleted.
The owning user group acts as a package for user nodes which represent the users in the user group. If the users are not yet set up, or the statuses have explicitly been set on the user node, the statuses are left to be derived by the user node. However, the owning user group may need to explicitly set Status and Error for the following conditions:
- If the user has been deleted, the status is set to Deleted. User deletion is permanent, but the user node is retained if deleting it would have any impacts, i.e. if any other nodes link to the user node.
- If the user is not in the owning user group, the status is set to Error and the error field describes the error.
- If the user can not be created, the status is set to Error and the error field describes the error.
The owning user group process supports the following actions as a minimum:
| Action | Description | Required permission |
|---|---|---|
| display |
Return a display for the owning user group. The default is to provide a list of users, but solutions may vary this to provide more extended management. The view to use is specified by the owningUserGroupView dynamic binding. The display action is run, rather than executed, and is passed the following parameters:
|
read |
| refresh | Refresh the owning user group node and the user nodes within it to reflect the underlying user group and user nodes. User nodes may be created, but will not be deleted. If there is a User id, but it is not part of the group, the refresh will attempt to set it as follows:
|
execute + update |
| update | Create or update the user group. | execute + update |
| updateUser | Create or update an individual user. | execute |
| updateAll | Update the user group and the users within it. | execute + update |
| clear | Remove status and error fields. | execute + update |
| clearUser | Remove status and error fields from a user. | execute |
| clearAll | Clear the user group and the users within it. | execute + update |
| deleteUser | Delete an individual user. | execute |
| deleteAll | Delete the user group and all the users within it. | admin |
| disableUser | Disable an individual user. Users can be disabled before they are created, in which case they will be created in a disabled state. | execute |
| disableAll | Disable all users. | execute |
| enableUser | Enable an individual user. | execute |
| enableAll | Enable all users. | execute |
| newUserDialog | Show a dialog to define a new user. This should create the user if the user group status is OK. | execute |
| editUserDialog | Show a dialog to update an existing user. This should update the user if the user group status is OK. | execute |
| deleteUserDialog | Show a dialog to delete a user. | execute |
| deleteAllDialog | Show a dialog to delete the user group and all users. | admin |
(Strikethrough = not yet implemented.)
The user-level actions are passed the user node in a "user" parameter. The "delegate" parameter is used to indicate when a owning user subgroup is being used (see below). These are available to the task scripts in attributes "userNode" and "delegateNode", respectively.
The user group process run under the authority of the owner of the user group node, i.e. only the user group node owner needs to have permissions on the user group, and the caller must have execute permission on the user group to run the processes. There are some exceptions to this:
- The display action is run directly from the user group type, passing it the user group in the "context" parameter, which is passed on to the task script in the "contextNode" attribute. Display callers therefore only need read access to the node and the user group type.
- The user must have execute authority on the user group and update authority on the name to perform actions that modify the user group: refresh, update, updateAll, clear, clearAll.
- The user must have admin authority on the user group to perform actions that delete the user group: deleteAll, deleteAllDialog.
Permission to grant to the user group is controlled by a [[typeUserGroupPermissionManifest]] node. This acts like a user list manifest, and grants "grant to" permissions on the user group, plus the required read and link permissions.
The processes can be extended or modified as necessary. For example:
- The update action can be modified to create a user home page.
- In a data gathering solution, users can be disabled when they have no tasks.
The User Group Script and User Script provide underlying functionality for many of these actions, and can be reused within the task scripts of extended processes.
The owning user group derives a User list which lists all the active users in the group, i.e. users which are not in error and which have not been deleted.
Creating new users
The owning user group will create new users as necessary. How the users are created is controlled by fields on the user node and on the owning user group node. The rules are:
- The User id on the user node is used, or, if it is not present, a new one will be created.
- The Password on the user node is used if present. If it is not present and if Generate password on the owning user group node is set, a password will be automatically generated. (If User id is not set on the user node, Password on the user node will be ignored.)
- If Enable user on the owning user group node is set, the user will be created in an enabled state.
- If Generate session token on the owning user group node is set, a session token will be generated for the new user and stored in the Session token field on the user node. The session token timeout period is controlled by the Session timeout period (hours) field on the owning user group node.
- If Force password change is set on the owning user group node, the user will be created such that they will be forced to change (or set) their password when they first sign on.
The fields on the owning user group set the policy for how users are created, and can be used to can control the level of security associated with the user creation.
User group
The User Group is a wrapper for a normal, non-owning user group. The users in the underlying user group are automatically set to reflect the users in the User list of the user group node. There is no concept of "refresh", i.e. this can not be used to list users within an existing user group. The processes for the user group are invoked using the execute method with an action parameter, and is supported by a Process library bound to the dynamic reference userGroupProcess, which defaults to Default User Group Process.
The normal user group supports a small set of actions, required only to manage the user group itself.
- display – return a display for the user group. The default is to provide a list of users, but solutions may vary this to provide more extended management. The view is specified by the userGroupView dynamic binding.
- update – create or update the user group.
- clear – remove status and error fields.
- delete – delete the user group
- deleteDialog – show a dialog to delete a user group.
Like owning user groups, display requires only read authority, but other actions require admin authority on the user group node.
There is no add user or remove user functionality - that is achieved by maintaining the user list.