Hello,
does anybody know if there is a safe way to access the user settings during the installation process at the stage when the preinit script is called?
From the appcenter logs I see that an UCR for my app is created after the preinit script has been called, but I would like to read and modify the user-submitted settings earlier, i.e. I need to access them in the preinit script.
Where are these settings temporarily stored?
Boris
Hi @bheithecker,
yes I had a similar problem/observation in Why is preinst executed before the settings screen? (you also commented there). I feel like the only way to make this possible at the moment is to manually create ucr variables before the app installation.
Hi,
okay, I can create ucr variables before the installation, but I want to do so only in case the installation-user has not set the variable (i.e. if the setting is “optional” and was left empty).
Boris
Yes, this is not possible. The settings are not stored anywhere before the start of the App.
If you wish to use a default value for some setting, maybe it is possible to put this logic into the container (I assume you are talking about a Docker App)?
If you actually have UCR available in your container (i.e., your App uses appbox), you may use this in any script inside the container:
ucr set my/option?my_value_in_case_it_is_not_set_yet
Does this help?
Yes, I have to generate missing settings in a pre-boot script inside the consider. The probleme is that there may be conflicting user settings or user inputs which can’t be processed. For example, one setting is supposed to be a valid host name. If the user has made an invalid input, perhaps inadvertently, all I can do is exit the container with non-zero status code and no meaningful message to the user about why the start-up has failed.
Perhaps in some future UCS version there could be an option to provide a simple javascript for validation of user inputs right in the frontend.
Depending on the App, it may be possible to not stop immediately with a non-zero exit code. Maybe the App can (although incorrectly configured) live long enough to execute the setup script that any App may ship. If this script has a non-zero exit code, the App is removed, too.
The advantage is that setup also gets --error-file, which can be used to give the user a meaningful error message.
This is not as instant as a simple JS validation would be, yet it should work.