Service Form Styling and Field Configuration #32

New issue

Open

opened 2025-03-27 07:52:33 +00:00 by tobru · 1 comment

tobru commented

2025-03-27 07:52:33 +00:00

Owner

Stories

As a user, I want to have a user-friendly form

Implementation Notes

Make fields configurable (override) - For example, hide a field or set a default value
Field grouping
Overall look and feel and usability

## Stories _As a user, I want to have a user-friendly form_ ## Implementation Notes - Make fields configurable (override) - For example, hide a field or set a default value - Field grouping - Overall look and feel and usability

tobru added this to the Servala Portal MVP milestone 2025-03-27 07:52:33 +00:00

tobru added the

enhancement

label 2025-03-27 07:52:33 +00:00

tobru added this to the Servala Portal project 2025-03-27 07:52:34 +00:00

rixx commented

2025-04-03 16:11:46 +00:00

Member

Field grouping was implemented as part of #31: Groups are derived from the spec structure, with any single fields in a group being put into an others category. Groups are tabbed, and sub-groups within those tabs (also as defined by the spec structure) are given headings. This means:

If a single field is nested A: B deep on its own, it will be labeled A: B: Field name, in the in order to provide the context for the field name.
If a field is nested A: B, but there are also other fields in A (but no other fields in B), it will be showin in the "A" tab with the label B: C: Field name
If a field is nested A: B together with other fields, it will be shown in tab A under section B with the label Field name

For configurability, we’ll need to define a JSON structure that can specify which fields will be hidden (not shown to the user, but sent to Kubernetes with their default values, if any); which fields will be removed completely; and which fields will have extra default values.

Field grouping was implemented as part of #31: Groups are derived from the spec structure, with any single fields in a group being put into an `others` category. Groups are tabbed, and sub-groups within those tabs (also as defined by the spec structure) are given headings. This means: - If a single field is nested `A: B` deep on its own, it will be labeled `A: B: Field name`, in the in order to provide the context for the field name. - If a field is nested `A: B`, but there are also other fields in `A` (but no other fields in `B`), it will be showin in the "A" tab with the label `B: C: Field name` - If a field is nested `A: B` together with other fields, it will be shown in tab `A` under section `B` with the label `Field name` For configurability, we’ll need to define a JSON structure that can specify which fields will be hidden (not shown to the user, but sent to Kubernetes with their default values, if any); which fields will be removed completely; and which fields will have extra default values.