Working with User Context

Context identifies a person and indicates the type of person (such as a System Administrator), and optionally, provides security with a password.

Any user can set context, but restrictions apply based on the type of person and password. For example, only a System Administrator can perform System Administrator functions.

Setting the context of a user implies that you are the user. Once the context is set, any commands you enter are subject to the same policies that govern the defined person. This is useful when you need to perform a large number of actions for a defined user.

For example, assume you want to include a person's files in the database. When you include them, you want the person to maintain ownership. Also, you do not want to create objects the person cannot access or perform actions prohibited to the person. You need to act as the person when those files are processed. In other words, you want to identify yourself as the person in question so that the actions you take appear to have been done by the actual owner of the files.

Context is controlled with the Set Context command which identifies a user to by specifying the person name and vault:

set context [ITEM {ITEM}];

For more information, see Set Context.

When a person is added to the database, the Business Administrator can include a Password clause as part of the person's definition. This clause assigns a password to the person. Once assigned, the password is required to access this person's context (unless the password is removed).

The password should be kept secret from all unauthorized users. If the defined person never shares its password with any other user, the effect is the same as using the Disable Password clause in the person's definition. For more information, see Add Person Command Syntax. Use the following Set Context command if a person is defined as having a password:

set context person PERSON_NAME password VALUE [vault VAULT_NAME];

• PERSON_NAME is the name of a user defined in the database.
• VALUE is the password value assigned to the named person in the person definition that was created by the Business Administrator.
• VAULT_NAME is a valid vault defined in the database.

In this command, you must enter both a person name and the password associated with the person. If either value is incorrect, an error message is displayed. However, if you are the Business Administrator, you can bypass a defined password. If you are assigned a user type of Business Administrator, you can change your context to that of another person by entering the following command:

set context person PERSON_NAME [vault VAULT_NAME];

For example, assume a person is defined as follows:

add person mcgovern
     fullname "Jenna C. McGovern"
     password PostModern
     assign role Engineer
     assign group "Building Construction" 
     vault "High Rise Apartments";

If you are defined as a Full User and want to set your context to mcgovern, you would enter:

set context user mcgovern password PostModern;

If you are defined as a Business Administrator, you can set your context to mcgovern by entering:

set context person mcgovern;

For more information on the different user types, see Type Clause for the Add Person Command.

set context user mcgovern password Jurassic newpassword PostModern;

set context person PERSON_NAME [vault VAULT_NAME];

set context person macleod;

When a person is defined with a Disable Password Clause, the security for logging into the operating system is used as the security for setting context.

When a user whose password is disabled attempts to set context, the system compares the user name used to log into the operating system with the list of persons defined in the 3DEXPERIENCE platform. If there is a match, the user can set context without a password. (The context dialog puts the system user name in as default, so the user can just hit enter.) If they do not match, the system denies access.

When Disable Password is chosen for an existing person, the 3DEXPERIENCE platform modifies the password so that others cannot access the account. This means that the user with a disabled password can only log in from a machine where the O/S ID matches the 3DEXPERIENCE ID. This is similar to the way automatic SSO-based user creation is handled. To re-enable a password for such a person, create a new password for the person as you normally would.

The context settings that the user provides at login time define the types of accesses that user has.

Programs and triggers might be available to users who do not have appropriate access privileges to run them, so the context must be changed within the program and then changed back to the original user's context withe the program completes. For example, a trigger program might need to switch context to perform some action which is not allowed under the current user context. It must then return to the original context to prohibit invalid access or ownership for subsequent actions.