Support editable enum dropdowns when values are pre‑filled via ContextViewer or API
complete
F
Fairy tale Canidae
Problem Statement
Today, when form fields in IDP (Backstage/Jarvis forms) are pre-filled using ContextViewer / formContext data from API responses, any field defined as an enum (dropdown) is rendered as a read‑only text input, not as a selectable dropdown.
As a result:
Users can see the previously saved value
But cannot change it using a dropdown
They must manually type values, which leads to errors and poor UX
This behavior occurs even when:
The field is explicitly defined as an enum
The API response value matches one of the enum options
Current Limitation
ContextViewer + enum fields do not work together
Once a value is injected via form context:
Dropdown UI is lost
Field becomes a static input
Setting defaults via API or context overrides enum behavior entirely
Log In
Rashmi Hegde
updated the status to
complete
Rashmi Hegde
We now preserve the enum drop downs and keep them editable when retrived from Contextviewer through API as well.
F
Fairy tale Canidae
Desired Behavior
Fields defined as enums must retain dropdown behavior
When a value is pre-filled from API/context:
That value should be pre‑selected in the dropdown
Users should be able to change the selection
Dropdown options should remain constrained to the enum list (no free-text typing)
Example Use Cases
OS selection (Linux / Windows)
Load balancer type (ALB / NLB / None)
Runtime selection (Java / Node / Python)
Boolean options exposed as dropdowns (true / false)
Business Impact
Critical for editing existing configurations
Prevents user input errors
Improves adoption of IDP for real production workflows
Removes the need for fragile workarounds (duplicate fields, read-only + editable combos)
Priority
High – This blocks correct editing of existing infrastructure configurations.