Change visibility of Request Property based on a previously filled out field

Hi Devs and One Identity Community,

How can I change the visibility or availability of a parameter based on an input of a previously filled out field?

I assume that this can be done or there is a possibility of doing this via the data dependency script however I can't figure out how.

I am currently trying to implement the following behavior with the new request properties:

When user chooses a certain department while requesting a product. In the request details sidesheet  a set of chechboxes should become visible and if a different department is chosen a different set of checkboxes should appear.

Any help is appreciated

Thanks

Gilles

Parents
  • Hello, Gilles.

    You are combining two different concepts into one in this request.

    First there is the concept of a "bound list box". This encapsulates the idea of controlling the options that are available or selectable based on a previously made decision. For example, if you select a Country, then perhaps the State/Province drop-down box is automatically populated with only options that pertain to the country you have selected.

    In this example, however, you must bear in mind that the State/Province drop-down selection was always present and displayed on-screen. There is never any point at which that drop-down box is hidden based on the Country selected. This code and logic is executed on and by the AR server. This is easily searchable and has been discussed many times in these forums if you look under that heading.

    The second concept that you are introducing is dynamically controlling the visibility of the client interface. This code and logic is executed by the "client" - the IIS application - hence is specific to the Web interface. The first available mechanism for controlling this is a special script called Entries.vbs. As the name implies, this is indeed still a VBScript. Specifics are documented in the SDK under the heading Creating a Custom Entry. There are additional options if that is insufficient, however the level of complexity rises significantly beyond this point (e.g., "Managed Code", and/or custom ASP pages).

    Hope that sends you in the right direction!

    Shawn

Reply
  • Hello, Gilles.

    You are combining two different concepts into one in this request.

    First there is the concept of a "bound list box". This encapsulates the idea of controlling the options that are available or selectable based on a previously made decision. For example, if you select a Country, then perhaps the State/Province drop-down box is automatically populated with only options that pertain to the country you have selected.

    In this example, however, you must bear in mind that the State/Province drop-down selection was always present and displayed on-screen. There is never any point at which that drop-down box is hidden based on the Country selected. This code and logic is executed on and by the AR server. This is easily searchable and has been discussed many times in these forums if you look under that heading.

    The second concept that you are introducing is dynamically controlling the visibility of the client interface. This code and logic is executed by the "client" - the IIS application - hence is specific to the Web interface. The first available mechanism for controlling this is a special script called Entries.vbs. As the name implies, this is indeed still a VBScript. Specifics are documented in the SDK under the heading Creating a Custom Entry. There are additional options if that is insufficient, however the level of complexity rises significantly beyond this point (e.g., "Managed Code", and/or custom ASP pages).

    Hope that sends you in the right direction!

    Shawn

Children
No Data