Feature Wiki
Tabs
New Object: Individual Assessment Form Pool
Page Overview
[Hide]If you need any help in filling out this wiki page, please visit our ILIAS Community FAQ. And please complete the metadata information in the right column after having created the page.
1 Initial Problem
{ Please give a brief description of the problem you want to be solved. }
2 Conceptual Summary
Similar to the functionality provided by Test Question Pools or Survey Question Pools, the
Individual Assessment feature will also have a pool object, which will allow users to manage
forms and fields within these forms. There are two types of objects that can be managed:
- A field represents one potential input in a form. It is comprised of:
- a field type such as text input or date input
- a name that identifies the field
- an accompanying label that provides a concise overview of the intended input
for the field - a description that provides a more detailed explanation of the information that
examiners are expected to input into the field - an optional default value that may be used when the field is displayed initially
- an option to add supplementary notes in the form of a markdown input to the
field - an option to restrict content in the field which is available for examiners
- A form comprised of many fields, a name to identify it, and a description of its intended
usage.
A user with the requisite permissions is able to perform basic CRUD operations on fields and
forms. Fields are always referenced into forms. For example, if something in a field is changed,
it will be reflected in the forms that use the field. It is not possible to delete a field when it is
used in some form. When configuring an Individual Assessment, users can choose to use a form
from a pool where they have the necessary permissions. The form will then be copied into the
Individual Assessment. It cannot be modified in the Individual Assessment nor will it reflect
changes in the original form or fields in the pool.
2.1 Use Forms in Individual Assessment
When creating an Individual Assessment object, users have the option of selecting a form from
a designated pool, provided they have the necessary permissions.
Should a user opt not to create a form when initiating an Individual Assessment, the same
settings and fields will be presented in a record form as are currently available. However, the
two additional settings, "File/Results Visible to Participants", will not be included. Additionally,
the fields in the record form will be reordered slightly. The fields "Learning Progress" (formerly
"Grading") and "Publish and Freeze" (formerly "Finalize") will appear at the end of the form,
with all other fields appearing before.
Individual Assessment: Use in High Volume Scenarios 15.10.2024 Seite 8 von 10
When a user selects a form at the point of creation, the settings of the individual assessment
will comprise only the generic object settings (title, description, availability, etc.), with no
settings regarding the record. The description of the selected form will be used as the
'Assessment content description', and the record will contain the fields of the form as
configured. Only the two fields 'Learning Progress' and 'Publish and Freeze' will be added to the
form, with the same functionality as for the standard case without form.
- Form Field Type: Markdown
The form pool will provide a field type, "Markdown," which can be used to configure fields.
When displayed in a form, fields of that type will be represented by Markdown input fields.
Please note that fields of the Markdown type will not have the option to add additional notes
to the same field. - Form Field Type: File
The form pool will provide a field type, designated "File," which will be used to configure fields.
Fields of that type will be represented by "File Input Fields" when displayed in a form. - Form Field Type: DateTime
The form pool will provide a field type, "DateTime," which can be used to configure fields.
When displayed in a form, fields of that type will be represented by DateTime input fields. - Form Field Type: Single Select
The form pool will provide a field type, "Single Select," which can be used to configure fields.
When displayed in a form, fields of that type will be represented by Single Select Input Fields.
Additionally, fields of this type will have an additional configuration field, through which the
available options can be set. - Form Field Type: Tag
The form pool will provide a field type, "Tag," which can be used to configure fields. When
displayed in a form, fields of that type will be represented by Tag Input Fields. Additionally,
fields of this type will have an additional configuration field, through which the available
options can be set. - Form Field Type: Rating
The form pool will provide a field type, designated "Rating," which will be used to configure
fields. Fields of that type will be represented by "Rating Input Fields" when displayed in a form.
3 User Interface Modifications
3.1 List of Affected Views
- … { Please list titles of all views (screens) of ILIAS that should be modified, newly introduced or removed. }
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
{ Please list all personal data that will need to be stored or processed to implement this feature. For each data point, provide a short explanation of why it is necessary to use that data. You may consult the Privacy Clinic for questions regarding the legality, minimization, or appropiate use of personal data in compliance with applicable privacy regulations such as GDPR. }
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: {Please add your name.}
- 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
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}.
Last edited: 20. Nov 2024, 14:40, Haagen, Nils [nlz]