Do you have setting improvements ideas?

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.

First idea comming from @lzap:

  • Mandatory setting types, no more calculation from default value

Please share anything you think might be interesting to offer plugin maintainers in settings DSL, what could be useful, or was missing but never added

The current state of the DSL can be found in the DSL PR documentation and there is already one that is a must addition custom validation of settings.


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.

1 Like

Not a specific suggestion, but smart-proxy has a setting’s DSL that might be worth checking for some inspiration.

My ideas:

  • validations (you already started working on that - great)
  • proper Ruby typing (until now it’s pretty much derived from the default value which is ultra confusing)
  • setting evaluated via block (not stored in database - good for deprecating old stuff)
  • instance only setting (not shared between HA deployments - probably prefixed with instance UUID to make it unique)

I am just brainstorming, I think types are worth the effort tho.

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.

What’s the use case for this?

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” :slight_smile:

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.

1 Like

No use case on my mind other than foreman_uuid (is that supposed to be same across the cluster or not actually)?

I love this one!

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 :slight_smile:

1 Like

It certainly is. It identifies an installation, even if that’s spread over multiple machines behind a load balancer.

1 Like

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 :smiley:

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.

I’ve heard consensus on the types, and while other ideas are also great I don’t feel any of them would be hard to define in addition for plugin maintainers, I’m going just with the typing in my effort: Fixes #32894 - add types to Setting DSL by ezr-ondrej · Pull Request #8625 · theforeman/foreman · GitHub

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.

I’d very much appreciate if someone could take a look at the implementations.
I’ve opened a PR, where in the last commit you can take a look how this all would look like used for General category settings: Fixes #32893 - use setting DSL for General category by ezr-ondrej · Pull Request #8624 · theforeman/foreman · GitHub