Introduction of Examination Protocol

This is the main article of the bwILIAS subproject ExaminiationProtocol.

1 Initial Problem

In the case of paper examinations, the obligatory examination protocol is usually also written on paper and later forwarded to the examination offices for storage with the other examination documents.
For digital examinations, it has so far been necessary to also write an examination protocol on paper. This leads to the dilemma that the examination itself is digital and the examination protocol must therefore be stored separately from it. Since many universities and colleges are now introducing digital student files to which examinations and tests can also be attached, it is a logical step to also keep digital examination protocols for digital examinations.

2 Conceptual Summary

A new tab must be developed for the test, via which the protocol is managed and displayed. In the run-up to the examination, the initial settings for the digital examination protocol are made via this tab. These include basic settings such as title, type of exam, type of supervision, allowed references and whether the exam takes place online or on-site. Furthermore, it should be possible to specify the names of the supervisors and the examination rooms. Since the supervisors do not always have to be members of the university, they are entered manually. The same applies to the examination rooms, as in this case there is no interface to the university's room allocation system. The examination participants should be able to be inserted via the search.
 The protocol should be exported via the TestArchiveCreator.

3 User Interface Modifications

3.1 List of Affected Views

New Tab:

General Settings:

Add supervisors:

Add locations:

Add participants:

Adding a new entry:

Protocol gradually filling up:

3.2 User Interface Details

{ For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour. }

3.3 New User Interface Concepts

{ If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this. }

3.4 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

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

• Students:
  • Name
  • Login
  • Matriculation-Number
• Supervisors
  • Name

As this is an examination protocol, all these data are legally necessary, as they have to be assigned to the respective examinees. The supervisors could use a pseudonym, but at least the person responsible for the exam must be named.

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: Slotosch, Sven [sven.slotosch]
  
• 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

• bwILIAS
• Universität Freiburg
• Universität Stuttgart

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}.