Improve filtering of test reports
Closed this issue · 13 comments
Background and Motivation
Currently test reports are sorted by date. In some cases have more different types of sorting could be useful.
This issue is related to etf-validator/etf-webapp#88.
Proposed change
Add possibility to sort test reports by conformance class and by category. The "categories" would be the headers of the group of tests such as "Basic tests" or "Metadata".
Alternatives
- Add a drop-down list to Test Report view where you can select the sorting.
- Develop a controller to sort the test reports.
Funding
TBD
The main issue is that it is difficult to find "your" test report in the list of test reports, because their names are all very similar (almost all users use the pre-defined title). This could be solved by changing the default naming scheme, e.g. including only the name of the test object (e.g. filename or abbreviated URL), the test object type (metadata records, WFS, ...) and the date.
In addition, the placeholder test in the filter box could be changed to "Filter by title, conformance class, test object type, filename, URL, etc." to indicate that the filter searches all these fields.
In addition, we could allow the user to specify a "tag" when launching a test run (e.g. "jrc" or "germany"). This tag could be appended to the test report label, e.g. as "[jrc] <name of test report>".
To do:
- Check with the INSPIRE community these functionalities
- Produce some mockups to support the discussion
Some improvements that can be made on the UI are the following.
- Add personalized labels to the TestRun
- Filter the test reports by date, labels, test suites used or name
Check with the INSPIRE community these functionalities
Following discussion with the members of MIWP Action 2017.4 (see here), it was agreed that this functionality (illustrated by the screenshots above) is very useful and has high priority for implementation.
Following the comments from the MIWP Action 2017.4, we added a mockup for including the label on the name of the test run. This way, all the tests can be easily identified at glance.
As for the technical aspects, this improvements requires both frontend and backend developments. In the frontend part, we need to add the support for this feature in the StartTestView.js dialog for the label input form; and the test-reports.html to show the filters and the labels appended to the TestRun name.
In the backend, we need to alter the StartTestRunRequest class to get the label parameter from the diaglog; and the TestRunDto to store the new field.
We foresee that the components involved in this improvement would be:
- FrontEnd, for rendering the dialogs and filters
- API, to pass the necessary data on the creation requests of test runs
- Core, to accommodate the data access objects and data transfer objects. Also, to hold the data transformers to generate the XMl representation of test runs.
Couldn't we just represent the labels (tags?) as arguments via the API and in the data model?
As @cportele proposed, using the arguments key would make easier the development of this EIP. This way, from a processes perspective, the workflow is unaltered. There would only be necessary developments on the frontend for the StartTestRun dialog, to add the labels input and insert them on the request to the API; and then on the test reports view add the input for filtering and the logic to check the TestRun object.
To be discussed in the SG: how are the valid arguments defined, and how can we add the "label" as an additional valid argument? We could not find anything about this in the API or developer documentation.
Parameters are defined in the ETS. See for example, https://github.com/inspire-eu-validation/ets-repository/blob/master/data-encoding/inspire-gml/ets-inspire-gml-bsxets.xml, where currently two parameters are defined.
This could be extended in all the INSPIRE ETSs. For example:
<ParameterList name="Parameters for INSPIRE Validator">
<parameter name="files_to_test" required="true">
<defaultValue>.*</defaultValue>
<description ref="TR.filesToTest"/>
<allowedValues>.*</allowedValues>
<type>string</type>
</parameter>
<parameter name="tests_to_execute" required="false">
<defaultValue>.*</defaultValue>
<description ref="TR.testsToExecute"/>
<allowedValues>.*</allowedValues>
<type>string</type>
</parameter>
<parameter name="tags" required="false">
<description ref="TR.tags"/>
<allowedValues>(tag1|tag2|tag3|tag4)(,(tag1|tag2|tag3|tag4))*</allowedValues>
<type>string</type>
</parameter>
<parameter name="other_parameter" required="false">
<defaultValue>some default</defaultValue>
<description ref="TR.otherParameter"/>
<allowedValues>.*</allowedValues>
<type>string</type>
</parameter>
</ParameterList>For the schema, see https://resources.etf-validator.net/schema/v2/basic/basicTypes.xsd
When starting a test run, the values are passed as arguments. For example:
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ \
"label": "My label", \
"executableTestSuiteIds": [ \
"EIDd6b7c42f-f8f4-4f78-8a34-5c1fbc25bfc6", \
"EIDf8d086f5-ef88-4fdf-9d82-4bfe5b18fbc2" \
], \
"arguments": { \
"files_to_test": ".*", \
"tests_to_execute": ".*", \
"tag": "tag1,tag3", \
"other_parameter": "some value" \
}, \
"testObject": { \
"id": "EID6e8eb718-be48-4cfe-9d1d-9985f119eddd" \
} \
}' 'https://validator.example.com/etf-webapp/v2/TestRuns'
Updating the development of this EIP, we have added the parameter for adding the tags on the TestRun, and then we render it on the TestReports view to use as a filter. Right now, the filter implemented on this page is based on the filter in jQuery mobile framework, and it simply parses the input and search for occurrences in every string present on the list. So, being the tags rendered in the list, the filter can use them as well.
However, we are still trying to modify the filters to add the date filter and the TestSuite filter. The jQuery Mobile filter is kinda rigid, so we are trying to add the filters overriding the framework, using the input events directly and modifying the DOM through JS.
The new UI of the INSPIRE Reference Validator allows to filter test reports based on different filters, e.g. the type of resource, the status of the test run, and the test label.
Therefore, unless there are different views, we suggest to close it.