Can't seem to get data-hide working?

twhitehead · October 16, 2025, 4:42pm

I’ve been trying to hide a form field element based on the value of a select dropdown form field following the documentation but just don’t seem to be able to make it work. I am using ondemand-4.0.6-1.el9.x86_64.

I have enabled them in my /etc/ood/config/ondemand.d/config.yml file with

...
bc_dynamic_js: true
..

and added the data-hide-… entries to my selection widget in my /etc/ood/config/apps/bc_desktop for yaml file

...
attributes:
  ...
  sn_gpu:
    widget: select
    label: GPU
    display: true
    options:
      - [ "None", "", data-hide-sn-virtualgl: true ]
      - [ "h100_1.10 (10GB)", "h100_1.10:1", data-hide-sn-virtualgl: true ]
      - [ "h100_2.20 (20GB)", "h100_2.20:1", data-hide-sn-virtualgl: true ]
      - [ "h100_3.40 (40GB)", "h100_3.40:1", data-hide-sn-virtualgl: true ]
      - [ "h100 (80GB)", "h100:1" ]
  sn_virtualgl:
    widget: "check_box"
    label: "Enable VirtualGL (if hardware OpenGL required)"
    checked_value: "yes"
    unchecked_value: "no"
  ...
attributes:
  desktop: "mate"
  sn_time:
    widget: "number_field"
    label: "Hours"
    value: 4
    min: 1
    max: 8
    step: 1
  sn_mem:
    widget: "number_field"
    label: "Memory (GB)"
    value: 8
    min: 4
    max: 6000
    step:  1
  sn_cores:
    widget: "number_field"
    label: "Cores (>12GB/core means longer large-memory queue times)"
    value: 2
    min: 1
    max: 192
  sn_gpu:
    widget: select
    label: GPU
    display: true
    options:
      - [ "None", "", data-hide-sn-virtualgl: true ]
      - [ "h100_1.10 (10GB)", "h100_1.10:1", data-hide-sn-virtualgl: true ]
      - [ "h100_2.20 (20GB)", "h100_2.20:1", data-hide-sn-virtualgl: true ]
      - [ "h100_3.40 (40GB)", "h100_3.40:1", data-hide-sn-virtualgl: true ]
      - [ "h100 (80GB)", "h100:1" ]
  sn_virtualgl:
    widget: "check_box"
    label: "Enable VirtualGL (if hardware OpenGL required)"
    checked_value: "yes"
    unchecked_value: "no"
form:
  ...
  - sn_gpu
  - sn_virtualgl
  ...
...

Even after doing a restart web sever from the develop menu, the sn_virtualgl check box remains shown for all sn_gpu selections as seen in this screenshot.

I know it is seeing my changes as any changes I make to the wording are showing up. Likewise I know it is reading my config entry as if I set the menu bar colour by adding add a brand_bg_color setting that works.

Here is a screenshot of what the Firefox inspector shows for the associated form items

I tried to look at and poke around on the javascript side as well, but it was unreadable minified code that I wasn’t able to work with in any meaningful way, and I couldn’t figure out how to turn off the minification.

twhitehead · October 16, 2025, 5:16pm

A further note on this after some more playing around. I found I could get it to dynamically hide the virtualgl checkbox for the first option that I set data-hide-sn-virtualgl: true on given that it wasn’t the first option and that I didn’t set data-hide-sn-virtualgl: false on any options before it including the first option.

Selecting that option would then hide the checkbox, and it would then remain permanently hidden regardless of whatever options I selected and if they had data-hide-sn-virtualgl set or what it was set to. The only way to bring it back was to do a refresh the webpage.

Given that I am getting some hidding behaviour, I am thinking this may actually be a bug?

travert · October 16, 2025, 5:41pm

Sorry, I’m confused looking at the config file. Why are there 2 sets of attributes set? I see an attributes block at the top, then another one below it and I’m not sure if that’s a typo.

twhitehead · October 16, 2025, 7:23pm

Sorry for the confusion. There is only one set of attributes. That bottom section was a cut and paste error. The file is /etc/ood/config/apps/bc_desktop/nibi-compute.yml. Here is the entire thing for clarity

---
cluster: nibi-compute

title: Compute Desktop
category: Compute Node
subcategory: Submit
description: |
  This launches a desktop job on a compute node.  Allocated resources
  are reserved solely for the job. It is ideal for computationally
  demanding applications. It is a job and (like all jobs) decreases
  priority of future jobs. Non-computationally demanding application
  are better done on a login node.

