Understanding the User View

The User view is the collection of attributes that contain information about an Waveset user, including:

• Attributes stored in the Waveset repository

• Attributes fetched from resource accounts

• Information derived from other sources such as resources, roles, and organizations

The user view is most often used with forms that are designed for the pages that create or edit users. These pages launch workflow processes that store a changed user view until it is necessary to push the updated view information back out to Waveset and associated resources. While the user view is stored in a workflow process, the workflow process can manipulate attribute values through workflow actions. Workflow can also expose attribute values for user input through manual actions and approval forms.

How the User View Is Integrated with Forms

The user view is often used in conjunction with a form. Forms contain rules that control how data is presented through HTML fields and is processed after the HTML page rendering the form is submitted. A system component called the form generator combines a form definition and a view to produce HTML that a browser then displays.

View attribute values are displayed by assigning them to an HTML component in the form. (See Chapter 7, HTML Display Components for more information on how view attributes can be displayed.)

Views are implemented as instances of the GenericObject class. This class provides a mechanism for the representation of name/value pairs and utilities for traversing complex hierarchies of objects through path expressions. A path expression is a string that is interpreted at runtime to traverse an object hierarchy and retrieve or assign the value of an attribute.

You must understand how to write path expressions to assign valid form field names. For more information on using path expressions, refer to the section titled Path Expressions.

How the User View Is Integrated with Workflow

Workflow processes that contain a user view typically store it in a workflow variable named user. You can reference a view in the workflow expressions by prefixing user to a user view path (for example, user.waveset.accountId). The string waveset identifies the attribute named accountId as belonging to another object named waveset, which itself belongs to the user view object.

Approval forms are written for a view known as the WorkItem view. The Work Item view by default contains all the workflow variables under an attribute named variables. If the approval form is written for a workflow that contains a user view, the prefix variables.user. is used to reference attributes in the user view (for example, variables.user.waveset.roles). See WorkItem View later in this chapter for more information.

Generic Object Class

At a high level, objects are simply named collections of attributes, which are name/value pairs. The value of an attribute can be an atomic value such as a string, a collection such as a list, or a reference to another object. You can represent almost any object abstractly with the Map, List, and String Java classes.

Within the Waveset system, the GenericObject class provides a simple memory model for the representation of arbitrary objects and collections. It includes features for easily navigating object hierarchies to access or modify attribute values.

The GenericObject class implements the java.util.Map interface and internally uses a java.util.HashMap to manage a collection of name/value pairs. The entries in this map are called attributes. The value of an attribute can be any Java object that is able to serialize itself as XML. The most common attribute values found in a GenericObject:

The following are instances of the following classes:

• String

• Integer

• Boolean

• EncryptedData

• List

• Date

• GenericObject

• X509cert

You can construct complex hierarchies of objects by assigning Lists or GenericObjects as attribute values. Once you have assigned attribute values, you traverse this hierarchy to access the values of an attribute.

Path Expressions

A path expression is a string that is interpreted at runtime by the GenericObject class to traverse an object hierarchy and retrieve or assign the value of an attribute. Waveset uses a system of dots and brackets to represent objects and attributes in the hierarchy.

You use path expressions as the value of the name attribute in form fields when customizing a form (for example, <Field name=’user.waveset.roles’/>).

Traversing Objects

The following simple example illustrates a GenericObject with two attributes:

• name (String)

• address (GenericObject) The address object, in turn, has an attribute named street, which is a string.

To create a path expression to the street attribute of the address object, use address.street.

Path expressions use the dot character (.) to indicate traversal from one object to another. This is similar to the way dot is used in Java or the ’->’ operator is used in C. Paths can be long, as illustrated by this example:

user.role.approver.department.name

Traversing Lists

You can also use path expressions to traverse values that are lists. Consider an object that has an attribute children whose value is a java.util.List. Each object in the list is itself a GenericObject with a name attribute and an age attribute. Write the path to the name of the first child as:

