Custom form configuration

rixx commented

2025-11-05 09:38:45 +00:00

Member

Forms can be configured in the admin
Fields used in custom forms are validated
Hard-coded fields that are always included
Create instances with custom forms
Update instances with custom forms
Merge data from custom forms into full instance data
Expert mode toggle

Generators are not included yet, as the FQDN field handling requires some hardcoding anyways (and we want it to always be loaded for the expert form, regardless), so I think we should wait with the generators implementation until we need one.

ref #165 - [x] Forms can be configured in the admin - [x] Fields used in custom forms are validated - [x] Hard-coded fields that are always included - [x] Create instances with custom forms - [x] Update instances with custom forms - [x] Merge data from custom forms into full instance data - [x] Expert mode toggle Generators are not included yet, as the FQDN field handling requires some hardcoding anyways (and we want it to always be loaded for the expert form, regardless), so I think we should wait with the generators implementation until we need one.

rixx added 13 commits 2025-11-05 09:38:46 +00:00

Remove Advanced Fields feature 880d10c5e5

we don't need it, as the new expert mode will be just the full current
form

Provide form building schema 1cf1947539

Remove expert fields, add form config 357e39b543

Generate custom service form from config 0045e532ee

Use custom forms in instance update cedcab85c4

Fix form display details 9e7330e24d

Make sure FQDN generation works with custom form 652e0798f4

Fix FQDN generation 63039171c1

Remove org field from generated form 2931315b96

Fix array widget container ID 7f99c78084

Implement instance creation from custom form

Tests / test (push) Successful in 28s

Details

aa77a10de2

Validate fields used in custom form config 5cc582b638

Code style

Tests / test (push) Successful in 26s

Details

a5d46b696f

rixx added 2 commits 2025-11-05 09:45:45 +00:00

Simplify form configuration, remove generators reference 59e7a75c51

Code style

Tests / test (push) Successful in 28s

Details

ca485978b9

tobru added the

UI/UX

label 2025-11-05 14:42:23 +00:00

tobru commented

2025-11-05 15:05:22 +00:00

Owner

Something is off with the migration:

❯ uv run src/manage.py migrate
CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0012_convert_user_info_to_array, 0013_add_form_config in core).
To fix them run 'python manage.py makemigrations --merge'

To unblock myself from testing, I executed (after creating a backup of my local db):

❯ uv run src/manage.py makemigrations --merge
Merging core
  Branch 0012_convert_user_info_to_array
    p Raw Python operation
  Branch 0013_add_form_config
    - Remove field advanced_fields from servicedefinition
    ~ Alter field name on organization
    + Add field form_config to servicedefinition

Merging will only work if the operations printed above do not conflict
with each other (working on different fields or models)
Should these migration branches be merged? [y/N] y

Created new merge migration /home/tobru/src/servala/portal/src/servala/core/migrations/0014_merge_20251105_1449.py
❯ uv run src/manage.py migrate
Operations to perform:
  Apply all migrations: account, admin, auditlog, auth, contenttypes, core, sessions, socialaccount
Running migrations:
  Applying core.0012_remove_advanced_fields... OK
  Applying core.0013_add_form_config... OK
  Applying core.0014_merge_20251105_1449... OK

After that, I could start with the testing.

Directly after this, navigating to e.g. /org/my-acme-7/services/redis/offering/1/ no form is shown anymore. I would have expected to see the same form as before because I didn't configure anything yet.

Trying to create a new form results in Invalid form configuration: None is not of type 'integer'. What am I doing wrong?

Either allow the fields to be empty or add some defaults.

And when filling in all fields: You must include a 'name' field in the custom form config.

EDIT: Got it, I must map to name, not metadata.name. I guess this is one of the fields that we need to hardcode.

Something is off with the migration: ``` ❯ uv run src/manage.py migrate CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0012_convert_user_info_to_array, 0013_add_form_config in core). To fix them run 'python manage.py makemigrations --merge' ``` To unblock myself from testing, I executed (after creating a backup of my local db): ``` ❯ uv run src/manage.py makemigrations --merge Merging core Branch 0012_convert_user_info_to_array p Raw Python operation Branch 0013_add_form_config - Remove field advanced_fields from servicedefinition ~ Alter field name on organization + Add field form_config to servicedefinition Merging will only work if the operations printed above do not conflict with each other (working on different fields or models) Should these migration branches be merged? [y/N] y Created new merge migration /home/tobru/src/servala/portal/src/servala/core/migrations/0014_merge_20251105_1449.py ❯ uv run src/manage.py migrate Operations to perform: Apply all migrations: account, admin, auditlog, auth, contenttypes, core, sessions, socialaccount Running migrations: Applying core.0012_remove_advanced_fields... OK Applying core.0013_add_form_config... OK Applying core.0014_merge_20251105_1449... OK ``` After that, I could start with the testing. Directly after this, navigating to e.g. `/org/my-acme-7/services/redis/offering/1/` no form is shown anymore. I would have expected to see the same form as before because I didn't configure anything yet. Trying to create a new form results in `Invalid form configuration: None is not of type 'integer'`. What am I doing wrong? ![Screenshot_20251105_160504.png](/attachments/7ac2dd5b-4a25-4b4d-a3c1-a22c4042a318) Either allow the fields to be empty or add some defaults. And when filling in all fields: ` You must include a 'name' field in the custom form config.` ![Screenshot_20251105_160830.png](/attachments/3b4fcd01-9e3f-4a62-8d5d-f682f66be538) EDIT: Got it, I must map to `name`, not `metadata.name`. I guess this is one of the fields that we need to hardcode.

