Interface to the TestArchiveCreator for Exports

1 Initial Problem

ILIAS already offers the plugin TestArchiveCreator which takes the questions and results of a specific test and exports them to .html and .pdf files. In order to be able to properly archive all test results we would like to create an interface between the examination protocol and the TestArchiveCreator (TAC).

2 Conceptual Summary

The aforementioned interface is supposed to allow the TestArchiveCreator to ask the Examination Protocol if it can offer data for the test-id that is about to be exported. If true -> the TAC also exports the data from the Examination Protocol.

The exact procedure would be the following:

1. Go to the export tab of the test
2. Click on the create button in order to generate an export for the TAC
3. The TAC creates an export and tells the ExaminationProtocol that it's supposed to create a new export, too. The newly generated export file (type html, name: examprotocol_<obj-id>_<timestamp>.html) is sent to the TAC. The TAC converts this file to a .pdf file
4. The TAC creates its usual zipped export and also includes the .html and .pdf file of the ExaminationProtocol

3 User Interface Modifications

3.1 List of Affected Views

• No screen will look differently since its kind of an implicit function.

3.2 User Interface Details

Screen 1. Current export screen of the test archive creator. These exports should contain the .html and .pdf files of the ExaminationProtocol if there is data.

Screen 2. Export screen of the ExaminationProtocol. If the TAC triggers an export a new export of the ExaminationProtocol is supposed to be generated, too, and put into the .zip file.

3.3 New User Interface Concepts

No new concepts.

3.4 Accessibility Implications

No aware of any.

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

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

6 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: Falkenstein, Rob [rob], Sven Slotosch
• Maintainer: Bischoff, Ulf [u.kunze], Neumann, Fred [fneumann] 
• Implementation of the feature is done by: Bischoff, Ulf [u.kunze], Neumann, Fred [fneumann] 

8 Funding

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

• …

9 Discussion

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}

Privacy

Information in privacy.md of component: updated on {date} by {user} | no change required

Approval

Approved at {date} by {user}.