children[#0].name

Path expressions use square brackets to indicate the indexing of a list. The token between brackets is the index expression. In the simplest case, this is a positive integer that is used to index the list by element position.

Typically, the position of an object in a list is arbitrary. Index expressions can also specify simple search criteria to identify one object in the list. Objects in a list typically have a name attribute, which serves to uniquely identify this object among its peers. Path expressions support an implicit reference to an object’s name attribute within the index expression.

For example

children[hannah].age

The preceding path expression obtains the list of objects stored under the children attribute. This list is searched until an object with a name attribute equal to hannah is found. If a matching object is found, Waveset returns the value of the age attribute.

Example: Using the = Operator

<ref>accountInfo.accounts[type=vms].name</ref>

accountInfo.accounts[type=vms].name returns a list of names for VMS resources. It returns a list of only one element if only one exists.

Using the == Operator

children[hannah].age is equivalent to children[name==hannah].age. If you search using type=LDAP for example, you would get a list of names of LDAP resources. However, if you use the == operator, the result is a single object. For example, children[parent=hannah].occupation returns a list of occupations for all of hannah’s children, but children[parent==hannah].occupation returns a single occupation (not in a list) for whichever child was found first.

Example

<index i=’0’>
<   ref>accountInfo.accounts[type=vms].name</ref>
</index>

is equivalent to

<ref>accountInfo.accounts[type==vms].name</ref>

If more than one account with type vms exists, then either example will return the first account found with no particular guaranteed ordering.

Calculating Lists

You can also write path expressions that calculate List values that are not stored in the object. For example:

accounts[*].name

When an asterisk is found as an index expression, it implies an iteration over each element of the list. The result of the expression is a list that contains the results of applying the remaining path expression to each element of the list. In the previous example, the result would be a list of String objects. The strings would be taken from the name attribute of each object in the accounts list.

Path expressions with * (asterisk) are used with the FieldLoop construct in forms to replicate a collection of fields.

Account Types and User-Oriented Views

When you assign an account type to a user, Waveset makes available the account type as well as the accountId. When working with the user-oriented views, including the User, Enable, Disable, and Deprovision views, follow these addressing guidelines:

• Use a value of null to indicate an account of the default type. Reference an accounts of the default type by resource name for example, accounts[corp-ad]

• Use a type-qualified name instead of the resource name to reference an account of a specific type. The type-qualified resource name takes this form:

  <resource name>|<type of account>

  To reference the account data for the account of type Admin on the resource corp-ad, reference accounts[corp-ad|Admin].

User View Attributes

Whenever you create or modify a user account from a web browser, you are indirectly working with the user view. From the perspective of altering user account information, it is the most significant view in the Waveset system.

Workflow processes also interact with the user view. When a request is passed to a workflow process, the attributes are sent to the process as a view. When a manual process is requested during a workflow process, the attributes in the user view can be displayed and modified further.

Introduction

Like all views, the user view is implemented as a GenericObject that contains a set of attributes. The values of the attributes in the root object are themselves GenericObjects. Attributes can be nested.

The user view contains the attributes described in the following table, which are further defined in subsequent sections.

When you design a form, the field names are typically paths into the user view objects waveset. global, and account attributes (for example, global.firstname).

Selecting the Appropriate Variable Namespaces

The user view provides several namespaces for deriving account-related information. The following table summarizes these variable namespaces.

Referencing Attributes

Within a form, you can reference attributes in two ways:

• Use the name attribute of a Field element by adding the complete attribute pathname as follows:

  <Field name=’waveset.accountId’>

  For more information on setting the Field name element in a form field, see the chapter titled Waveset Forms.

• Reference an attribute from within another field:

  <Expansion> <concat> <ref>global.firstname</ref><s> </s> <ref>global.lastname</ref> </concat> </Expansion>

  Within workflow, you can reference Field attributes as process variables (that is, variables that are visible to the workflow engine) or in XPRESS statements for actions and transitions. When referencing these attributes in workflow, you must prefix the path with the name of the workflow variable where the view is stored (for example, user.waveset.accountId).

Attributes with Transient Values

You can define fields that store values at the top-level of the user view, but these values are transient. Although they exist throughout the life of the in-memory user view (typically the life of the process), the values of these fields are not stored in the Waveset repository or propagated to a resource account.

For example, a phone number value is the result of concatenating the values of three form fields. In the following example, p1 refers to the area code, p2 and p3 refer to the rest of the phone number. These are then combined by a field named global.workPhone. Because the combined phone number is the only value you want propagated to the resources, only that field is prepended with global.

In general, use the top-level field syntax if you are:

• not pushing a field value out to Waveset or any other resource

• the field is being used only in email notifications or for calculating other fields.

Any field that is to be passed to the next level must have one of the path prefixes defined in the preceding table, User View Attributes.

Field name=’p1’ required=’true’>
   <Display class=’Text’>
      <Property name=’title’ value=’Work Phone Number’/>
      <Property name=’size’ value=’3’/>
      <Property name=’maxLength’ value=’3’/>
   </Display>
</Field>
<Field name=’p2’ display=’true’ required=’true’>
   <Display class=’Text’>
      <Property name=’rowHold’ value=’true’/>
      <Property name=’noNewRow’ value=’true’/>
      <Property name=’size’ value=’3’/>
      <Property name=’maxLength’ value=’3’/>
   </Display>
</Field>
<Field name=’p3’ display=’true’ required=’true’>
   <Display class=’Text’>
      <Property name=’rowHold’ value=’true’/>
      <Property name=’noNewRow’ value=’true’/>
      <Property name=’size’ value=’4’/>
      <Property name=’maxLength’ value=’4’/>
   </Display>
</Field>
<Field name=’global.workPhone’ required=’true’ hidden=’true’>
   <Expansion>
      <concat>
         <ref>p1</ref>
         <s>-</s>
         <ref>p2</ref>
         <s>-</s>
         <ref>p3</ref>
      </concat>
   </Expansion>
</Field>

waveset Attribute

The waveset attribute set contains the information that is stored in a WSUser object in the Waveset repository. Some attributes nested within this attribute set are not intended for direct manipulation in the form but are provided so that Waveset can fully represent all information in the WSUser object in the view.

Most Used Attributes

Not all attributes are necessary when creating a new user. The following list contains the waveset attributes that are most often visible during creation or editing. Some attributes are read-only, but their values are used when calculating the values of other attributes. All waveset attributes are described in the sections that follow this table.

waveset.accountId

Specifies the visible name of the Waveset user object. It must be set during user creation. Once the user has been created, modifications to this attribute will trigger the renaming of the Waveset account.

For information on renaming a user, see Business Administrator's Guide.

waveset.applications

Contains a list of the names of each application (also called resource group in the Waveset User Interface) assigned directly to the user. This does not include applications that are assigned to a user through a role.

waveset.attributes

Collection of arbitrary attributes that is stored with the WSUser in the Waveset repository. The value of the waveset.attributes attribute is either null or another object. The names of the attributes in this object are defined by a system configuration object named Extended User Attributes. Common examples of extended attributes are firstname, lastname, and fullname. You can reference these attributes in the following ways:

waveset.attributes.fullname

or

accounts[Lighthouse].fullname

You typically do not modify the contents of the waveset.attributes attribute. Instead, modify the values of the accounts[Lighthouse] attributes. When the attribute is stored, values in accounts[Lighthouse] are copied into waveset.attributes before storage. waveset.attributes is used to record the original values of the attributes. The system compares the values here to the ones in accounts[Lighthouse] to generate an update summary report. See the section on the account[Lighthouse] attribute for an example of how to extend the extended user attributes.

waveset.correlationKey

Contains the correlation value used to identify a user during reconciliation and discovery of users. You can directly edit it, although it is generally not exposed.

waveset.creator

Contains the name of the administrator that created this user.

This attribute is read-only.

waveset.createDate

Contains the date on which this account was created. Dates are rendered in the following format: MM/dd/yy HH:mm:ss z

Example

05/21/02 14:34:30 CST

This attribute is set once only and is read-only.

waveset.disabled

Contains the disabled status of the Waveset user. It is set to a value that is logically true if the account is disabled. In the memory model, it is either a Boolean object or the string true or false. When accessed through forms, you can assume it is a string.

You can modify this attribute to enable or disable the Waveset user, although it is more common to use the global.disable. (Prepending global. to a variable name ensures that the system applies the value of that variable to all resources that recognize the variable, including Waveset.)

Once this value becomes true, the user cannot log in to the Waveset user interface.

waveset.email

Specifies the email address stored for a user in the Waveset repository. Typically, it is the same email address that is propagated to the resource accounts.

Modifications to this attribute apply to the Waveset repository only. If you want to synchronize email values across resources, you must use the global.email attribute.

You can modify this attribute.

waveset.exclusions

List the names of the resource that will be excluded from provisioning, even if the resource is assigned to the user through a role, resource group, or directly.

waveset.id

Identifies the repository ID of the Waveset user object. Once the user has been created in Waveset, this value is non-null. You can test this value to see if the user is being created or edited. This attribute is tested with logic in the form. You can use it to customize the displayed fields depending on whether a new user is being created (waveset.id is null) or an existing user account is being edited (waveset.id is non-null).

Example

The following example shows an XPRESS statement that tests to see if waveset.id is null:

<isnull><ref>waveset.id</ref></isnull>

waveset.lastModDate

Contains the date at which the last modification was made. It represents the date by the number of milliseconds since midnight, January 1970 GMT. This attribute is updated each time a user account is modified.

This attribute is read-only.

waveset.lastModifier

Contains the name of the administrator or user that last modified this user account.

This attribute is read-only.

waveset.locked

Indicates whether the user is locked. A value of true indicates that the user is locked.

waveset.lockExpiry

Specifies when the user lock expires if the user’s Lighthouse Account policy contains a non-zero value for the locked account expiry date. This attribute value is a human-readable date and time.

waveset.organization

Contains the name of the organization (or ObjectGroup) in which a user resides. An administrator can modify this attribute if he has sufficient privileges for the new organization.

Since changing an organization is a significant event, the original value of the organization is also stored in the waveset.original attribute, which can be used for later comparison.

waveset.original

Contains information about the original values of several important attributes in the waveset attribute. The system sets this value when the view is constructed and should never be modified. The system uses this information to construct summary reports and audit log records.

Not all of the original waveset attributes are saved here. The attributes currently defined for change tracking are:

• password

• role

• organization

To reference these attributes, prepend waveset.original. to the attribute name (for example, waveset.original.role).

password

Specifies the Waveset user password. When the view is first constructed, this attribute does not contain the decrypted user password. Instead, it contains a randomly generated string.

The password attribute set contains the attributes described in the following table.

waveset.passwordExpiry

Contains the date on which the Waveset password will expire. When the view is initially constructed, the memory representation will be a java.util.Date object. As the view is processed with the form, the value can either be a Date object or a String object that contains a text representation of the date in the format mm/dd/yy.

waveset.passwordExpiryWarning

Contains the date on which warning messages will start being displayed whenever the user logs into the Waveset User Interface. This is typically a date prior to the waveset.passwordExpiry date in the same format (mm/dd/yy).

waveset.questions

Contains information about the authentication questions and answers assigned to this user. The value of the attribute is a List whose elements are waveset.questions attributes.

The waveset.questions attribute set contains the attributes described in the following table.

The name attribute is not stored. The system generates the name by transforming the id. This is necessary because question IDs are typically numbers, and numbers that are used to index an array in a path expression are considered absolute indexes rather than object names.

For example, the path waveset.questions[#1].question addresses the second element of the questions list (list indexes start from zero). However, since there may be only one question on the list whose ID is the number 1, the ID is not necessarily suitable as a list index. To reliably address the elements of the list, the system manufactures a name for each question that consists of the letter Q followed by the ID (in this example, Q1). The path waveset.questions[Q1].question then always correctly addresses the question.

waveset.resources

Contains a list of the names of each resource that is assigned directly to the user. This list does not include resources that are assigned to a user through a role or through applications. You can add only unqualified resource names to this attribute. To find all resources that are assigned to a user, see the section on the accountInfo attribute.

waveset.resourceAssignments

Qualifies the assigned resource list. (This attribute parallels the existing attribute waveset.resources attribute.) All resources in this attribute appear as unqualified in waveset.resources. Even if a user is assigned only an account of non-default type, the resource will appear in waveset.resources.

You can add new assignments made to either waveset.resource or waveset.resourceAssignments, with the lists automatically resynchronizing when the view is refreshed. This adds an assignment for an account of default type. You can add both qualified and unqualified resource names to waveset.resourceAssignments. This adds an account of the specified type based on the qualifier.

waveset.roleInfos

Contains a list of objects that contain information about the roles assigned to this user.

waveset.roles

Contains the names of the roles assigned to this user. An administrator can modify this attribute if he has sufficient privileges for the new roles.

Since changing a role is a significant event, the original value of the role attribute is also stored in the original view, which can be used for later comparison.

waveset.serverId

Use to set unique server names when your deployment includes multiple Waveset instances that point to one repository on a single physical server. See Installation Guide for more information.

accounts Attribute

The accounts attribute contains a list of objects for each account linked to the Waveset user. Each account object contains the values of the account attributes retrieved from the resource.

The name of each account object is typically the name of the associated resource. If more than one account exists for a given resource, the object names take a suffix of the form |n where n is an integer. The first account on a resource has no suffix. The second account has the suffix |2. The third account on a resource has |3, etc.

For example, if you have a resource named Active Directory that defines an account attribute named Profile, the view path to this attribute would be:

accounts[Active Directory].Profile

If this view path were used in a form field, it would prevent the value of the global.Profile attribute from being propagated to the Active Directory account.

You may want to use account-specific attributes in forms rather than global attributes to prevent propagation of values to all resources

Overriding Resource Attributes

In addition to setting account attributes, you can also specify resource attribute overrides for each account. Resource attributes are attributes that are defined for the resource definition in Waveset, and consequently for the resource type. They are not attributes associated with an individual account. Examples of resource attributes include the host name of the server, or the base context in a directory.

You may want to create an account on a resource, but use a different value for one of the resource attributes. You could do this by duplicating the resource and changing the value, but excessive resource duplication can be confusing. Instead, resource attributes can be overridden on a per-account basis in the view.

Resource attribute overrides are stored in the attribute object under an attribute named resourceAttributes. If, for example, the resource defined an attribute named host, this could be specified in the view with the path:

accounts[Active Directory].resourceAttributes.host

Although overriding resource attributes is not recommended, sometimes you cannot avoid it. You might choose to overwrite a resource to avoid creating duplicate resources that point to the same physical resource but differ by one attribute. For example, in a customer environment that has multiple Active Directory servers, it may make more sense to override the resource attribute host in the form than to create a new resource. Contact your Waveset support representative for more information.

accounts[Lighthouse]

Sets the values of only the attributes stored in the Waveset repository. When a view is created, it contains a copy of the attributes in the waveset.attributes attribute set. When the view is saved, the system compares the contents of accounts[Lighthouse] with waveset.attributes to generate and update reports and audit log entries. Although this attribute is stored in the Waveset repository, changes to this attribute are not automatically propagated to resources.

The Extended User Attributes Configuration object defines the attributes that are allowed in this view. The system ignores any name found in this set of attributes that is not registered in the configuration object.

The following code is a sample of the Extended User Attributes Configuration object. This object maintains the list of attributes that are managed by the waveset.attribute set.

<?xml version=’1.0’ encoding=’UTF-8’?>
<!DOCTYPE Configuration PUBLIC ’waveset.dtd’ ’waveset.dtd’>
<!--  id="#ID#Configuration:UserExtendedAttributes" 
      name="User Extended Attributes"-->
 <Configuration id=’#ID#Configuration:UserExtendedAttributes’ 
      name=’User Extended Attributes’
 creator=’Configurator’ createDate=’1019603369733’ lastMod=’2’ counter=’0’>
  <Extension>
    <List>
      <String>firstname</String>
      <String>lastname</String>
      <String>fullname</String>
<!—add string values here - - >
      <String>SSN</String>
    </List>
  </Extension>
  <MemberObjectGroups>
    <ObjectRef type=’ObjectGroup’ id=’#ID#Top’ name=’Top’/>
  </MemberObjectGroups>
</Configuration>

This object can be modified to extend the list from the default firstname, lastname, and fullname attributes. In this case, an attribute called SSN has been added.

accounts[Lighthouse].delegates

Lists delegate objects, indexed by workItemType, where each object specifies delegate information for a specific type of work item

• If delegatedApproversRule is the value of delegateApproversTo, identifies the selected rule.

• If manager is the value of delegateApproversTo, this attribute has no value.

This attribute takes the attributes contained in the Attributes of accounts[Lighthouse].delegate* Attributes table.

accounts[Lighthouse].delegatesHistory

Lists delegate objects, indexed from 0 to n, where n is the current number of delegate history objects up to the delegate history depth. This attribute takes the attributes contained in the Attributes of accounts[Lighthouse].delegate* Attributes table.

accounts[Lighthouse].delegatesOrginal

Original list of delegate objects, indexed by workItemType, following a get operation or checkout view operation. This attribute takes the attributes contained in the following table.

accounts[Lighthouse].properties

The value of this attribute is an object whose attribute names correspond to the properties defined by the user. User properties allow arbitrary custom data to be stored with the user in the Waveset repository. You can then use properties in forms and workflows. A property is similar in some ways to an Extended User Attribute, but are not limited to primitive data types such as strings or integers.

Waveset defines the tasks system property, which is used by the Deferred Task Scanner to cause workflow tasks to be run at some date in the future. The value of the tasks property is a list of objects. The following table defines the attributes that belong to objects in the list.

Sample Use

You can use the accounts[Lighthouse].properties value to display a table of the deferred tasks assigned to a user. This list is added to the form library named Default User Library, which is found in sample/formlib.xml.

The field that displays the deferred task table is named Deferred Tasks. After modifying the waveset.properties attribute, the deferred task table is now referenced by the default Tabbed User Form. If any deferred tasks exist, the table will be displayed at the bottom of the Identity tab panel.

accounts[Lighthouse].viewUserForm

Used to display a view-only User form. This view-only form displays field information as Labels, to ensure that the administrator cannot change values, although he can list, view, and search on this user information. (The administrator selects a user from the accounts list, then clicks View to see user details.)

accounts[<resource>].properties

Used to store account properties in the Waveset repository. Use this attribute if you have some information about the account -- for example the date it was created -- that cannot be stored as a native account attribute on the resource.

accounts[<resource>].waveset.forceUpdate

Used to specify a list of resource account attributes that will always be sent to the resource for update when a user is modified and that an attribute value remains available to resource actions. This attribute is required for resource actions to be run when a user is unassigned from a resource.

The following field definition from a user form uses a Solaris resource. (<resource> has been replaced with the name of the resource.):

<Field name=’accounts[waterloo].waveset.forceUpdate’>
   <Default>
      <List>
          <String>delete after action</String>
          <String>Home directory</String>
      </List>
   </Default>
</Field

The preceding code causes Waveset to send the delete after action and Home directory attribute to the provisioner and resource adapter.

global Attribute

You can use the global attribute set of the user view to conveniently assign attributes to many resource accounts (including Waveset). The value of the global attribute is an object whose attributes are referred to as global attributes. When the view is saved, the system assigns the value of each global attribute to all resource accounts that define the global attribute name in their schema map. These values are also propagated to the Waveset repository if there is an extended attribute with the same name.

For example, two resources R1 and R2 define an attribute named fullname. When the attribute global.fullname is stored in the view, this value is automatically copied into attributes accounts[R1].fullname and accounts[R2].fullname.

You can also use global attributes to assign extended attributes that are stored in the Waveset repository. If a global attribute is also declared as an extended Waveset attribute, it is copied into accounts[Lighthouse].

Do not use global.accountId when creating accounts. The account ID is created by the DN templates on the resources. Using global.accountId overrides this, which may cause problems.

Referencing Two Different Fullname Attributes

The global attribute can be used in combination with the account attribute for the same attribute name. For example, on an Active Directory resource, the structure of the fullname is lastname, firstname. But all other resources that have a fullname use firstname lastname.

The following example shows how you can reference these two fields in a form.

<Field name=’global.fullname’>
 <Expansion>
       <concat>
         <ref>global.firstname</ref><s> </s>
         <ref>global.lastname</ref>
       </concat>
 </Expansion>
</Field>
<Field name=’accounts[ActiveDir].fullname’>
 <Expansion>
       <concat>
          <ref>global.lastname</ref><s>, </s>
          <ref>global.firstname</ref>
      </concat>
   </Expansion>
</Field>

In the preceding example, creating a new user works as expected. However, when you load the user, the fullname attribute from the Active Directory resource can be used to populate the global.fullname field.

A more accurate implementation for this scenario would be to declare one resource to be the authoritative source for an attribute and create a Derivation rule such as the following:

<Field name=’global.fullname’>
 <Derivation>
       <or>
         <ref>accounts[LDAP res].fullname</ref>
         <ref>accounts[AD res].fullname</ref>
       </or>
 </Derivation>
      <concat>
          <ref>global.firstname</ref><s> </s>
          <ref>global.lastname</ref>
      </concat>
   </Expansion>
</Field>
   <Expansion>

By defining a Derivation rule, the value of the fullname attribute in the LDAP resource will be used first to populate the fullname field. If the value does not exist on LDAP, then the value will be set from the AD resource.

accountInfo Attribute

Contains read-only information about resource accounts associated with the user. It is used within system views besides the user view. Some information in this view is a duplicate of the information found in the waveset.accounts attribute. There are two reasons for this duplication:

• Information in this view is structured so that it is easier to use in forms

• This view can be used as a component of other views without including the entire waveset view.

Most account information is stored in the accountsInfo.accounts attribute. Other attributes simply contain lists of account names. It is common to use a FieldLoop in a form to iterate over the names in one of the name list attributes, then use this name to index the account list attribute.

For example, the following form element generates a list of labels that contain the names of each resource that is assigned indirectly through a role.

<Field name=’accountInfo.accounts[$(name)].name>
   <FieldLoop for=’name’ in=’accountInfo.fromRole’>
     <Display class=’Label’/>
   </Field>
</FieldLoop>

The following tables shows the accountInfo view attributes, which describe characteristics about the user.

accountInfo.accounts

Contains a list of objects that themselves contain information about each associated resource account. Elements in the accounts list are referenced by name, where the name is the name of the resource.

Example

accountInfo.accounts[Active Directory].type

Objects found in the accountInfo.accounts list have the following attributes, as defined in the following table.

accountInfo.accounts[ ].attributes[ ]

Contains information about all the account attributes defined by this resource. These attributes are listed on the schema map page of the resource. The value of the attribute is a List of objects.

The following table defines the attributes that these objects contain.

If you are designing a form, do not worry about the declared resource account attribute types. The user view processing system makes the appropriate type coercions when necessary.

accountInfo.accounts[].passwordPolicy

A resource can be assigned a password policy. If an attribute has an assigned password policy, the value of this attribute will contain information about it.

The following table defines the attributes in the accountInfo.accounts[resname].passwordPolicy.

Applications that display policy information typically display the summary text, but if you need more fine-grained control over the display of each policy attribute, you can use the attributes map.

Forms that provide an interface for changing and synchronizing passwords often use this information.

accountInfo.accounts[Lighthouse]

This special entry in the accountInfo list is used to hold information about the Waveset default password policy. This is convenient when displaying password forms since information about the Waveset password and policies must be displayed along with the information for resource accounts.

This element is present only when pass-through authentication is not being used. The resource type is Lighthouse.

accountInfo Resource Name Lists

The accountInfo view includes attributes that contain lists of resource names. Each list is intended to be used in forms with FieldLoop constructs to iterate over resources with certain characteristics.

The accountInfo attributes that can contain resource names are:

• assigned

• created

• fromRole

• private

• toCreate

• toDelete

accountInfo.assigned

Identifies the resources that are assigned to the user. If you are designing a form, you can call this attribute to display a list of resources that are assigned from the role, applications, and that are directly assigned to a user.

accountInfo.typeNames

A list of unique type names for every assigned resource. This is used in Disable expressions in forms where you want to disable fields unless a resource of a particular type is selected.

<Field name=’HomeDirectory’ prompt=’Home Directory’>
   <Display class=’Text’/>
      <Disable>
         <not>
            <contains>
               <ref>accountInfo.typeNames</ref>
               <s>Solaris</s>
            </contains>
         </not>
      </Disable>
</Field>

This returns the same information as the path accountInfo.types[*].name but is more efficient, which is important when used with Disable expressions. This list can include common resource types.

You can determine the resource type names by bringing up the resource list from the Waveset Administrator Interface. The Type column on this page contains the names of the type of currently defined resources. The options list next to New Resource also contains the names of the resource adapters that are currently installed.

accountInfo.types

This attribute contains information about each type of resource that is currently assigned. The value of the attribute is a List (objects).

The following table shows the attributes that belong to each object.

For example, you can determine a list of IDs for all UNIX accounts with the following path:

accountInfo.types[Unix].accounts

display Attribute

The display attribute contains information that relates to the context in which the view is being processed. Most of the attributes are valid only during interactive form processing.

The following table shows the most used display view attributes.

Default itemType Behavior

Typically, only wizard itemTypes cause a workflow to transition directly to a WorkItem if the requester is the owner of the workItem.

When itemType is set as follows, the workflow will not transition into a WorkItem, but will instead appear under the Approval tab:

• approval

• custom

• itemType

Overriding Default Behavior

You can override behavior in the User view by setting the allowedWorkItemTransitions option as a property of the form as follows:

<Form ......>
   <Properties>
     <Property name=’allowedWorkItemTransitions’>
       <list>
         <s>myCustomType</s>
        </list>
 <     /Property>
    </Properties>

Deferred Attributes

A deferred attribute is an attribute that derives its value from an attribute value on a different account. You declare the deferred attribute in a view (and the WSUser model), and the provisioning engine performs this substitution immediately before calling the adapter.

If the deferred attribute derives its value from another resource’s GUID attribute, the source adapter does not need to take action. However, if the source attribute is not the GUID, the adapter must return the attribute in the ResourceInfo._resultsAttributes map as a side effect of the realCreate operation. If the adapter does not return the attribute, the provisioning engine will fetch the account to get the value. This is less efficient than modifying the adapter to return the value.

When to Use Deferred Attributes

Use deferred attributes when creating new accounts to specify that the value of an account attribute is to be derived from the value of an attribute on a different account that will not be known until the source account has been created. One common example is to set an attribute to the value of the generated unique identifier.

Using Deferred Attributes

There are two main steps to defining a deferred attribute:

To Define a Deferred Attribute

1. Ensure that the account is created on the source resource before the second account is created. Do this by creating an ordered Resource Group that contains both resources and assigning the Resource Group to the user.

2. Set the special attributes in the User view for the accounts that are to be created as indicated by the following sample scenario. Each deferred attribute requires two view attributes: one that identifies the source account, and one that identifies the source attribute. Set these using paths of the following form:

   accounts[<resource>].deferredAttributes.<attname>.resource accounts[<resource>].deferredAttributes.<attname>.attribute

   where <resource> would be replaced with an actual resource name and <attname> replaced with an actual attribute name.

   For example, assume a scenario in which the following two resources are created: 1) a resource named LDAP that generates a uid attribute when an account is created; 2)a resource named HR, which contains a directoryid attribute named directoryid, whose value is to be the same as uid in the LDAP resource.

   The following form fields set the necessary view attributes to define this association.

   <Field name=’accounts[HR].deferredAttributes.directoryid.resource’> <Expansion><s>LDAP</s></Expansion> </Field> <Field name=’accounts[HR].deferredAttributes.directoryid <Expansion><s>uid</s></Expansion> </Field>

Debugging the User View

When debugging the User view, you might find it useful to dump the contents of the view into a new file. To create a dump file, add the following Derivation statement to the User view:

<Field name=’DumpView’>
   <Derivation>
      <invoke name=’dumpFile’>
         <ref>form_inputs</ref>
            <s>c:/temp/view.xml</s>
      </invoke>
   </Derivation>
</Field>

This Derivation expression invokes the dumpFile method, which generates the file after the User form is displayed for the first time. The form_inputs variable is automatically bound to the view that is being used with this form.

In the preceding example, the String argument to the dumpFile method is a file system path, where you substitute a valid path for c:/temp/view.xml.