Provide more options for how submitted form data is processed

[sabinebaer]

Q	A
Bug?	no
New Feature?	yes

Actual Behavior

At the moment form data is always stored in the database and only some email configuration can be done to decide what should happen if someone fills out the form.

Expected Behavior

A more flexibel way to define how submitted forms are processed would be nice. A possible solution could be that the whole email configuration is removed from the "General" tab and a new tab is added instead. The new tab should include the possibility to add as many "form processing" mechanisms as the user wants. The following types should be provided:

• Data storage: Define if the data should be stored in the database or not (I guess it would be good to have this option activated by default to avoid that form data is completely lost if someone does not think about this configuration).
• Email confirmation: Email confirmation for the user that fills out the form.
• Email notification: Send the form data to one or more recipients to notify them that someone filled out a form.
• API: Provide an input field for a URL where the data is posted to when someone fills out the form. TBD: How to generate the JSON needed for this?

It would be cool if it is really easy for a developer to add new types to use e.g. the API type in a flexible way (e.g. add a new "API with Basic Auth" type or a new API type that processes the form data before posting them to the given URL).

@thomasduenser & @Quehnie: Please add your thoughts and requirements.

[Quehnie]

We (aka Thomas) already build a solution for this.

With some cleanup and extension:
- Basic Auth for API
- FieldType extension for json key
- Flexible way for multiple APIs.

I think after this it would be ready for a RC version and a pull request.
For the email tab i would do a 2nd pull request.

[thomasduenser]

We've added a new tab to define a JSON API endpoint and the possibility to define which kind of security (e.g. Basic Auth) is used.

The expected behavior sounds very good to me, but it would be nice to have at least two possible security types (Basic Auth and Bearer Token) for the API type.

[alexander-schranz]

I think at the end the result should be you can define endpoints which will be then used where the data should be send to:

sulu_form:
   endpoints:
       my_endpoint:
            title: 'app.my_endpoint'
            method: 'PUT';
            uri: 'https://example.org';
            headers:
                 Authorization: 'Bearer Test';
       my_other_endpoint:
            title: 'app.my_other_endpoint'
            method: 'POST';
            uri: 'https://user:name@example.org';

The content manager itself should just have then an option via a Multi Checkbox or Multi Select which endpoints are activated for that form and the data will then be send to that endpoints depending on the checkboxes or not.

[thomasduenser]

Is "you" the developer?

That sounds good for many cases, but in our actual project it was a requirement that the content manager is able to select and define the authorization type of the JSON API endpoint for each form.

[alexander-schranz]

@thomasduenser I don't think that any Content Manager should get into contact with Autorization, JSON, API Keys or this kind of things.

At the end the content manager should just need to choose I want that data is always send to mailchimp, to sending blue, to my crm, ... The configuration for authentication should in my point of view always be done by a developer not by some content managers.