Ga naar hoofdinhoud

Forms integration

Forms
forms
Provider stub

Link NC Forms responses to Open Register objects. Read-only response display plus 'link a form for future responses' flow. Provider stub today.

Group
Workflow
Required app
forms
Storage
Link table
Icon
ClipboardText

Surface NC Forms responses on an Open Register object. The Forms tab will show linked responses read-only; admins can also link a form so future responses auto-attach. Provider registers today; the wrapping FormResponseService + link table land in a follow-up.

Screenshot​

The integration registers in OpenRegister's in-page registry and renders as one of the tabs on the standalone integrations view. The tab is highlighted active here so you can see exactly which surface this leaf controls.

forms integration tab active in the OpenRegister integrations view

Captured by tests/e2e/leaf-screenshots.spec.ts against the seeded integration-verification register on the dev container. Empty state (Nothing linked yet) is expected on a freshly seeded object — link an upstream entity from the tab's + Add affordance to populate it.

What it will do​

  • Lists linked Forms responses on the Forms sidebar tab. Read-only.
  • Lets admins link a form so future submissions auto-attach to a target object (via a URL parameter or a hidden form field).
  • Renders a response-count summary on the detail-page widget.
  • Resolves a referenceType: 'forms' schema property to a single-entity chip with form title + response count.

Setup​

1. Install NC Forms​

Install the forms Nextcloud app. The Forms tab appears once it's enabled.

2. Use it on an object​

Open any object whose schema declares linkedTypes: ['forms']. The Forms tab appears. Today it renders the empty state until the wrapping service lands.

Configuration​

FieldOpen Register sideNC Forms side
Storagelink-table (openregister_form_links, pending)NC Forms own tables
Mappingform id, response id, object uuidForms REST API
RefreshPer render—
PermissionsInherits from object RBACForms' own ACL (response visibility)

Local verification setup​

The leaf-verification harness in tests/e2e/leaf-verification.spec.ts probes every advertised provider against the seeded integration-verification register; you can reproduce a single-leaf check by hand against any OpenRegister dev container.

1. Install the forms Nextcloud app​

docker exec -u www-data nextcloud php occ app:install forms
docker exec -u www-data nextcloud php occ app:enable forms
docker exec nextcloud apache2ctl graceful   # bust OPcache so the registry sees the new app

Without forms enabled, the forms provider reports enabled: false on the OCS capabilities payload and its sub-resource endpoint refuses to dispatch.

2. Probe the registry to confirm the provider is advertised​

curl -s -u admin:admin -H 'OCS-APIRequest: true' \
  http://localhost:8080/ocs/v2.php/cloud/capabilities?format=json \
  | jq '.ocs.data.capabilities.openregister.integrations.providers[] | select(.id == "forms")'

Expected payload — the enabled flag flips to true once the required app is installed.

3. Probe the per-object sub-resource​

curl -s -u admin:admin -H 'OCS-APIRequest: true' \
  "http://localhost:8080/index.php/apps/openregister/api/objects/21/166/25706ca9-c989-4d6b-9f7b-98cf1cc70639/integrations/forms"

Most recent harness run (against the seeded verification-probe object on this dev container):

  • Status: 200 (list-envelope)
  • Latency: 83ms
  • Body: matches the documented list envelope below
{
  "items": []
}

The OCS-APIRequest: true header is mandatory — without it, Nextcloud's session-CSRF guard short-circuits with HTTP 412 before the provider runs. An empty items: [] is the correct response for a freshly-seeded object that hasn't been linked to any upstream forms entity yet.

Current status​

Provider registered. Wrapping service + link table tracked under openspec/changes/integration-forms.