Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Account names with special characters break the auto_accounts/auto_queues form widget #3919

Open
tw0flower opened this issue Oct 31, 2024 · 7 comments

Comments

@tw0flower
Copy link

tw0flower commented Oct 31, 2024

Hi,

We use the auto_accounts and auto_qos widgets to generate a form for a Jupyter interactive application, and the account names that we use seem to break the web page.

Our Slurm accounts names include "." and "_" characters, which get brought directly into the HTML code. For instance, one of the attributes in the auto_account menu will have value=faculty_name.surname, and the corresponding data-option-for-auto-accounts attribute in the QoS menu will be data-option-for-auto-accounts-faculty_name.surname.

The Javascript code for the form page does not find the entries to hide because of these special characters, which results in incompatible QoS options being displayed. The image below presents the case of a user that has access to 3 Slurm accounts. With the faculty_name.surname account selected, some QoS options that belong to other accounts are displayed. This does not happen with accounts that do not have special characters in their names: only QoS options that belong to the account are showed.

Changing the attribute names in the HTML code to faculty-name-surname and data-option-for-auto-accounts-faculty-name-surname in the browser's developer tools fixes the issue.

The code generating the HTML page seems to belong to this file:

hash["data-option-for-auto-accounts-#{account}"] = false

@osc-bot osc-bot added this to the Backlog milestone Oct 31, 2024
@johrstrom
Copy link
Contributor

It might take me a little bit to replicate. In the interim, you can hot patch your system by editing the file if you wish. If you do, just backup the original file so you can rollback if you need to.

Seems like you're suggesting that this change to substitute . and _ with - could work?

-  hash["data-option-for-auto-accounts-#{account}"] = false 
+  hash["data-option-for-auto-accounts-#{account.to_s.gsub(/[._]/, '-')}"] = false 

@tw0flower
Copy link
Author

@johrstrom Thanks for your quick reply, and for the hot patch suggestion.

This fixes this issue for the QoS widget, but not the value=faculty_name.surname attribute in the account list. I'm not familiar with Ruby/Ruby on Rails and I haven't been able to figure out where I should apply the regex to change that.

This will definitely work for us. There's a tiny chance that folks with similar account names end up with duplicates by applying this regex (for instance, faculty_name.surname and faculty.name_surname), but it's the best solution I can think of for now!

@johrstrom
Copy link
Contributor

Yea unfortunately we need to do all sorts of translations, so it may not work entirely. Basically we have to go from dash-style in HTML to camelCase in javascript then back to the original value/actual which is likely snake_case (or at least assumed to be).

https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset#name_conversion

@tw0flower
Copy link
Author

I took some time yesterday to go deeper into the auto_accounts attribute code. Unfortunately, changing the value attribute to not include special characters in this widget breaks submission. Specifically, I tried to apply the regex to the second element of this array:

[account_name, account_name, data]

This fixes the form itself, but then the edited value is sent to our scheduler, which fails.

Now that I'm looking at the code on Github again, you seem to be passing the value differently in the master branch:

static_opts = {
options: options,
value: default_value(opts, scalar_accounts(options))
}.merge(opts.without(:options, :value).to_h)

Version 3.1.9 only has this:

      static_opts = {
        options: options
      }.merge(opts.without(:options).to_h)

I'm going to try the version from the master branch with the hot-fix mentioned above and hopefully it will fix our issue.

@johrstrom
Copy link
Contributor

I'm going to try the version from the master branch with the hot-fix mentioned above and hopefully it will fix our issue.

I think that update was just to provide a default value. But yea your issue is tough because we do translations in javascript which may not be compatible with these sort of strings.

@tw0flower
Copy link
Author

I was under the impression that the most recent code set the value variable separately from the rest of the options, whereas the code in 3.1.9 set it as part of the options variable.

Would it be possible/realistic to creating a separate submitvalue attribute that would be submitted instead of value?

@johrstrom
Copy link
Contributor

I was under the impression that the most recent code set the value variable separately from the rest of the options, whereas the code in 3.1.9 set it as part of the options variable.

When the object is created, it's created with a default value, that's what you're seeing there.

This default value however is overwritten when the user submits the POST request from the form.

Would it be possible/realistic to creating a separate submitvalue attribute that would be submitted instead of value?

I mean, in the abstract, sure we could do whatever. In practice, that just seems wonky or error prone to me because we're suing value all over the place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants