Allow special characters in auto_accounts by adding data-alias #4673
Conversation
| rm_btn = find("#launcher_auto_accounts_remove_#{acct}") | ||
| add_btn = find("#launcher_auto_accounts_add_#{acct}") | ||
| counter += 1 | ||
| html_acct = "option#{counter}" |
There was a problem hiding this comment.
The counter = 7 here works due to the order of the account fixtures, and the ids are now determined by option order instead of value. I recognize that this is a bit 'magic numbery', but the alternative would be identifying the data-select-value and then finding the add and remove button directly below. That method would be nice for making this test resistant to fixture changes (that might change the index of the options) but would add complexity, and is not really the point of the test. Open to taking the other path though if that is important.
|
|
||
| function cacheAliases(elementId) { | ||
| // This should only run once on each select with an alias defined | ||
| if (!Object.keys(aliasLookup).includes(elementId)) { |
There was a problem hiding this comment.
Can this expression be aliasLookup[elementId] !== undefined instead? It's really not a big deal, there's just something about Object.keys.includes that I feel is wonky in javascript.
That is, the language itself is very flexible in at least trying to access properties. Functions throw errors - but properties never do.
There was a problem hiding this comment.
That makes sense
There was a problem hiding this comment.
Taken care of, with the slight edit that the correct replacement for !Object.keys(aliasLookup).includes(elementId) is aliasLookup[elementId] === undefined
| const value = data[key] | ||
| aliasLookup[elementId][value] = alias; | ||
| } | ||
| }) | ||
| }) |
There was a problem hiding this comment.
Please be liberal in using ;s. Maybe a nit-pick, but I just feel uneasy about lines or method calls without them.
Of course this likely works fine, but at a glance, it just looks off.
There was a problem hiding this comment.
Sorry about that, I went ahead and fixed it up for these changes and a few lines from the aria-announcement PR that I had missed
Fixes #3919 by adding the data-alias directive to dynamic forms. This allows any option-for or exclusive-option-for directive to use a safe name for a value instead of the actual option value. The aliases are scoped to the select widget they are defined in, so the automatically set aliases in auto_accounts will never conflict with a user-defined alias. The alias is only tried if no plain option-for directive is found, so if there were ever a conflict between an alias and a true account value, the true account value would be engaged.
Tests have been added demonstrating the data-alias directive for option-for and exclusive-option-for, and accounts with special characters have been added to the fixtures to ensure the full auto_accounts flow handles these properly. This could be expanded to other auto fields like clusters and queues, but that implementation would closely match what has been done here for account values. The current solution uses aliases for any account with characters beyond digits and lowercase letters, just to be overly cautious.
This PR isn't quite finished, I have not completely resolved the project manager implementation of auto_accounts, so some ProjectManagerTest tests are expected to fail until that is fixed. My plan for those is to identify the options by their order by substituting the value with option{index}. From there
launcher_edit.jsshould be able to match the aliased values by their place in the auto_accounts template. I have less familiarity with the project manager than the dynamic forms, so if this is a flawed approach I would be very welcome to better ideas.I would also like to allow data-max/min-for directives to use aliases, and will be adding that after the project manager stuff is worked out.