Form: re-calculation of already filled fields

Which IIQ version are you inquiring about?

Version 8.3

Share all details related to your problem, including any error messages you may have received.

In a form I am trying to do some things in a field with dynamic=true. According to the documentation, a dynamic=true field is only recalculated when a postback action is triggered, even though the field has lost there focus.

Additional is documented that a field with dynamic=true is only recalculated if there is no value “manually” entered. The real behavior here is a “not null” check, but it is not releated, if a value is manual or automatic changed or if is a previous saved value.

Depending on this behavior is a “hack” documented, to force a re-calculation for already filled fields.

  1. In Section hidden-attribute, the form field must set to NULL with a custom mini script.
  2. Then the form field should be re-calculated, wich means, gets called.

But thats not working, because Field-Script-Source will called first and then the hidden attribute gets calculated. So it works only with a second postback.

Is the documentation wrong or is this buggy?

See:
8.3_IdentityIQ_Forms.pdf
Components of a Form Definition → Fields → dynamic
Page 17

Dynamic form fields can be pretty wonky.

  • postBack = this field will trigger reevaluation on the backend when updated on the client
  • dynamic = this field will be reevaluated when triggered

Validation scripts like AllowedValues are also invoked on every postBack, regardless of dynamic.

You’re correct that auxiliary scripts like ‘hidden’ and ‘readOnly’ can be used to produce interesting effects. These can be on any Section or any Field. They’ll all run every time. You can do anything to any Field using these scripts.

What I’d do in your case is probably:

  1. Keep the regular field value script on the Field itself. However, extract it to a Rule Library so that you can re-use the code.
  2. In the ‘hidden’ script, if your Field has an invalid value and you’d like to re-calculate it, invoke that same Rule Library method and set the Field value to the desired value, rather than NULL.

There’s a sneaky coding trick here, though. While normal Scripts can use Rule Libraries via an <Includes> section, like this (and this is what you’d do in your Field Value script) …

<Script>
   <Includes>
      <Reference class="sailpoint.object.Rule" name="Some Rule Library"/>
   </Includes>
   <Source>
      // your code here
   </Source>
</Script>

… the Scripts within ‘hidden’ and ‘readOnly’ attributes explicitly cannot. Internally, the Script objects are copied before they’re run, but the Includes list is not copied. I consider this an IIQ bug. But there is an easy workaround. IIQ has a “secret” include syntax, which looks like this:

<entry key="hidden">
    <value>
        <Script>
            <Source><![CDATA[
            	// #include "Some Rule Library"
                // your code here
            ]]></Source>
        </Script>
    </value>
</entry>

This is how Rule Libraries worked prior to Rule Libraries. IIQ will evaluate the text of a Beanshell script before invoking it, and if it includes that // #include syntax, the source of that other rule will be simply swapped in there in place, as a straight string replacement.

2 Likes

Thanks for your suggestion with the hidden feature (// #include …) for code reusing. This was also my thinking and now is a good practice possible.

I was hoping, my understanding of the documentation could be wrong. :wink:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.