"unattended" setting value counter intuitive
You have to set
if you want to disable the unattended installs, which makes the following code look awkward:
# do not show these fields if unattended mode is disabled unless $settings[:unattended] ... end
Updated by Paul Kelly over 13 years ago
- Status changed from New to Resolved
The whole SETTINGS thing was a bit clunky so I have introduced a facility to read the settings.yaml file and then dynamically create a module with class methods matching the names. This means that:-
and I have added a query function for booleans so that
maps to both
NOTE that you should not try and assign to the query interface, (Foreman.setting?=value,) but should Foreman.setting=value
I also added support for cascading settings so that
- nodes : true # This will always be true if you want anything to work
- build : false # indicates whether we should also manage the build lifecycle?
This implementation requires that if you wish to use a setting you are required to declare it in the settings.yaml file. This is a good idea anyway as this is also documentation. If you want to use a default value in the code, unless you override this in the settings file, then set the value to false in settings.yam. The code then go
var = Foreman.setting || "hardcoded_default"
I have also updated the settings file to show the defaults from the program. (Where I can, and there is one.)
The code can be found at refactor/92 @ my github along with a replacement of all SETTINGS entries throughout the codebase.