attributes:
  desktop: "mate"
  sn_time:
    widget: "number_field"
    label: "Hours"
    value: 4
    min: 1
    max: 8
    step: 1
  sn_mem:
    widget: "number_field"
    label: "Memory (GB)"
    value: 8
    min: 4
    max: 6000
    step:  1
  sn_cores:
    widget: "number_field"
    label: "Cores (>12GB/core means longer large-memory queue times)"
    value: 2
    min: 1
    max: 192
  sn_gpu:
    widget: select
    label: GPU
    display: true
    options:
      - [ "None", "", data-hide-sn-virtualgl: true ]
      - [ "h100_1.10 (10GB)", "h100_1.10:1", data-hide-sn-virtualgl: true ]
      - [ "h100_2.20 (20GB)", "h100_2.20:1", data-hide-sn-virtualgl: true ]
      - [ "h100_3.40 (40GB)", "h100_3.40:1", data-hide-sn-virtualgl: true ]
      - [ "h100 (80GB)", "h100:1" ]
  sn_virtualgl:
    widget: "check_box"
    label: "Enable VirtualGL (if hardware OpenGL required)"
    checked_value: "yes"
    unchecked_value: "no"
  sn_email:
    widget: "text_field"
    value: ""
    label: "Email on start (leave blank for no email)"
    pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
form:
  - desktop
  - auto_accounts
  - sn_time
  - sn_mem
  - sn_cores
  - sn_gpu
  - sn_virtualgl
  - sn_email
submit: submit/nibi-compute.yml.erb

travert · October 16, 2025, 8:41pm

Thanks for the correction!

Ok, thinking on this again, I am remembering there is some issue with radio buttons specifically for this feature and I think there’s an open issue. Yeah, this looks to be similar to what you are experiencing: data-label doesn't work with radio buttons · Issue #4607 · OSC/ondemand · GitHub

Can you confirm that describes what you see?

twhitehead · October 16, 2025, 10:16pm

Humm. I am not 100% certain how to check if that is also causing the issue I am seeing. In particular, I am using data-hide and not data-label.

It does say it is running afoul on the complicated structure of the collection_radio_button component of bootstrap forms though, so I figured maybe I could test it by switching the target to the sn_email form element (which is just a text box) and see if it worked on that.

It didn’t. That is, when I targeted the sn_email form element I saw the exact same behaviour as when I targeted the sn_virtualgl form element. That is

it would dynamically hide the email textbox for the first option that I set data-hide-sn-email: true on given that it wasn’t the first option and that I didn’t set data-hide-sn-email: false on any options before it including the first option,
selecting that option would then hide the checkbox, and it would then remain permanently hidden regardless of whatever options I selected and if they had data-hide-sn-email set or what it was set to, and
the only way to bring it back was to do a refresh the webpage.

So my guess would be that there is something more going on here (unless text boxes also have the same sort of complicated structure that is messing up radio buttons).

Thanks! Tyson

travert · October 16, 2025, 11:52pm

Thanks for doing that work.

I’m pretty hazy on how this feature works but I’m kinda curious, I see you have the default values set to use yes and no for checked_value and unchecked_value, but from reading about this on MDN and looking at the code itself that handles this, does the behavior change if you use true and false instead?

I ask just because I see those hardcoded in the javascript that I think handles this:

github.com/OSC/ondemand

apps/dashboard/app/javascript/dynamic_forms.js

e15f641ec


      
              ariaStream(`set ${elementInfo} to value ${changeVal}`);
          
              if(element['type'] == 'checkbox') {
                setCheckboxValue(element, changeVal);
              } else {
                element.value = changeVal;
              }
            }
          }
          
          function setCheckboxValue(checkbox, value) {
            const positiveValue = checkbox.value;
            if(value == positiveValue) {
              checkbox.checked = true;
            } else {
              checkbox.checked = false;
            }
          }
          
          /**
           *

But I don’t know enough to know if that is going to matter. I’ll try to play with this on my end because I’m kinda confused myself what that code is supposed to do when it is checking a value that is a string but expecting a positive integer…maybe it’s late but i literally cannot tell what that setCheckboxValue is actually doing the more I stare at it…seems to just always use true…but why then give you the option to set it? I have to get familiar with this because it’s not really making sense to me how this would ever work.

twhitehead · October 17, 2025, 1:53pm

I tried true and false instead of yes and no and it didn’t make any difference.

Thanks! Tyson

jeff.ohrstrom · October 20, 2025, 7:16pm

There appears to be a bug where the javascript cannot handle an empty string as a value here. I Think if you used - [ "None", "none", data-hide-sn-virtualgl: true ] or similar it would work.

I’m filing a bug upstream now with a patch, so it’ll be fixed in the next release in 4.1.

Topic		Replies	Views
Dynamic Behavior - Issue Get Help ondemand2 , question	6	571	September 17, 2022
Dynamic behaviour with dropdown Get Help question	7	900	April 15, 2023
Unable to hide radio button with checkbox Get Help question	2	126	October 7, 2024
Help with data-hide Get Help	5	67	September 2, 2025
About the operation of data-hide Get Help	2	314	April 23, 2024

Can't seem to get data-hide working?

Related topics