REAUTHORIZE

{REAUTHORIZE: user_field_name [NODISPLAY] ‘message to display‘}

• This action is only valid within the onchange and preupdate directive sections of the business rules.  However, it is important to note that when used within an onchange directive, the issue being processed is updated immediately after successful reauthorization.  This is to avoid confusion with the user, who might process the electronic signature and believe they have completed their update
• The administrator may set up the reauthentication of the current user at the time the issue is updated. If the re-authentication is successful, the issue is updated and the name of the current user is placed in the field user_field_name. The reauthentication or electronic signature mechanism demands that the user must enter their password before the transaction is allowed to continue. The application will continue to request the user’s password until it is entered correctly. The user may cancel out of the signature request, but will not be able to update the record
• The field user_field_name must be placed on the add or edit screen. The field also requires read and write access for the user roles that will perform the re-authentication. If you want to hide the field from the user’s view until the REAUTHORIZE action and associated rules provide values, set a layout cell attribute of the type VISIBLE IF and a value of NOT NULL
• Do not set the value of user_field_name  user_field_name within the rules that are part of the reauthorization code.  The value is set automatically by the action and unpredictable behavior will result if you assign it any value.  You can use the rules to set any other field values, such as the timestamp of the event.  Of course, you can assign a value user_field_name by rules that are not triggered with the REAUTHORIZE REAUTHORIZE command
• The NODISPLAY option alters the display of the popup.  This is an optional within the REAUTHORIZE action.  When this is not present, the current user’s name appears within the popup where the reauthentication is carried out, in read-only format.  The user need only enter their password to complete the action.  When this is present, the user must enter both their User ID and their password.  It is not valid for any other user than the one who is currently signed onto the ExtraView session to complete the reauthentication.
• With most electronic signatures, you will want to record a timestamp of the event. You can set up a field with a display type of day or date and place it on the form in the same way as the user_field_name. It should also be given a similar layout cell attribute to the user_field_name, of VISIBLE IF NOT NULL
• As an example, create the following business rule in the preupdate directive section of the rules:<== preupdate ==>
  if (STATUS.{changed to: ‘Approved’} && APPROVED_BY.{is null}) {
  {REAUTHORIZE: APPROVED_BY ‘By clicking the Submit button you are approving the update of this issue. This is an electronic signature which is recorded in the database. <span style=color:#CC0000>Any appropriate text may be placed here as a warning.</span>’};
  }
  # if we get here, we have assented to the reauthorization, so set the trigger fields:
  if (STATUS.{changed to: ‘Approved’} && APPROVED_BY.{is not null}) {
  APPROVAL_DATE = SYSDAY;
  }
  # clear approval if reopened
  if (STATUS.{changed from: ‘Approved’} && STATUS != ‘Closed’) {
  APPROVAL_DATE = “”;
  APPROVED_BY = {null};
  }
  if (STATUS.{changed from: ‘Closed’} && STATUS != ‘Approved’) {
  APPROVAL_DATE = “”;
  APPROVED_BY = {null};
  } Assign the APPROVAL_DATE to SYSDAY if the field is of type day as opposed to date. This will set the APPROVAL_DATE to the current date and time when the APPROVED_BY field is set, and set it to a null value if the APPROVED_BY field is set to null. The key condition that triggers the reauthorization requires a little explanation. In the above example, the condition is:if (STATUS.{changed to: ‘Approved’} && APPROVED_BY.{is null})

  The reauthorization is special, in that the user is not able to exit from the action, until they either successfully enter their password, or cancel the complete action. The first part of the trigger expression (STATUS.{changed to: ‘Approved’}) is the change upon which you want to trigger the reauthorization. Once the user enters their password, ExtraView validates this, and then executes the expression again. This is where the APPROVED_BY.{is null} part of the expression comes into play. A successful reauthorization will have set the APPROVED_BY field to a value, usually the value of the current user. Therefore, the reauthorization is not reentered, as the evaluation of APPROVED_BY.{is null} now returns a false value

• As a second example, when you would like the REAUTHORIZATION rule to be triggered within an onchange directive, there is an alteration to be made so that the timestamp of the issue is not updated until the actual time that the issue is updated.  onchange directives do not update any information within the current issue.  This example show how to make this happen:<== onchange ==>
  if (STATUS.{changed to: ‘Approved’} && APPROVED_BY.{is null}) {
  {REAUTHORIZE: APPROVED_BY ‘By clicking the Submit button you are approving the update of this issue. This is an electronic signature which is recorded in the database. <span style=color:#CC0000>Any appropriate text may be placed here as a warning.</span>’};
  <== preupdate ==>
  if (STATUS.{changed to: ‘Approved’} && APPROVED_BY.{is not null}) {
  APPROVAL_DATE = SYSDAY;
  }
  
• The message to display in the REAUTHORIZE syntax allows the display of any text on the popup window where the electronic signature is provided. Many organizations have a message approved by their legal departments that is used here. Notice that the message to display may contain HTML, allowing you to format the message. A typical electronic signature popup window will look like the following:
• The administrator may set up any number of electronic signature requests, each with a different logical expression that triggers the requirement for the user to enter their signature
• If an issue is on a report and Quickedit is used to update the issue, then the electronic signature can only be triggered if the field containing the signature is placed on the report.  No prompt for completion of the electronic signature is made without this
• If you implement the REAUTHORIZE rule within a repeating row, then the user field that contains the electronic signature must be a popup user field and the user must complete the electronic signatures in order, starting with the first repeating row
• As explained in the section on Creating & Updating Layouts, you should be careful not to place the user_field_name and the day or date field on a row within the layout by themselves.  With the VISIBLE IF NOT NULL layout cell attributes, the entire row would not be rendered within the browser’s DOM, and therefore ExtraView could not alter their values with the REAUTHORIZE rule.

The REAUTHORIZE action is only supported in the preupdate directive.  As stated above, users have the ability to alter field values within their issues after an onchange directive is processed, and the electronic signature would not reflect the values within the issue at the point in time the user provided their signature.

Note: If the site utilizes SAML as a SSO mechanism to authenticate user’s sign on credentials, the user is redirected to the SAML sign on screen for the reauthentication.  Due to limitations in third-party SAML providers’ software, this authentication takes place in a separate browser window or tab.  Once the user enters a valid User ID and password they are redirected back to the ExtraView screen to complete the update caused by the electronic signature REAUTHORIZE action.