-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a registration backend that sends the form/submission variables as JSON to some API endpoint #4908
Comments
Plugin name did not make sense before
API endpoint is relative, name should reflect that
Will be easier to add new fields
Does 'optionally' mean that the configuration options should also include a checkbox (for example) with which you can select this? |
No - it's a wish to include this, but having the actual data is the minimum requirement for this ticket. Including the JSON Schema is desired, but not crucial and should likely be the final task of this ticket to implement :) |
Plugin name did not make sense before
API endpoint is relative, name should reflect that
Will be easier to add new fields
It should match the corresponding property of the serializer (which is 'service' and not 'service_select')
Not relevant anymore or duplicates
Wrong place and doesn't look great
…n plugin Need to include all form variables listed in the options to a values dictionary
The content of the attachment is now added to the result
Now includes a check on the generated values dictionary for easy testing
This is a requirement of the plugin
The user might want to send it to just the api root of the service
Makes more sense to keep static variables dict close to where it's used
The previous size was not big enough to show all elements without scroll bars
Required for simulating a receiving service
It is sufficient to only pass the relative endpoint to the .post method
This check if redundant, as the for loop will never be executed anyway if the query set is empty
It is closely related to the serializer
…pes only Only ORC type services are relevant for this plugin
"Any other fields that need special attention?": Not for the moment, all the fields are JSON serializable "Service type relevant?": Yes, but not here. In the serializer, it should only show the services of type ORC. The other ones are not relevant for this plugin "Does execute_unless_result_exists need to be used?": Not for this plugin. It is normally used in plugins where a lot of API calls are made, where it prevents objects from being created multiple times on retries (when one or multiple API calls had failed).
This will raise a KeyError if a form variable is not available in the submitted data nor in the static variables. This is better than passing is silently
…e service The instructions on how to start it is now in line with the other docker compose services
The configuration options could be saved without specifying any form variables to include. This does not make much sense. Added a minimum length of 1 for the form variables list in the serializer (Thanks to Robin for the hint)
There is a desire for a "simple" registration backend/plugin which just dumps the submission/form variables with their values as a "flat" JSON structure and sends this data to an API endpoint for further processing. The goal is to keep this super simple and light weight, and let the post-processing be done on the receiving end (with an enterprise service bus or other technologies).
Requirements
values
and (optional?)schema
is sentzgw_consumers.Service
)schema
keyExample
An example form with the following configuration:
firstName
andlastName
attachment
Should lead to a JSON object being sent with the shape:
Tasks
if settings.DEBUG
since I don't expect this to be done for 3.0Pointers
Existing code that can be useful:
The text was updated successfully, but these errors were encountered: