User

All available user properties, at least those seen in the New or Edit user dialog (Figure 264), are described as follows:

Name

Unique name of the user, as known to the station. Used in login credentials (along with Password), also appears in audits of changes made by the user (see About user audits).
Full Name

Full formal name of the user, or any descriptive name needed.
Enabled

Either true (default) or false. Determines if the user account is operational. If disabled (false), login attempts are blocked. By default, user guest is disabled (and for the best security, should remain so).
Expiration

Either “Never Expires” (default) or “Expires on <date>”. After the expiration date, login attempts are blocked.
Permissions

Either “Super User” (all permissions) or a specific permissions map (click “>>” control). Permissions are category-based. For an overview, see permissions and also About permission levels.
In general, it is strongly recommended to not assign super user rights. Instead, assign only those permissions to categories needed by a user. Note you can configure a “minimum set” of permissions in the station’s Default Prototype. These will serve as “starting point” set of permissions for any new user you add using the User Manager. For related details, see Default Prototype.
Network User

See the next section Network user related properties.
Prototype Name

See the next section Network user related properties.
Language

To specify a lexicon (typically two character language code, such as “fr” or “de”), as needed for language support or other customizing.
If customizing lexicons in an English language station, i.e. any U.S. application for example, enter the language code “en” to ensure the WbApplet (for a browser connected user) uses lexicons. Note you may wish to specify this in station’s Default Prototype, such that this is the default.
Password

Password entered by user in login credentials (along with user Name). Two entry fields are provided, both entries must match. Can be any combination of alphanumeric characters.
If the UserService is configured for strong passwords (property Require Strong Passwords), the password must be a minimum of 8 characters, using at least two of the three types of characters: either alpha (a—z, A—Z), numeric (0—9) or any other special character, such as “!”, “@”, “#”, “$”, or “%”. See Strong password notes.
Email

User’s email address. Informational, and also used in EmailService (and/or OnCallService) handling of incoming alarm acknowledgments via the “EmailAlarmAcknowledger” component, to verify the user. For related details, see About the Email Alarm Acknowledger.
Cell Phone Number

User’s cell phone number. Informational, and also used in SMS (Short Message Service) handling of incoming alarm acknowledgments via the “SmsAlarmAcknowledger” component, to verify the user. For related details, see About the Sms Alarm Acknowledger.
Facets

Includes two separate settings, as follows:
- Time Format
  
  How timestamps are formatted in property sheets, and so on. The default time format is sourced from Baja lexicon.
- Unit Conversion
  
  Selectable as either None (default), Metric, or English. Primarily affects value display of “out” slots on control points.
Nav File

To specify a Nav file that provides custom navigation for the user, defining locator bar content and home page. Click the folder control for a File Chooser dialog to navigate to the location of the station’s .nav files (by convention, a “Nav” folder under the station directory). For more details, see the NiagaraAX Graphics Guide section “About the Nav file”.
Default Web Profile

Includes two settings for station “auto logoff,” as follows:
- Auto Logoff Enabled
  
  Either true (default) or false. If true, a browser-connected user will be automatically disconnected from the station after the “auto logoff period” expires, providing that no user activity was detected during that time (changing views, expanding/contracting containers, and so on).
  
  If disabled (false), this browser-connected user is never automatically disconnected.
- Auto Logoff Period
  
  Any number of hours, minutes, seconds needed (default is 15 minutes). Specifies the time period used by the auto logoff routine (“inactive user time”), if auto logoff is enabled for the user.
In addition to the two properties above, other Default Web Profile properties specify the user’s expected method and level of HTTP browser access, by “Type”.
- Type
  
  Specifies the user’s expected type and level of HTTP browser access. For more details on profile types, see the NiagaraAX Graphics Guide section “About Web Profiles”.
  In AX-3.8, any station user connecting via a browser with an assigned Wb Web profile (Web Workbench) requires that browser client PC’s Java installation to have Java configured with “Unlimited Strength Policy Files”. For details refer to “Additional AX-3.8 client-side Java installation” in the NiagaraAX 2013 Security Updates document.
  
  A few of the available Web Profile types include the following:
  - Basic Hx Profile
    
    Lowest level and simplest browser requirements (browser with Java plug-in not required). Provides locator bar, ability to access properties and graphics (Px views).
  - Default Hx Profile
    
    Provides more navigation controls with simple browser requirements (browser with Java plug-in not required). Provides locator bar, access to property sheets and graphics (Px views), plus a view selector. Access to slot sheets is included, as well as PDF creation from property sheets or graphics.
  - Basic Wb Web Profile
    
    Requires the browser client to have the Java plug-in. Provides Workbench station access within a browser (Fox connection), but without top menu bar or ability for side bars. View access is limited to property sheets and Px views.
    
    Providing that Type is any of the Web Workbench (Wb Web) selections, three additional properties are available. These may be useful in the handling of the Web Workbench applet (WbApplet) in a browser’s Java plugin. These properties are listed below.
  - Default Wb Web Profile
    
    Requires the browser client to have the Java plug-in. Allows nearly full Workbench station access within a browser (Fox connection), including top menu bar and side bars (palettes and Nav tree). View access includes property sheets, wire sheets, category sheets, slot sheets, link sheets and Px views. Additional related properties are listed below.
  Prior to AX-3.7, if the same user needed to access the station differently, that is from a simple browser as well as from Workbench or a browser with Java plug-in support, it was recommended to use separate user accounts for that person, each with a different Web Profile. However, starting in AX-3.7 with mobile device support, this may be unnecessary. For related details see the “Mobile Web Profile” property of a User, in the list below.
