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<\/em> and edit<\/em> screens, while the 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.<\/p>\n 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 This rule provides a means to synchronize the values within a user’s record to issues where the user’s details are stored.<\/p>\n To facilitate the operation of this directive, there are two session variable fields defined in the Data Dictionary:<\/p>\n 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 The ADD\/UPDATE task must be running for this directive to be operable.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" <== 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…<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_acf_changed":false,"_lmt_disableupdate":"","_lmt_disable":"","_kad_blocks_custom_css":"","_kad_blocks_head_custom_js":"","_kad_blocks_body_custom_js":"","_kad_blocks_footer_custom_js":"","_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"class_list":["post-22236","page","type-page","status-publish","hentry"],"acf":[],"yoast_head":"\n<== user mapping ==><\/code> directive allows administrative changes to users to be reflected in updates to issues.<\/p>\n<== user mapping ==><\/code> rules section are executed.<\/p>\n\n
CREATE USER<\/code> and UPDATE USER<\/code>.<\/p>\n\n\tExample<\/h4>\n
<== link vendorContactLink ==> AREA=Vendors, PROJECT=Contacts, CONTACT.{is not null}, NEW_USER_ID.{is not null}, CONTACT=RULES_MANAGED_USER, STATUS='Active'<\/code><\/code><\/p>\n<== user mapping ==>
\n\tif ((vendorContactLink).ID.{is not null}) {
\n\t{ UPDATE: vendorContactLink
\n\t VENDOR_FNAME = RULES_MANAGED_USER<\/span>.{first name},
\n\t VENDOR_LNAME = RULES_MANAGED_USER<\/span>.{last name},
\n\t VENDOR_PHONE = RULES_MANAGED_USER<\/span>.{cell phone}
\n\t};<\/code>
\n\t <\/p>\n\n
vendorContactLink <\/code>searches for all issues where the AREA equals Vendors<\/em>, the PROJECT equals Contacts<\/em>, 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<\/em>. 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<\/span><\/li>\n<== user mapping ==><\/code> directive first check to see if the identified issue or issues exist. Note there may be more than one matching issue<\/li>\n