Security > Users
  
Users
Each user of the system must be defined.
User names cannot include the following characters:
& (ampersand)
: (colon)
/ (forward slash)
+ (plus sign)
* 
User names can be email addresses.
For more information, see Naming Entities.
The default users are the following:
Administrator
The Administrator is a default user account that cannot be deleted. The administrator has create, read, update, and delete permissions for all entities and all runtime execution permissions.
SuperUser
If you are using the Extension SDK for extension development and you need to access a secured resource to which the user making the request may not have access, you can generate the Super User or System User contexts using the appropriate factory methods. You must ensure that the security context is only used to access the secured resources that are needed for proper functionality.
System User
A user can belong to any number of groups and can be assigned most combinations of rights and permissions. Unlike things, users do not have services, events, or subscriptions.
You can access properties for the current user (the user who is logged in) in the Mashup Builder on the User tab. They are also available in a mashup at run time. You can create and clone users at run time using the Resources service library.
Configuring Permissions for Non Administrator Users and Debugging Error Messages
Non administrator users do not have any permissions out of the box, which means they cannot view anything until explicitly permitted by an Administrator. Follow the tips below to configure new users and to debug error messages when certain actions are restricted:
In 8.4.0+, new users must be placed in the ComposerUser user group in ThingWorx. This will allow the user to log into Composer with run time service invoke permissions.
If there are other actions that a user should have but they appear to be restricted, an Administrator user can debug using the Application Log. Look for error level messages that indicate an entity may be missing or that some other function cannot be authorized. Example error messages are as follows:
Entity Not Found : [CurrentSessionInfo]] indicates that an Administrator must grant the non-admin user visibility permissions to see the CurrentSessionInfo resource.
Not authorized for ServiceInvoke on GetDaysRemainingInLicense in LicensingSubsystem] indicates that a run time service invoke permission for the GetDaysRemainingInLicense service on the Licensing Subsystem is missing for that non-admin user.
Any user entities that are migrated from a pre-existing version of ThingWorx (prior to 8.4.0) need to be manually added to the ComposerUsers user group. ThingWorx will not migrate imported user entities into the ComposerUsers user group automatically.
User Extensions
A user can have any number of properties, called User Extensions. To modify a User Extensions configuration, edit its Thing Shape under Modeling > Thing Shapes > User Extensions.
If you allow password reset for users, the following user extension properties are required:
firstName
lastName
emailAddress
User Permissions on Services
Services are explicitly designed to not require permissions for that user initiating the service. For example, users can change their own passwords. Attempting to prevent a user from using any service on their own account does not work.
Language Preference
In the Languages field, an administrator who knows the names of available languages can enter an ordered comma-separated list (for example, ca,es,hu,fr-CA) or select from a list of available languages. The first language listed is the preferred language for the user. If a user does not have language preferences set, the Default and System localization tables are used.
The displayed value (translation) of a localization token is determined by the user’s language preferences, the localization tables configured in the system, and the translation for the token existing in the specified localization tables.
For example, a user's language preference is fr,pt,ru,hi (French, Portuguese, Russian, Hindi). The system is configured with localization tables for es (Spanish), fr-CA (Canadian French), it (Italian),pt-BR (Brazilian Portuguese), ru (Russian), and the default (likely English). The system is searching for a value for a given token. The system first looks for a fr localization table, which exists. However, the token is not included in the fr localization table. Therefore, the system continues to the pt localization table. There is no pt localization table in the system. Therefore, it continues to ru. The system finds the ru localization table and the token. The token has a value, so that value is displayed on the UI.