Answers to plugin questions not rendered in the API

[thegcat]

Describe the bug
The REST API does not render answer data from questions added by plugins using the pretix.presale.signals.question_form_fields signal.

Expected behavior
Answers to questions added by plugins using the pretix.presale.signals.question_form_fields signal should be rendered alongside "core" questions in the API.

(This probably also applies to other exports such as the JSON export available from the Web UI)

[raphaelm]

This is – unfortunately – not really a bug. Plugin questions are not questions in any aspect other than that they are asked in the same place, technically it's a wildly different concept. pretix core has no idea what data types they include and what would be a good representation on the API, so we can't just output them.

Unfortunately, we have not yet found a great concept way to integrate plugins with the API other than plugins exposing their own endpoints.

Calling plugins in every API serialisation process would be horrible both for performance as well as for maintaining the compatibility guarantees of the API.

While I'd love to have a solution for this, I don't see one on the horizon other than you plugin exposing its own API endpoints.

[thegcat]

Well, from a conference organiser standpoint this is somewhat confusing. I can add a plugin that adds questions, can see the answer to said question on an individual order, but won't get the answer in neither the export options nor through the API.

Your suggestion would then mean that, again as a conference organiser, I would need to get my data from however many plugins I'm using and then somehow merge that again myself should I need the data in a consolidated way?

As a plugin developer, "here is a way to inject questions into the order process, here a way to save it" but "no, it doesn't work like other questions" is a little frustrating.

[thegcat]

Now, I spent the day thinking of the performance issue. I understand calling a plugin's signal (or the signals of multiple plugins) for each order or each position would add n SQL queries to each reading API call.

This could be batch processed by a plugin. Either pass the Order IDs or Positions IDs or Order or Position objects or maybe just a dictionary of IDs and question_form_data and ask for a dictionary of IDs and whatever data would be needed for the API response in return. Best of cases this would be no additional or one additional SQL query per plugin and one pass to prepare the data.

[thegcat]

Another way would be to add the ability for plugins to define questions added to the questions list, for which the plugin would maybe be able to verify the data, but everything else would use the builtin questions stuff. I understand this poses challenges too, but maybe they would be easier to manage.

[raphaelm]

Another way would be to add the ability for plugins to define questions added to the questions list, for which the plugin would maybe be able to verify the data, but everything else would use the builtin questions stuff. I understand this poses challenges too, but maybe they would be easier to manage.

That might be the best idea, but it will also have significant downsides as those questions then won't work properly in pretixPOS or pretixSCAN