Als gemeente wil ik product-gegevens voor-invullen in een formulier

[joeribekker]

Thema / Theme

Plugins

Omschrijving / Description

Aanname: De klant heeft een specifiek product afgenomen bij de gemeente en wil deze wijzigen, verlengen of annuleren (allemaal acties).

1. Er wordt een formulier gemaakt, specifiek voor "acties" op dat product (technisch: object in de Objecten API). Het formulier kan omgaan met het product. Dat wil zeggen, het weet welke informatie in het product zit en wat het daarvan moet tonen en/of doorzetten naar een achterliggend systeem bij inzenden. Technisch wordt dit gedaan door formulier variabelen expliciet te koppelen aan attributen uit het Objecttype van het betreffende product.

2. Een taak of een mijn-omgeving bevat een link naar een formulier om "de actie" uit te voeren. De link bevat een "product identificatie code" waarmee het formulier weet over welk product het gaat.

3. Het formulier wordt gestart middels DigiD of e-Herkenning, waardoor de klant is geïdentificeerd. Er vind controle plaats of de klant het product mag wijzigen *.

4. Het formulier haalt de productgegevens op uit de Objecten API en vult de formulier velden die gekoppeld zijn aan attributen uit het opgehaalde product.

5. Als dat veld ook weer gekoppeld is aan een registratie-attribuut, komt het ook weer mee in het achterliggende systeem. **

* De controle of een product wel echt van die klant is, kan plaatsvinden door het BSN uit DigiD te controleren met een specifiek BSN attribuut dat in het product zit. Dit lijkt ons een vereiste!
Additioneel zouden we ook een encrypted code kunnen sturen maar dan moeten Open Formulieren en degene die de link (met de "product identificatie code") stuurt, beide op de hoogte zijn van een shared secret.

** Jan Verbeek heeft aangegeven dat het portaal alvast een "object" aanmaakt. Wij dienen dat object uit te lezen (t.b.v. stap 1) en te overschrijven (dus geen nieuw object aan te maken - wat mij betreft een optionele feature).

Added value / Toegevoegde waarde

Op deze manier kan een gemeente een specifiek product tonen in een formulier, en is het duidelijk waar een inzending van een formulier over gaat. Dit kan gebruikt worden voor het verlengen of wijzigen van een product.

Aanvullende opmerkingen / Additional context

Inschatting: 6 weken

Tasks:

• Add query parameter to pass reference to existing object and send this to the backend on submissionCreate #4397
• Add a flag on Objects API registration to update existing objects instead of creating new ones #4395
• Create a prefill plugin to prefill with values from an external reference (initially only for Objects API) #4396
• Make sure prefill object is updated when the owner changes values #4721
• Add validation to the Objects API prefill plugin to check if the user is the owner of the object #4398
• Implement prefill configuration modal (StoryBook only) #4608
• Product prefill configuration modal: integrate with backend #4693
• Allow the SDK to handle 403 permission denied responses for the Submission create endpoint if the Object does not belong to the user #4399

[joeribekker]

Refinement: Please make a proposal on how to do this in detail, on a functional level! And then add technical tasks to be divided.

[stevenbal]

@joeribekker @sergei-maertens I discussed briefly with @vaszig and we do have some questions, but this is my attempt at describing the flow in more detail. I'm not sure if what I'm describing here makes sense, because I'm not 100% sure how certain aspects like FormVariables and service fetch work currently. Let me know if this makes any sense.

1. There is some form aanvraag-bijwerken that has the Objects API as its registration backend, linked to an objectType.
   • This form has several fields that correspond with attributes on objects of the specified objectType.
   • This form should also have some flag enabled to indicate that it's supposed to work with existing objects, instead of creating new objects (like a registration backend would normally do), I think this could be a flag on the Objects API registration options
2. The portal includes this form aanvraag-bijwerken and uses a query parameter to pass the ID of this object to the SDK
   • this ID should be passed to the backend -> we could add it as a queryparameter to the loginUrl that the SDK constructs
