• State Suggested Answer
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 68 subscribers
  • Views 380 views
  • Users 0 members are here
Options
Related

Disable checkbox when another one is activated in web interface

michael.junger_1237478612031

Hello,

I would like to create a new form with some checkboxes with a dependency. So, when I click on checkbox A, the checkbox B should be disabled and the user cannot activate it anymore unless checkbox A is deselected.

How can this be done in the webinterface of Active Roles?

Many Thanks

Michael

Parents
  • 0

      

    Active Roles doesn't offer a built-in "if A then disable B" toggle in the form designer — checkbox interdependency on a Web Interface form is done by attaching a small client-side script to the customized form. There are two supported paths:

    Option 1 – Web Interface form customization + script (recommended for pure UI enable/disable)

    1. In the Web Interface, switch to Customization mode (gear/admin menu → Customize), or use Active Roles Configuration Center → Web Interface to edit the relevant site (Admin/Helpdesk/Self-Service).
    2. Navigate to the command whose form you want to change (e.g. Create User, or your custom command) and edit its form.
    3. Add both checkboxes as form entries and note each entry's control ID (use the browser dev tools / F12 to confirm the rendered element id).
    4. Add a Script entry (or inject via a custom entry) that wires the change events, e.g.:
    document.addEventListener("DOMContentLoaded", function () { var a = document.getElementById("checkboxA_id"); var b = document.getElementById("checkboxB_id"); function sync() { b.disabled = a.checked; if (a.checked) b.checked = false; } a.addEventListener("change", sync); sync(); // apply initial state });

    When A is checked, B is disabled (and cleared) until A is unchecked.

    Option 2 – Server-side enforcement (recommended if the rule must be guaranteed, not just UI)

    Client-side disabling is cosmetic — a user could bypass it. If the two attributes must never both be set, back it up with a Policy Object → Property Generation and Validation (or a Script Policy) on the target object that rejects/clears the invalid combination on submit. This enforces the rule regardless of how the change is made (Web Interface, MMC console, ADSI, sync).

    For most "nicer UX" requests Option 1 is enough; use Option 2 when it's a data-integrity constraint.

    Docs / references

Reply
  • 0

      

    Active Roles doesn't offer a built-in "if A then disable B" toggle in the form designer — checkbox interdependency on a Web Interface form is done by attaching a small client-side script to the customized form. There are two supported paths:

    Option 1 – Web Interface form customization + script (recommended for pure UI enable/disable)

    1. In the Web Interface, switch to Customization mode (gear/admin menu → Customize), or use Active Roles Configuration Center → Web Interface to edit the relevant site (Admin/Helpdesk/Self-Service).
    2. Navigate to the command whose form you want to change (e.g. Create User, or your custom command) and edit its form.
    3. Add both checkboxes as form entries and note each entry's control ID (use the browser dev tools / F12 to confirm the rendered element id).
    4. Add a Script entry (or inject via a custom entry) that wires the change events, e.g.:
    document.addEventListener("DOMContentLoaded", function () { var a = document.getElementById("checkboxA_id"); var b = document.getElementById("checkboxB_id"); function sync() { b.disabled = a.checked; if (a.checked) b.checked = false; } a.addEventListener("change", sync); sync(); // apply initial state });

    When A is checked, B is disabled (and cleared) until A is unchecked.

    Option 2 – Server-side enforcement (recommended if the rule must be guaranteed, not just UI)

    Client-side disabling is cosmetic — a user could bypass it. If the two attributes must never both be set, back it up with a Policy Object → Property Generation and Validation (or a Script Policy) on the target object that rejects/clears the invalid combination on submit. This enforces the rule regardless of how the change is made (Web Interface, MMC console, ADSI, sync).

    For most "nicer UX" requests Option 1 is enough; use Option 2 when it's a data-integrity constraint.

    Docs / references

Children
No Data