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.
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.
Data Explorer can run arbitrary SQL queries which can be costly for us if over-used. Because of that we want to add the ability to rate limit the query run endpoint, in particular when requested programmatically using API.
This commit introduces a rate limit to the `QueryController#run` endpoint. It heavily leans on the existing `RateLimiter` implementation, and the ability of `ApplicationController` to turn rate limit exceptions into nicely formatted JSON responses.
The rate limit (per 10 seconds) can be configured through the global setting `max_data_explorer_api_reqs_per_10_seconds`, and defaults to 2.
Handling can be configured through `max_data_explorer_api_req_mode`, and can be set to warn, block, or both warn and block. We will default to warn for now and monitor the logs for a while.
This commit updates the plugin to the latest guidelines, as shown in
discourse-plugin-skeleton, which involves moving a lot of the code to
dedicated files, use proper namespaces, use the autoloader as much as
possible, etc.
* FIX: allow groups to access system queries (without having to run the query once first)
Bug is: Trying to allow a group to access a system query results in a Discourse::NotFound unless the query is run first.
Cause:
- System queries don't exist in the database by default
- update calls set_query before action
- set_query searches the database for the system query with Query.find_by(:id), which will not exist by default.
- running system queries first fixes this because Query.find is overridden to include system queries (Queries.default) in its results, avoiding the Discourse::NotFound.
Solution: use the overridden Query.find in set_query to include system queries in the search, instead of Query.find_by(:id)
* Added test for fixing allowing groups to access system query.
* Fixed test formatting.
Previously the `QUERY_RESULT_DEFAULT_LIMIT` const was used
to limit the number of query results. This commit adds the
`data_explorer_query_result_limit` site setting which defaults
to 1000 and has a max of 10000 which matches the const
`QUERY_RESULT_MAX_LIMIT`.
Previously this was adding an extra AJAX request to check if the group had any queries available. Now a boolean is included in the group serializer, so there is no need for the extra request.
Removing this ajax request will also stop other plugin JS integration tests from failing when the data-explorer plugin is installed.
This commit also fixes the HTML markup of the tab, so that it doesn't have a <ul> nested inside the existing <ul>. Also adds an icon for good measure.
Krzysztof Kotlarek