Feature Wiki

Information about planned and released features

Tabs

Administration of Tests: Log Data Export Improvements

Page Overview

[Hide]

1 Initial Problem

The current admin section for test log data is not suitable to work with when it comes to big numbers of tests. The dropdown selection for tests becomes cluttered, loading times become exessive, admin feelings are hurt etc. Admins are not able to quickly search for a test, select it easily and export the test log data in a convenient way.

On top of that the concept of the Log Data Output is not logical. Admins are asked to limit the log data output by date while also selecting a test. There is no way of knowing if that combination will yield results. I.e. if the selected test actually has data logged for the specified timeframe.

Screenshot T&A Administration Log Data Output Page
Screenshot T&A Administration Log Data Output Page

2 Conceptual Summary

2.1 RFC 2119

In order to provide a clear understanding of the importance/relevance of a requirement we use the following keywords as described in RFC 2119:

  • MUST, MUST NOT
  • REQUIRED
  • SHALL, SHALL NOT
  • SHOULD, SHOULD NOT
  • RECOMMENDED
  • MAY
  • OPTIONAL

The subtabs Log Data Output and Log Data Administration are combined in just one subtab Log Data Administration. Admins must be able to quickly search/filter for test objects. After that, admins must be able to either export the log data for 1-n test objects or delete test log data for 1-n test objects via bulk action.

The following search/filter options MUST be given:

  • TITLE
  • OWNER

The following search/filter options are OPTIONAL:

  • REF-ID
  • REPOSITORY NODE (note: the repository picker is legacy code, KS does not offer a replacement as of yet)

Search/Filter results MUST be shown as a table, admins SHOULD be able to sort by colums. The table MUST offer a bulk action for export/deleting log data. Table columns MUST be as follows:

  • CHECKBOX for bulk action (export / delete log data)
  • TITLE
  • LOG ENTRIES (number of log entries)
  • OWNER
  • REFID
  • LOCATION (permanent link to the test object)

3 User Interface Modifications

3.1 List of Affected Views

  • ILIAS Administration / Repository and Objects / Test and Assessment / Log Data: Log Data Output
  • ILIAS Administration / Repository and Objects / Test and Assessment / Log Data: Log Data Administration

3.2 User Interface Details

3.2.1 Log Data Administration - Search/Filter for Tests (Mockup)

Mockup 1: Search/Filter for Log Data

3.2.2 Log Data Administration - Search/Filter Results (Mockup)

Mockup 2: Search/Filter Results for Log Data

3.3 New User Interface Concepts

None.

3.4 Accessibility Implications

No implications.

4 Technical Information

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Privacy

No additional / new data required for this request.

6 Security

No implications.

7 Contact

  • Author of the Request: Sesterhenn, Fabian [sesterhenn]
  • Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
  • Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

9 Discussion

Tödt, Alexandra [atoedt]: 29. Aug 2022:

  • This seems to be a filter even if the mock up calls it a search.  Please revisit the label "search". 
  • Please do not ask users to enter a ref-id. What about using a repository picker? This allows 
  • Why would the two distinct sub-tabs be merged? To me they seem to serve two very distinct purposes.

Sesterhenn, Fabian [sesterhenn], 14. Sep 2022:

The feature request was discussed in a first workshop on September, 13th 2022. See the full protocol for details. Key points:

  • One of the biggest hurdles with this FR is to come up with a good/usable UI. The use case contains 2 steps: a) searching/filtering for a specific test object, b) filtering/limiting the amount of log data to be exported by date. For the admin UI it seems to make sense to abandon b). This will reduce the complexity for the UI by a lot. We discussed that the export of log data would also make sense to be available at the test object itself. Here it would make sense to be able to only export parts of the log data, especially for tests that run for a long time. I.e. tutors need to be able to export test log data for the last semester for a test they are still using. Adding log data export to the test UI will be a separate FR.
  • A good KS element for searching for test might be Input -> Container -> Filter -> Standard.
  • We would like to rename "Protokolldaten" in german to "Log Daten" for the time being. Reason: Currently ILIAS speaks of log data in english, the german translation speaks of protocol data. Log data and protocol data are not the same. The current data discussed here falls into the former category. This would come with a separate FR.

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

  • {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.

Last edited: 14. Sep 2022, 13:41, Sesterhenn, Fabian [sesterhenn]