Red Hat Bugzilla – Bug 108124
The interative parameter prompt doesn't let user confirm / edit values before running
Last modified: 2014-12-01 18:13:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.9 (X11; Linux i686; U;) Gecko/20030314
Description of problem:
The interative parameter prompter run in the package loader doesn't let user
confirm / edit values they enter before running. For example, it prompts for the
admin email, name, password, etc, and if you make a typo you have no opportunity
to correct it, so you then have to drop & reload the entire DB.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Enter a typo for the admin email address
Actual Results: No opportunity to correct it
Expected Results: Confirm step lets you review & re-edit parameters before running
You can use the -defaults switch to pass in a file
with name=value pairs. Both ConfigTool (ccm-conf)
and PackageTool (ccm-pkg) take the -defaults switch.
for my.defaults to see an example.
What we will do for Oct 30 is, for WAF:
1. Prompt for all the database-persistent settings.
2. Prior to persisting in the database, present a summary screen for the user,
with all the user-input settings.
3. Allow the user to go back to the beginning or persist to the database.
Time permitting, we will also enable editing each item line-by-line.
We will not do this for anything other than Core (which should be okay, I think,
since the other app bootstraps do not persist stuff into the database). Let me
know if this is not the case.
This sounds reasonable. Line-by-line re-editing is an optimization that isn't
critical for Oct 30 given the number of parameters for core is a mere five.
> We will not do this for anything other than Core
Is the interactive reading really custom code to the Core loader ? Ultimately it
would be better if this were part of the general config parameter infrastructure
& thus automatically available to all apps loaders, but again not critical for
The functionality is not custom to core loader, but it will depend on removing
usage of the deprecated ScriptContext.getParameterLoader() for parameters that
require confirmation. This has already been done for CoreLoader, but not for
other Loaders, so we can't guarantee that other loaders will get confirmation.