3. The user logs in with DigiD
   • after the user is logged in, the auth plugin's handle_return has access to this ID via the request and it has access to the BSN, there could be some kind of post-authentication permission check that passes the request and the value of the auth attribute. I'm not sure where the actual call should be defined though, maybe we could construct the URL of the Object and store it in a form variable and then use service fetch to fetch it and perform the comparison between the bsn in the Object and the bsn the user logged in with
4. Use prefill with the same service fetch operation as in the previous step to prefill the data of the Object
   • I don't know how generic this has to be, but maybe there could be a new prefill option that simply prefills based on the existing registration in the registration backend, using the URL stored in step 3
5. After the user modifies some values and saves the form, it should essentially do the same as a normal registration except instead of creating a new Object, it should do a PUT or PATCH on the URL that was saved to a form variable in step 3

[joeribekker]

As long as we don't actually need to use service fetch, then it's ok

[sergei-maertens]

yeah, roughly this is getting there, there are just some issues where existing concepts are being overloaded/mis-used and we really should keep different modules from OF loosely coupled, so...

• I see this looking-up-data-and-prefill-it as an extension of our existing openforms.prefill module. IMO it's just another plugin, requiring a bunch of configuration. At first, we will only support Objects API.
• Joeri and I discussed during the estimate that there should be a "synchronize/populate from registration configuration" - so while we will store the mappings for prefill and registration separately, we can use the information of registration to cut down on boring mapping configuration in the UI with this simple button. This would also be used if the object type definition changes - just re-sync the mapping
• I don't think that appending the lookup-information (querystring) to the login URL makes a lot of sense, the only thing that login URLs do is set up session data for when the submission starts. I think we can just stick to the URL query param approach and have the SDK extract that and send the information on the submission create API call. Then all the information is available for the prefill to kick off and look up the data, validate the object ownership (since we are now authenticated) and can build on the existing prefill mechanism.

There is some additional configuration required either way - you need to know the object type (and thus the objects/objecttypes API (group) being used) to be able to set up the prefill mapping, I think this can go in our "advanced settings" form designer tab which only activates if there are certain configurations/features used in a form.

I like the idea of storing the looked up object in a (static) form variable - could be useful to display bits of information in a content component and it would probably work well with the prefill configuration/mechanism. Maybe it could even be a user-defined variable you need to set up yourself and then organize the prefill configuration for it 🤔 which would bring our UI more in line with the future design:

+-----------+----------+----------------+---------------------+-----------------+
| Variable  |   Type   |   Prefill      |     Registration    |  Default value  |
+-----------+----------+----------------+---------------------+-----------------+
| permitXY  | Object   |    configure   |     n/a             | `{}`            |
+-----------+----------+----------------+---------------------+-----------------+


# Clicking configure opens the modal


+---------------------------------------------------------+
| PREFILL CONFIGURATION                                   |
|                                                         |
|             ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍                          |
| Plugin:    |  Objects API    ▼ |                        |
|             ﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉                          |
|             ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍                          |
| API Group: | Default         ▼ |                        |
|             ﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉                          |
|             ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍   ﹍﹍﹍﹍﹍        |
| Copy from: | Objects Registration  ▼ | |  COPY  |       |
|             ﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉   ﹉﹉﹉﹉﹉        |
|                                                         |
| Mappings                                                |
| ﹉﹉﹉﹉﹉                                                |
|   ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍       ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍      |
|  |  Form var 1   ▼ | <-- |  car > licensePlate  ▼ |     |
|   ﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉       ﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉      |
|   ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍       ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍      |
|  |  Form var 7   ▼ | <-- |  address > street    ▼ |     |
|   ﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉       ﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉      |
+---------------------------------------------------------+

(oh and I'm okay with programmatically using service fetch under the hood, as long as it's not exposed to the form designers!)

edit: discussed the specifics of this modal more with Steven - I didn't take into account that only the relevant config should be shown for each variable row instead of the full pre-fill configuration. We'll find a pragmatic approach to this.

[joeribekker]

Refinement: Steven will add concrete tasks, that might be converted to separate issues. The general idea seems clear.

[stevenbal]

@joeribekker I created tasks and separate issues for them as well

[sergei-maertens]

This is now completed and ready for testing/gathering feedback