The idea for this object was derived from the discussion of the (now deprecated) idea of a
Test Overview object originally described in the following way:
We imagine the test overview as a repository object, ie. an object under "normal" RBAC control that can be created anywhere in the repository and that would in our originating scenario usually only be made available as a tool for lecturers, not learners.
The main goal is to make accumulating test results from multiple tests in arbitrary locations a lot more convenient. These test should be configurable in the test overview object; RBAC should be applied in the usual way, ie. a lecturer can only select his own tests/tests he or she has access to for inclusion in the overview. (The test overview should not be "hierarchical" object that has to "contain" the test it accumulates like a folder or category.)
The overview itself should present a table matrix of users (rows), test (end) results (percentages; columns) and a final mean value column. The matrix fields should have different background colors for passed (green), not passed (red) and perhaps not finished (yellow) retaining white for no results (yet).
If possible the test names in the column headers should be links to those tests and the test results should be links to the detailed test results of the current user in the current test.
For tests that do not themselves reside inside groups or courses it should be possible to be able to specify groups/courses as kind of "filters" for the learners to be shown in the matrix.
The lastly the test overview should offer an accumulated export of its included tests (not just of the accumulated results).
(Just a vague idea for future development and a note for further reference: The possibility to define a kind "balanced column" from selected values/criteria in the matrix (in addition to a "simple" mean value); input on that is welcome.)
The scope should now be widened to a (potentially) more general (and expandable) overview object, that could (in a future incarnation) collect information from e.g. exercises, courses, groups etc. and might even be tied appropriately into the learning progress.
Universität Stuttgart might be able to finance a first version (for ILIAS 4.3) with the "core" functionality described above (but with the explicit conceptional requirement that the object's can can be expanded in the future).
CB 2012-03-18: It looks like the "basic" version could be done by Databay, either as core object or plugin; we're definitely aiming for sustainability, though, that can't be stressed enough. Conceptual expandability (on code level) to other objects doesn't seem to be a problem, as far as we understood Michael Jansen correctly. I also like to point out the community response even to an overview object that (for now) just covers tests was very positive on the DevConf at Erlangen. ;)
JF 2 May 2012: We currently see the concept not being ready for the trunk. Beside the discussion of a general approach for different object types, we see a major need to discuss the way how access to reporting data is managed, especially when information of other objects are collected.
Example:
- Test A in Course A
- Test B in Course B
- "Overview Object" C adds Test A and Test B
Now users having access to C can view learner data of course A, even if they have no permission in course A. The current RBAC concept is not able to handle access to user related data, if this data is viewed outside of a single context (e.g. a course) or on a global level (administration).
The managment of access to reporting data may need other concepts, which means it could be a bad idea to implement this feature as a repository object.
This topic cannot be handled in the JF, but requires a dedicated workshop or a SIG reporting.
