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.
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
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.