Just to be clear - you want the survey to explicitly want to pass in a extra_var of type "list"?

That is correct.
Currently you have to pass a list like so ['foo','bar']. Instead of like foo, bar or foo bar

Current as it stands you have a text field, but if you want to pass a list it has to be yml format. It would would be nice if the survey had an option like typelist instead of text that would construct your item as a list instead one single var. Hope that makes sense.

Hi,
In the same way it could be useful to have a boolean type. Actually booleans are passed at string type and we need to cast variable in ansible job.

Also note 'volatile password option', #1274

Additional type - 'File':

Semantics:
have a 'file' survey type
this uses a file upload widget in the survey taker
the uploaded file is stored as a base64-encoded extra var in the specified variable

This needs to set appropriate limits to not DoS the system.

Is this issue worked on ? We too would need the boolean type

The implications of not having a boolean type are quite significant - we can't use any existing bool variables in Surveys that otherwise work completely fine via other common Ansible var handling methods. E.g., if I build an AWX Workflow from playbooks that use some variables and a boolean one among them - I can place all those variables into the Workflow's Survey - except for the boolean one. So, I need to build an intermediate step in the beginning of the Workflow just to initiate and inject the boolean value into the process. With the way Ansible handles variables vs. facts and the variables priority - if I accidentally do put the boolean var into the Survey as-is, I'm setting myself up for a huge trouble as this String value silently "overrides" any handling of the normal boolean flow, which I won't catch unless I explicitly test both true and false scenarios. Lots of lost time and frustration.

Is there any progress on this? I am also in need of a boolean survey type. Having to cast a string to a boolean is error prone. A checkbox would also be a better UI than a "true"/"false" dropdown.

Uploading files(FileType in Survey) is one of must haves for AWX, since other automation engines(i.e. Jenkins) allow to do this.

Have the same request. I would need to upload file to the survey, I'm now doing a 2 step flow (first upload a file via SFTP manually, and then request in the survey the url from that file). Would be great to have all integrated in the same survey. If not we would need to create a parallel website to upload files and execute the playbook via api.

On top of boolean which is highly desirable, it would be a nice to have a Regular Expression type so we can validate specific patterns directly from the user inputs (eg: IP Address).

from #3149:

Additional type: datetime
Chooser: a calendar + time picker
Result: iso8601 extended datetime, in UTC.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

• UI

SUMMARY

Feature request to add a listtype option in tower survey to correctly parse a list that you pass for a variable. As it stands now you have to pass a list in yml format and for user experience it would be nice if you could pass a list just comma separated or how you do it when you specify a --limit

ENVIRONMENT

• AWX version: 3.2
• AWX install method: Linxus
• Ansible version: lastest
• Operating System: RHEL 7
• Web Browser: Chrome

STEPS TO REPRODUCE

No steps needed as it's a feature request.

EXPECTED RESULTS

ACTUAL RESULTS

ADDITIONAL INFORMATION

You can do something like this in your role/playbook to convert a comma or space delimited string into a simple (flat) list:

in the survey:
foo,bar,baz

playbook/role:
with_items: "{{ variable.split(',') }}"

However, I do not know if this would work with a list of lists, IE: item.pass=foo, item.username=bar, item.thing=baz. that's where I am at the moment and I'm trying to figure out a way to pass a list with multiple items through a survey into a role and execute a loop via with_items

In my case devs need boolean and list to manage their tests CI/CD environment without passing variables each time. I kindly ask the contributors to increase priority of this issue.

+1 for boolean type

1,581 days later... still no bool

I too would love to see a boolean type variable available in Surveys. I'm currently figuring out the best work-around for it and having a native bool type would be very helpful.

I too would love to see a boolean type variable available in Surveys. I'm currently figuring out the best work-around for it and having a native bool type would be very helpful.

survey_input: 'true'
all_yml_var: "{{ survey_input | bool }}"

You can use multiple choice with 'true' and 'false' as possible choices. Note, the quotes are not necessary, the values are always read as strings. Then in all.yml or role/defaults/main.yml or similar, you can read that answer (survey_input above) with the bool filter to become a true boolean variable (all_yml_var above).

+1 for bool in surveys

You can use multiple choice with 'true' and 'false' as possible choices. Note, the quotes are not necessary, the values are always read as strings. Then in all.yml or role/defaults/main.yml or similar, you can read that answer (survey_input above) with the bool filter to become a true boolean variable (all_yml_var above).

That is a bad idea by my experience as described in the 2.8 Porting Guide:

Beginning in version 2.8, Ansible will warn if a module expects a string, but a non-string value is passed and automatically converted to a string. This highlights potential problems where, for example, a yes or true (parsed as truish boolean value) would be converted to the string 'True', or where a version number 1.10 (parsed as float value) would be converted to '1.1'. Such conversions can result in unexpected behavior depending on context.

This behavior can be changed to be an error or to be ignored by setting the ANSIBLE_STRING_CONVERSION_ACTION environment variable, or by setting the string_conversion_action configuration in the defaults section of ansible.cfg.

And further on:

Ultimately, when: 'string' will always evaluate as True and when: not 'string' will always evaluate as False, as long as 'string' is not empty, even if the value of 'string' itself looks like a boolean. For users with playbooks that depend on the old behavior, we added a config setting that preserves it. You can use the ANSIBLE_CONDITIONAL_BARE_VARS environment variable or conditional_bare_variables in the defaults section of ansible.cfg to select the behavior you want on your control node. The default setting is true, which preserves the old behavior. Set the config value or environment variable to false to start using the new option.

Depending on the use case the author can cause involuntary problems. From my perspective to avoid any confusing problems by converting types, it's better to have a native booleans that will be passed to the play.

@Decstasy I don't think the solution that I provided is ideal, but I don't think that it's the same as what is referenced in your first quote. I believe that is referring to actually using 'true' (string) in your play and not what I suggested, which is casting a string to a boolean data type. It's also provided as an example in Ansible docs: https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#forcing-the-data-type

Any update or Road Map for this project?

Boolean true/false yes/no is a basic concept of Ansible. Im curious why there isnt movement on this or priority? what does everyone else to do get around this? Having to do the below seems asinine to get around this oversight.

      set_fact:
        some_var: "{{ true if some_var == 'True' else false }}"

@satellite-no, use bool filter instead
https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#forcing-the-data-type

@climardo thank you! good call that's much more elegant!

I also upvote this, especially the boolean support... Cannot believe that since 2017 instead of implementing some simple stuff everything got packed into one huge issue, that noone wants to touch.
BTW currently dealing with booleans using:

vars:
  variable: "{{ variable_survey | d('No') == 'Yes' }}"

And using multiple items single select with Yes and No values in survey. Benefit is, that you can use other text values as well, however this is still a bit messy as it requires to prepare playbooks especially for this survey stuff. A single checkbox would be way better.

I'd really love a way to upload files in a survey as well - a vars file in YAML or JSON specifically though other files would be very useful, too - even if the contents is just read by AWX and then can be either turned into a file with code or whatever.

To me, the boolean type would be nice but it's dead easy to code around.