Dynamic input fields in prompt form

[jdcsplunk]

Is there an existing request for this feature?

• [X] I have searched the existing issues for this feature request and I know that duplicates will be closed

Is your feature request related to a problem?

Sometimes payloads or request resource identifiers can be extracted by using post scripts and those work great. Sometimes dynamic variables work for things that are not consequential. However, sometimes these features just don't cut it. It would be nice to have something that would prompt a user form upon clicking the send button to input variables.

Describe the solution you'd like

Let's suppose we have an api endpoint called GET v1/charts/{{id}}. It would be nice to have something like /charts/{{$formTextInput}} where post man would generate a form where the user could type the input.

Let's also suppose there is a post call named POST v1/charts where the payload is:

{
  "name": "my chart",
  "teams": [
      "teamId1",
      "teamId2"
   ],
   "dashboardId": "1234"
}

It would be nice to have a smart variable storage as options for future dynamic form directive inputs. For instance I would like to make two request calls as a precondition for creating my new chart resource because the chart payload needs an array of team ids and one dashboard id property.

GET v2/teams

{
   "results": ["teamid1", "teamid2"]
}

post script pm.environment.set("teamIds", body.results)

GET v2/dashboards

{
   "results": ["dbID1", "dbID2"]
}

post script pm.environment.set("dashboardIds", body.results)

Having these form options would allow us to have a post or put call where the payload for POST /v2/charts could be

{
    "name": "{{$formTextInput}}", <- no variable specified so it takes any arbitrary val
    "teams": "{{$formMultiSelectInput:teamIds}}", <- populates multi select input with team ids collected from teamIds
    "dashboardId": "{{$formDropdownInput:dashboardIds}}" <- populates a dropdown with dashboard id options collected from dashboardIds
     "expirty": {{$formDateTimeInput}} <- creates a datepicker with an option for date format string or epoch timestamp
}

Personally, I would have two options as I typically generate a sequence of steps for every folder that represents a resource set in my collection. I'd probably have a folder where I'd name charts and another called charts dynamic.

Describe alternatives you've considered

Creating a different request for every scenario which is not fun for adhoc testing.

Additional context

No response