Screenshot_20251105_160504.png

85 KiB

Screenshot_20251105_160830.png

85 KiB

tobru commented

2025-11-05 15:18:11 +00:00

Owner

Added a second fieldset, this somehow broke the view:

Added a second fieldset, this somehow broke the view: <video src="/attachments/4e076c8b-d64d-4c75-a312-af5b81c079e7" title="Screencast_20251105_161748.webm" controls></video>

Screencast_20251105_161748.webm

33 KiB

tobru commented

2025-11-05 15:23:27 +00:00

Owner

A choice field allowed me to enter custom values, but ended up showing the choices from the control plane:

When I enter choices in the form configuration, I'd expect these to be shown (and validated against the available choices in the control plane). When I don't enter choices, the current behavior makes sense to use the available values from the control plane. This way I can override the choices if I'd like to but keep it up to the control plane when I don't configure anything.

A choice field allowed me to enter custom values, but ended up showing the choices from the control plane: ![Screenshot_20251105_162019.png](/attachments/3f4f963a-37c9-456d-96f5-e763fe44a878) ![Screenshot_20251105_162104.png](/attachments/5d78d537-c60f-4062-9ff5-8901e45113ac) When I enter choices in the form configuration, I'd expect these to be shown (and validated against the available choices in the control plane). When I don't enter choices, the current behavior makes sense to use the available values from the control plane. This way I can override the choices if I'd like to but keep it up to the control plane when I don't configure anything.

Screenshot_20251105_162019.png

52 KiB

Screenshot_20251105_162104.png

18 KiB

tobru commented

2025-11-05 15:35:13 +00:00

Owner

On a number field, when setting "Min value" and "Max value" I'd expect the form field to only allow these numbers in the frontend with the up- and down controls. It allows all numbers. The validation works though, a number not in the range gets rejected.

tobru commented

2025-11-05 15:37:14 +00:00

Owner

I miss a setting to set a default value on the field.

rixx added 9 commits 2025-11-06 15:15:30 +00:00

Fix migration story 5b496ec5b2

Split up crd.py into module 9e1804a141

Fix missing form when no custom form is present 16d8ac0c6d

Add basic form generation tests 7fbd57d1b1

Make form_config integers optional 68dce4c5fb

Fix tabs on custom instance forms b3bb41b322

Fix custom choices not being used 089dbb663a

Fix missing number validators on custom form widgets bab9d636ee

Implement default values in custom forms

Tests / test (push) Successful in 28s

Details

ece60ad3b1

tobru commented

2025-11-07 07:58:51 +00:00

Owner

"Invalid form configuration: '64' is not of type 'integer', 'null'"

Make the "Show Expert Mode" button less prominent, in practice the expert mode should only be used in rare edge cases...

The attached field definition JSON formdef.json breaks the frontend with not enough values to unpack (expected 2, got 1) stacktrace.txt

"Invalid form configuration: '64' is not of type 'integer', 'null'" ![Screenshot_20251107_084828.png](/attachments/63701cb6-673c-4202-99bc-8fd96fc3f1e8) Make the "Show Expert Mode" button less prominent, in practice the expert mode should only be used in rare edge cases... The attached field definition JSON [formdef.json](/attachments/10f1ed3f-e35b-4112-9d9a-385460a5e3d2) breaks the frontend with `not enough values to unpack (expected 2, got 1)` [stacktrace.txt](/attachments/412d50a3-2285-45ed-8f3f-3a83acde1011)

Screenshot_20251107_084828.png

55 KiB

formdef.json

4.6 KiB

stacktrace.txt

14 KiB

rixx added 3 commits 2025-11-07 11:59:50 +00:00

Coerce string-numbers to numbers in admin form 1ed261d4b2

Implicitly fix admin choices configuration 6182b36daf

Make expert mode toggle less prominent

Tests / test (push) Successful in 28s

Details

985e4b47c0

tobru commented

2025-11-07 15:44:38 +00:00

Owner

For the record:

Fieldsets do not work correctly on the frontend yet
Missing: Hard-coded fields that are always included, like "name"
~~Missing: Configurable field validators~~ can be added later
~~Missing: Generators, for example, FQDN from name~~ already works as expected!

Additional requirement: Many services share the same fields. So that we don't have to copy/paste between services, predefined and reusable field definitions should be made available. When configuring the service form, allow choosing from pre-defined fields.

For the record: * Fieldsets do not work correctly on the frontend yet * Missing: Hard-coded fields that are always included, like "name" * ~~Missing: Configurable field validators~~ can be added later * ~~Missing: Generators, for example, FQDN from name~~ already works as expected! Additional requirement: Many services share the same fields. So that we don't have to copy/paste between services, predefined and reusable field definitions should be made available. When configuring the service form, allow choosing from pre-defined fields.

rixx added 4 commits 2025-11-10 13:05:03 +00:00

Make fqdn generator fail silently 228ab9bc0d

Add default config c7c22aa265

Make sure max length applies to textarea 7a8dc91afe

Add print debugging to tab setup

Tests / test (push) Successful in 29s

Details

9ac9f5e1c9

rixx added 1 commit 2025-11-10 13:15:32 +00:00

Fix tabs for custom fieldsets

Tests / test (push) Successful in 30s

Details