Service Form Styling and Usability #32

New issue

Closed

opened 2025-03-27 07:52:33 +00:00 by tobru · 2 comments

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
Support for "JSON field (array)" in the frontend - instead of a text field, add dynamic fields
Move first-level sub-groups into their own tabs (e.g. Backup), next level as title
Automatically generate spec.writeConnectionSecretToRef.name (must be unique in the org)
Skip a few fields hardcoded (see below)

Fields to skip

The following fields should not be displayed in the Portal:

spec.compositeDeletePolicy
spec.compositionRef
spec.compositionRevisionRef
spec.compositionRevisionSelector
spec.compositionSelector
spec.compositionUpdatePolicy
spec.parameters.scheduling
spec.parameters.security
spec.parameters.network.serviceType
spec.parameters.size.cpu
spec.parameters.size.memory
spec.parameters.size.requests.cpu
spec.parameters.size.requests.memory
spec.publishConnectionDetailsTo
spec.resourceRef
spec.writeConnectionSecretToRef

Note: Not all services have all fields!

## 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~~ - [x] Field grouping - [x] Support for "JSON field (array)" in the frontend - instead of a text field, add dynamic fields - [x] Move first-level sub-groups into their own tabs (e.g. Backup), next level as title - [x] Automatically generate `spec.writeConnectionSecretToRef.name` (must be unique in the org) - [x] Skip a few fields hardcoded (see below) ### Fields to skip The following fields should not be displayed in the Portal: ``` spec.compositeDeletePolicy spec.compositionRef spec.compositionRevisionRef spec.compositionRevisionSelector spec.compositionSelector spec.compositionUpdatePolicy spec.parameters.scheduling spec.parameters.security spec.parameters.network.serviceType spec.parameters.size.cpu spec.parameters.size.memory spec.parameters.size.requests.cpu spec.parameters.size.requests.memory spec.publishConnectionDetailsTo spec.resourceRef spec.writeConnectionSecretToRef ``` Note: Not all services have all fields!

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 Development Planning 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.

tobru removed this from the Servala Portal MVP milestone 2025-06-18 11:12:16 +00:00

tobru changed title from ~~Service Form Styling and Field Configuration~~ to Service Form Styling and Usability

2025-06-23 06:45:04 +00:00

tobru commented

2025-06-23 07:08:24 +00:00

Author

Owner

Let's skip field configuration in this issue and focus on some more (hardcoded) usability

tobru added this to the Servala Portal MVP milestone 2025-06-23 07:08:31 +00:00