Stateless submit-button for login-less applications

[magnusjerre]

Description

We would like to provide our respondents with a login-less survey they can fill in and then submit their answer. Using the normal submit button requires an instance, but these respondents will be responding using the anonymous stateless functionality instead, hence no instance. This "stateless submit"-button should preferably include the contents of the model (not the formData representation). Upon clicking "stateless submit" a call to an overridable endpoint on the server should be made, followed by a navigation/redirect to a customizable receipt page.

Additional Information

We have a working POC where we have created a custom Web Component that makes an http-request to a custom endpoint on the server that handles the request, after which the frontend just redirects to the start of the survey. The initial idea was to include another layout page with the receipt, but we couldn't find a way to trigger a "next page" event in the frontend.

Our POC-implementation can be found here: https://altinn.studio/repos/udir/demodemoeleveundersokelsen Workflow:

1. The respondent goes to http://altinn3local.no/udir/demodemoelevundersokelsen?userid=d-mango-vann-1. This is a stateless part of the app (allowAnonymousOnStateless = true). By inspecting the query parameter "userid" the server requests an external service for information on which survey they should partake in and provides the correct resources to the frontend.
2. The respondent fills in their answers. On the last page of the survey, our custom Web Component for the "stateless submit button" binds all fields from the model to dataModelBindings (this gets quite large for many questions).
3. The respondent clicks the "stateless submit button" which then makes a request to our custom endpoint udir/demodemoeleveundersokelsen/api/stateless/submit. The backend then converts the datamodelBindings to our model and then makes a request to an external service. When the frontend receives a response, it redirects to the front page. Instead of redirecting to the front page it should preferably present a receipt instead.

Sample layoutelement illustrating why we would like the model to be sent instead of having to define/map datamodelBindings (this example is a summary, we can have more than 70 questions, this one includes only 9)

{
          "tagName": "stateless-submit-button-component",
          "id": "formlayout-uniqueid-23",
          "type": "Custom",
          "textResourceBindings": {},
          "dataModelBindings": {
            "surveyId": "SurveyId",
            "surveyExecutionId": "SurveyExecutionId",
            "schoolClass": "Metadata.Claims.SchoolClass",
            "yearLevel": "Metadata.Claims.YearLevel",
            "orgNumber": "Metadata.Claims.SchoolOrgNumber",
            "orgNumberOwner": "Metadata.Claims.SchoolOwnerOrgNumber",
            "q0id": "Questions[0].Id",
            "q0code": "Questions[0].QuestionCode",
            "q0ans": "Questions[0].Answer",
            "q1id": "Questions[1].Id",
            "q1code": "Questions[1].QuestionCode",
            "q1ans": "Questions[1].Answer",
            "q2id": "Questions[2].Id",
            "q2code": "Questions[2].QuestionCode",
            "q2ans": "Questions[2].Answer",
            "q3id": "Questions[3].Id",
            "q3code": "Questions[3].QuestionCode",
            "q3ans": "Questions[3].Answer",
            "q3ao0code": "Questions[3].MultipleChoiceOptions[0].Code",
            "q3ao0val": "Questions[3].MultipleChoiceOptions[0].Value",
            "q3ao1code": "Questions[3].MultipleChoiceOptions[1].Code",
            "q3ao1val": "Questions[3].MultipleChoiceOptions[1].Value",
            "q3ao2code": "Questions[3].MultipleChoiceOptions[2].Code",
            "q3ao2val": "Questions[3].MultipleChoiceOptions[2].Value",
            "q3ao3code": "Questions[3].MultipleChoiceOptions[3].Code",
            "q3ao3val": "Questions[3].MultipleChoiceOptions[3].Value",
            "q4id": "Questions[4].Id",
            "q4code": "Questions[4].QuestionCode",
            "q4ans": "Questions[4].Answer",
            "q4ao0code": "Questions[4].MultipleChoiceOptions[0].Code",
            "q4ao0val": "Questions[4].MultipleChoiceOptions[0].Value",
            "q4ao1code": "Questions[4].MultipleChoiceOptions[1].Code",
            "q4ao1val": "Questions[4].MultipleChoiceOptions[1].Value",
            "q4ao2code": "Questions[4].MultipleChoiceOptions[2].Code",
            "q4ao2val": "Questions[4].MultipleChoiceOptions[2].Value",
            "q4ao3code": "Questions[4].MultipleChoiceOptions[3].Code",
            "q4ao3val": "Questions[4].MultipleChoiceOptions[3].Value",
            "q5id": "Questions[5].Id",
            "q5code": "Questions[5].QuestionCode",
            "q5ans": "Questions[5].Answer",
            "q6id": "Questions[6].Id",
            "q6code": "Questions[6].QuestionCode",
            "q6ans": "Questions[6].Answer",
            "q7id": "Questions[7].Id",
            "q7code": "Questions[7].QuestionCode",
            "q7ans": "Questions[7].Answer",
            "q8id": "Questions[8].Id",
            "q8code": "Questions[8].QuestionCode",
            "q8ans": "Questions[8].Answer",
            "q9id": "Questions[9].Id",
            "q9code": "Questions[9].QuestionCode",
            "q9ans": "Questions[9].Answer"
          }
        }

[olemartinorg]

Moving this to app-frontend-react although it might require some implementation elsewhere as well. Instead of jerry-rigging some way to submit data from anonymous stateless apps to an endpoint we should probably look into supporting anonymous instances (and proper anonymous stateful apps). This could also make it possible to limit who can create new instances. It also follows the rest of our paradigm where completed instances are fetched from our APIs (PULL) rather than submitted somewhere (PUSH), as this feature-request describes.

[gnetrom]

Altinn App spesifikasjon Vi ønsker en APP som kan brukes som svar på en (uformell) høring.

Behov:

• Svar fra APP sendes som epost til: -- nasjonalarkitektur@digdir.no -- Avsenders epost/kontaktinformasjon

• Skjemadata kan enten serialiseres som ren tekst og/eller som Json. Hvis sendes som ren tekst må den ha en viss struktur slik at den kan importeres inn i f.eks Excel.

• Print/PDF-behov -- Ønsker primært at APP genererer PDF og at denne sendes som vedlegg til epost-mottagere. Hvis dette ikke er mulig - at avsender har mulighet til selv å printe ut hos seg selv.

• Kun Bokmål-støtte ...

• Kan vedlegge 1 dokument/fil hvis ønskelig

Følgende spørsmål og oppbygging av spørsmål/svar

• Tittel: "Beste Praksis - Arkitektur for hendelser i felles økosystem"

• Undertittel: "Vårt saksnummer: "23/46 Høring på beste praksis arkitektur for hendelser", (ikke-editerbart felt)

• Avsender informasjon -- "Navn", obligatorisk -- "Virksomhet", obligatorisk men preutfylt med "N/A" -- "Kontaktinformasjon/epost", obligatorisk

Hoveddel:

• Er behovene reelle og dekkende slik de er beskrevet i høringsnotatet? -- ja/nei + kommentarfelt
• Er det andre behov knyttet til utveksling av hendelser på tvers av virksomheter og sektorer? -- ja/nei + kommentarfelt
• Er begrepene godt nok forklart? -- ja/nei + kommentar
• Er mønstrene (hovedmønstre og delmønstre) relevante og godt nok forklart? -- ja/nei + kommentar
• Forslag til videreutvikling av en beste praksis Er det andre områder innenfor utveksling av hendelser på tvers av virksomheter og sektorer" vi må arbeide med videre? -- Kommentarfelt Har dere eksempler som er relevante? -- Kommentarfelt (mye tekst)