In the current effort for improving settings I’m basically rewriting settings from scrach and @lzap shared a good point, that we will want all plugin maintainers rewrite settings once this effort is done.
It would be great if everyone could think about what our setting model is missing and how we could improve it. So I’ve decided to create separate thread for visibility as followup for his comment.
some of the basic validations that are currently handled via constants could also be defined as attributes in the dsl - for example, allow_blank, non_zero. Also we can have types that aren’t ruby primitives, such as email, hostname or ip.
It does mean we can’t do (cheap) live corrections in the UI since translating blocks to Javascript is a complicated matter. It could be done via API calls, but that’s more expensive. Built in types would be good (email since there’s an email field in HTML, regex etc) but it certainly makes sense for complex validation that a block should be allowed.
Things I recall from earlier in non specific order:
Logging configuration done through settings (I don’t want to restart foreman to set debug log level)
Multiple value setting user experience (today, people need to type ruby array as the value)
Setting levels (basic, advanced, expert) so new users are not overwhelmed
Ability to confirm changing a value (e.g. agree to some terms&conditions when allowing feature X)
Some settings would benefit from markdown support (e.g. the welcome page text, users wanted to add hyperlinks to it)
Hiding internal settings (db seed pending, fix db cache)
Custom text in the modal window, e.g. showing examples, provides further help
Reset to default button (UX)
Schedule settings for e.g. tasks cleanup, reports cleanup, audits cleanup
Settings override per user
Settings override per organization
I realize this is more than you asked for and a lot of it is out of the scope for the DSL design, but perhaps some are useful. Let me know if I should elaborate more on some.
If we had such a component it would be useful in other places as well. I didn’t find anything matching it in patternfly, maybe @MariSvirik could help us design something and get that in? (not high prio but would be nice)
Those should be ideally dropped, or moved to ForemanInternal table if needed
not sure that theses make sense, user specific preferences should be stored on the user. do you have any example?
I agree, changing how we store this is valid implementation of “hiding”
I don’t care where they are stored, but some settings can be seen as a user preference. E.g.
General / Entries per page
General / show host power status
General / Show Experimental Labs
Provisioning / Clean up failed deployment
Provisioning / Destroy associated VM on host delete
Provisioning / Root password
Examples from plugins
Content / Autosearch
Content / Use ermote execution by default (will be dropped at some point)
Bootdisk / Allowed bootdisk types
ForemanTasks / Enable dynflow console
I’m not 100% sure on all of them, perhaps they should not be global settings in the first place. Perhaps some should be still implemented as settings but configurable per User or other entity, Org comes to mind first. I can imagine different Orgs have different preferences on custom fact for prefilling the default org/loc, various timeoutes, different default templates etc.
Nice, but we must make sure that setting lookup is very fast. No Rails cache, just a hash lookup. Logging is everywhere.
Good idea too.
This could be actually one of the levels (basic, advanced, developer).
You are brainstorming monster, I like this one. Maybe even 3rd (multiline) description (optional). We would allow plugin authors to extensively explain what is happening, like with HTML tags rendered in the dialog.
Smells like a lot of work tho. However we could add this field while not yet implementing it and warn authors about it. This could be implemented later on, maybe on User edit screen rather than on the Administer - Settings screen. Big change, out of Ondřej’s scope for sure.
Well I think these could be simply expert/developer mode, that would be a good solution to avoid cluttering the UX.
That was a rainstorm of ideas. Feel free to pick anything you like, Ondřej. You are writing the code after all
I’m not sure if I get exactly what you need. We could discuss it in a separate thread (google chat) in order not to spam this one with my non-technical questions
This PR reminded me of something we can do with the installer: generate a reference from the code. It would be great if we could do the same with settings.
Generating of the setting documentation would be great, we can do it today, but it will be much easier with the setting definition, as you won’t need database anymore.
As there is very little traction to the original PRs, I consider that as blocker for further improvements unless those improvements would force maintainers to touch the definitions again (as forced types would) and I did not hear any of those.
