The code for listing all of the defined queries is mixed together with the code for editing a single query. Notably, this results in large amounts of unnecessary data being loaded for the list view, which causes substantial rendering slowdowns.
To address this issue, we now only load the necessary data for the list view, and load the full data when it's actually needed (any endpoint that returns a single query). The primary changes that achieve this are:
- Create a new `QueryDetailsSerializer` serialiser, which includes all of the query info, and change the existing `QuerySerializer` serialiser to only include the necessary attributes of each query for generating a list of them all.
- Split the monolith `/plugins/explorer` route into `/plugins/explorer` for showing just the list of queries, and `/plugins/explorer/queries/:query_id`, for showing/editing/running a specific query.
When reading an existing state from the params defaults or from URL params, the input elements weren't representing the right state for booleans and "3-state/null booleans".
internal /t/-/118495
When checking `attach_csv` in the `Schedule a PM with Data Explorer results`
automation script, `csv` has to be added to the list of authorized extensions in the site settings. This will now raise an error if it's not the case.
Another private plugin is extending this plugin and the current_user check here is a problem -- adding safe navigation does not break any existing functionality but allows for future changes.
Followup da1c99ec2d
We already had the functionality to convert results like
this:
```
|blah_url|
|--------|
|3,https://test.com|
```
To a link clientside, so in the UI it looks like this:
```
<a href="https://test.com">3</a>
```
With the addition of the recurring report to post automation,
and the existing report to PM automation, we also need to be
able to do this server-side, so reports don't come out malformed
if they have these type of count + URL columns.
The primary key is usually a bigint column, but the foreign key columns
are usually of integer type. This can lead to issues when joining these
columns due to mismatched types and different value ranges.
This script is similar to the existing one that schedules
report results to to be sent to a PM on a regular basis,
but instead takes a topic ID and posts to that. This way
people can have report results sent to a public topic regularly
too and not have to deal with PM recipients and so on.