Allow special characters in auto_accounts by adding data-alias#4673
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.
There was a problem hiding this comment.
I think it's fine - or at least it is until it isn't 😆.
|
|
||
| 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
|
@johrstrom @Bubballoo3 just reviewing all 4.1 PRs in flight - what needs to happen (next steps) for this PR to be merged? |
I think we're ready to merge, I just need to give it a once over again. |
johrstrom
left a comment
johrstrom
left a comment
There was a problem hiding this comment.
OK - I think we're ready to go!
github-project-automation
bot
moved this from Awaiting Review
to Merged/Closed
in PR Review Pipeline
4 participants
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.