- Providing that Type is any of the Web Workbench (Wb Web) selections, three additional properties are available. These may be useful in the handling of the Web Workbench applet (WbApplet) in a browser’s Java plugin. These properties include:
  - Applet Reload On Hyperlink
    
    Available only if Type is one of the Workbench (“Wb Web”) selections, where the default value is true. The WbApplet reloads on a hyperlink—meaning when you change the current Workbench view. If set to false, this results in less memory usage by a browser, because the WbApplet is not reloaded upon a hyperlink to a new Workbench view. Note the following additional hyperlink behaviors if this property is set to false:
    
    Just the current Workbench view changes.
    
    The browser URL remains the same, meaning it does not change.
    
    Refresh of the browser takes the user back to their original home page.
    
    The Back and Forward buttons in the browser no longer function (as the URL remains the same when hyperlinking to a new Workbench view).
    
    Changing Workbench views is much quicker!
    
    Tunneling is the exception where the WbApplet still reloads.
    
    To summarize, there are both positives and negatives regarding this option. To help with one of the less intuitive behaviors, another property (“Show Back and Forward Buttons”) can be set from defaults.
  - Workbench Theme
    
    (New starting in AX-3.7) Available only if Type is one of the Workbench (“Wb Web”) selections, where the default value is Lucid. Specifies the Workbench “theme” to use in WbApplet access in the browser. For related details, see About Workbench themes.
  - Show Back And Forward Buttons
    
    Available only if Type is one of the Workbench (“Wb Web”) selections, where the default value is false. If set to true, and the user Type is either “Basic Wb Web Profile” or “Default Wb Web Profile”, this shows some extra “browser like” Back and Forwards buttons.
    
    If “Applet Reload On Hyperlink” is true, the extra back and forward buttons call the browser’s back and forward commands. Note that these buttons are never disabled, as the browser’s history is unknown to the WbApplet.
    
    If “Applet Reload On Hyperlink” is false, the extra back and forward buttons call the Workbench history back and forward commands.
    
    As a consequence, this also fixes the kitPx backwards and forwards buttons so each works in a browser (following the above behavior).
    
    Note that for handheld Workbench profiles, the station designer needs to supply their own form of navigation, which could include the backwards and forwards buttons.
Mobile Web Profile

(AX-3.7 and later, and available only if the station’s host is licensed for the mobile feature):
Starting in AX-3.7, the station’s WebService has a “ClientEnvironments” container slot with a “Mobile Client Environment” child container with a few properties. This allows the station to automatically detect the “user agent” of an incoming client, and use the appropriate Web Profile for the user (“Default Web Profile” if Java-enabled device like a PC, or else “Mobile Web Profile” if a mobile device like a cell phone or tablet).
- Type
  
  Specifies the type and level of HTTP browser access to use for a detected mobile client. For more details on profile types, see the NiagaraAX Graphics Guide section “About Web Profiles”. Current choices include:
  - Default Hx Profile
    
    Default mobile profile based on Hx, which does not require the host to have the mobile module installed. Other Hx profiles are also available, and may be appropriate in certain cases for tablets or other touch-based applications.
  - Default Mobile Web Profile
    
    Mobile profile based on Bajascript, optimized for devices that do not support a Java plugin, but do support HTML5, CSS3, and JavaScript. Often, devices have small displays. When selecting this, the station should have Niagara Mobile Apps in its App container.
    For detailed information about properties below, refer to the NiagaraAX Mobile Guide section “Common Mobile interface controls and indicators”.
    
    Theme
    
    Specifies the “theme” to use when the user accesses the station using a mobile device (e.g. cell phone). Theme is always “mobile” with the following subtypes available:
    
    DefaultJQueryMobileTheme
    
    DefaultBlueMobileTheme
    
    LucidMobileTheme
    
    Show Header
    
    Default value is Show. If set to Hide the header area does not appear.
    
    Show Header Back Button
    
    Default value is Show. If set to Hide the Back button in the header does not appear.
    
    Show Select Views
    
    Default value is Show. If set to Hide selected views do not appear.
    
    Show Home
    
    Default value is Show. If set to Hide the Home button does not appear.

Network user related properties

Among User component properties are two that apply to the “network users” function.

Figure 294. User properties related to network user

These properties are unused for any users in a station with an LDAP user service (e.g. LdapV3UserService).

These properties are described as follows:

Network User

A boolean that specifies whether this user can be made available in other stations. When using the User Manager to add new users, this typically defaults to “false” (unless the “User Prototypes > Default Prototype” component has been edited from defaults, where it has been set to “true”. Leave or set to false whenever you wish this user to be local to this particular station only. For an overview of this feature, see Network users.
Prototype Name

Pick from a selection list showing available local User Prototypes. Blank or no selection is effectively the same as the frozen Default Prototype. Currently, this property setting matters only if the Network User property is “true”. See User Prototypes for related information.