USER MAPPING

<== user mapping ==>

This directive allows business rules to be triggered when a user account is modified.  This directive is often used as the companion to the action rules of CREATE USER and UPDATE USER.  CREATE USER and UPDATE USER allow users to be managed from add and edit screens, while the <== user mapping ==> directive allows administrative changes to users to be reflected in updates to issues.

This is significantly different from other directives which are triggered when issues are inserted or updated.  This directive is triggered when changes to user information are submitted.

As an example, the rules within this directive are triggered when an administrator goes to the User Account maintenance screen, and edits a user's account.  When the administrator updates the user record, the changes to the account are made in the normal way and the rules in the <== user mapping ==> rules section are executed.

This rule provides a means to synchronize the values within a user's record to issues where the user's details are stored.

To facilitate the operation of this directive, there are two session variable fields defined in the Data Dictionary:

  1. RULES_MANAGED_USER - this is the user field containing the User ID of the user that was created, modified or deleted by the user transaction that invoked the mapping rule
  2. RULES_TXN_NAME -  this is an option where a text field placed on the layout can contain either a value of ADD, EDIT or DELETE. This signifies which user transaction invoked the mapping rules.  An example might be that with a value of ADD you can have further rules within this directive to execute a ADD action rule, or if there is a value of EDIT then you might execute an UPDATE action rule.

Note that there are action rules that permit a user's account details to be created or updated and synchronized in the opposite direction, i.e. from issues to user accounts.  These actions are CREATE USER and UPDATE USER.

The ADD/UPDATE task must be running for this directive to be operable.

Example

<== link vendorContactLink ==> AREA=Vendors, PROJECT=Contacts, CONTACT.{is not null}, NEW_USER_ID.{is not null}, CONTACT=RULES_MANAGED_USER, STATUS='Active'

<== user mapping ==>
if ((vendorContactLink).ID.{is not null}) {
{ UPDATE: vendorContactLink
    VENDOR_FNAME = RULES_MANAGED_USER.{first name},
    VENDOR_LNAME = RULES_MANAGED_USER.{last name},
    VENDOR_PHONE = RULES_MANAGED_USER.{cell phone}
};
 

  • The link rule vendorContactLink searches for all issues where the AREA equals Vendors, the PROJECT equals Contacts, there is a value in the CONTACT field, there is a value in the NEW_USER_ID field, and the value of the STATUS field is Active.  The value in the CONTACT field must be the User ID of the user that caused the rule to execute, i.e. the RULES_MANAGED_USER
  • The rules within the <== user mapping ==> directive first check to see if the identified issue or issues exist.  Note there may be more than one matching issue
  • For the matching issues found with the link the current value from the user's account for the first name, last name and cell phone are then saved into the issue(s) in the VENDOR_FNAME, VENDOR_LNAME and VENDOR_PHONE fields.