Choice fields: Ability to select arbitrary default value(s)

[astro-stan]

The choice fields were added with PR #4822.

This discussion originated in #5045.

Problem:

Currently the choice fields do not allow an admin to (easily) select what the preselected value should be on stage load. This is because currently the preselected value is always the first item in the returned choice list from the prompt's placeholder.

While it is technically possible to rearrange the choice list dynamically on every stage load, it may not be as nice as being able to select an arbitrary default value. In addition, being able to specify more than one default value will allow the addition of a new field - multi-select.

Current implementation

The choice fields use the prompt's placeholder to enumerate all valid choices. The current behavior is as follows:

• Normal placeholder - specifies a single choice.
• Expression placeholder - specifies arbitrary number of choices by returning a python iterable (list, tuple, set). Default choice is the first returned item.

Examples:

Placeholder	Expression	Choice list	Default choice
Example string	❌	["Example string"]	"Example string"
return ["Example string", 1, True]	✔	["Example string", 1, True]	"Example string"

Implementation limitations

Currently, all prompt model fields serve a generic purpose and are applicable to all prompt types (with rare exceptions, such as a read-only field not able to be required). This makes adding new prompt-specific fields hard to justify.

Possible solutions

Currently I am not aware of any good solutions to this problem.

The only discussed solution so far has been to return a 2-tuple from the placeholder, where the first item is the choice list and the second is either the default choice or another list containing default choices.

Example:

Placeholder	Expression	Choice list	Default choice
return ["Str1", "Str2", "Str3"], "Str2"	✔	["Str1", "Str2", "Str3"]	"Str2"

This may seem a good idea at first, but there are a couple issues that need to be considered:

• User error:

  • It is easy to return a tuple with more than 2 items in it. This is should be considered undefined behavior and should result in an error.

  • It is easy to return a 2-tuple (lists/sets/single values are fine) with no default choice. This is an ambiguous behavior and should also result in an error. For example:

    # Could mean both:
    # - 2 choices
    # - 1 choice and 1 (invalid) default value
    return ("Example 1", "Example 2") 

• Complicated format:
  • More complicated than just returning a single iterable
  • Requires more validation
  • Not very intuitive

For these reasons I consider this implementation to not be a very good UX.

[astro-stan]

To address @sevmonster's last comment in the issue:

I understand you might not have or see a particular problem with the implementation, or might not want to write the code or implement it yourself. However, that doesn't change that there are clearly shown problems that are avoided or solved by utilizing a new approach. It is a common paradigm to use enumerations for data in lists for good reason, to avoid using a fixed string as a value. It's bad practice and puts more work on the admin.

:) :), it is not that I "have a problem" or "don't want to implement it myself". It is all about what is both:

• able to be generalized to serve a generic use case, and not only a specific use case you or a group of users have
• intuitive and easy to use

Please refrain from using such language as it is quite a turnoff for developers. No need to lecture you on how these features are being worked on for free and in the developer's own time.

or perhaps translate it to another language

Translation has never been in scope for this feature. Moreover, even if it was developed you are still left with the problem of being unable to translate:

• The prompt's label and help text
• The flow's title and name
• Probably other stuff I am currently forgetting

Thus, you will be forced to create language-specific flows, stages and prompts.

Even if you don't find an issue with it now, you and anyone else sure will in the future when all the policies and flows you've written that expect a certain string value need to be updated because you want to change how a specific choice is written

There are good coding practices that should prevent you from ending up in this situation, however, that is also out of scope here.

[astro-stan]

While I was re-reading your last comment in the issue I got an idea.

It would also be nice UX to allow a placeholder and provide an initial value since one may not always exist.

This might be able to kill 3 birds with 1 stone.

Adding a new "initial value" field will be applicable to all prompt types and will:

• Solve this:

  introduces an issue where if you open your user settings flow in the normal flow executor, you can't edit the placeholder text, and must retype any values you want

• Move the default value(s) selection from the placeholder to the initial value field. This will keep the whole choice field UX somewhat intuitive to the end user (as long as they understand that all choices are defined in the placeholder, while the default choices are defined in the "initial value" field)
• Allow for the addition of a multi-select field

I need to sleep on this and see if it still makes sense in the morning.