Feature Wiki
Tabs
Improvements of taxonomy assignments modal
Page Overview
[Hide]- On Hold because this needs the tree picker
- afterwards: topic of this FR will be to transfer the legacy content of the modal to KS
1 Initial Problem
To assign an object to a taxonomy node of a taxonomy originating in a parent category to an object, a modal is used:
The following problems with this modal were identified:
- The heading of the modal is missing.
- The title of the taxonomy is not given.
- The node fact is not communicated and lastly, not everything is directly expanded, which makes it difficult to work with the modal.
- After assigning taxonomy nodes in the modal, users must also click the Save button on the page Taxonomy Assignment. This obligatory step can be omitted.
2 Conceptual Summary
The Roundtrip Modal for Forms /Example 2 of the Kitchensink with a legacy tree picker is to be used.
- Modal title: Assign Taxonomy Node to [Title of Object]
- X / Close-Button
- Modal content: [Title of Taxonomie] and [Fully Expanded Tree of Taxonomy Nodes]
- [Save] Button instead of [Select]-Buttons
Up for discussion: Can the Taxonomy Assignment form actually live without a Save-Button?
The save button on the taxonomy assignment sub-tab is then no longer needed.
3 User Interface Modifications
3.1 List of Affected Views
- what ever object - metadata - taxonomy assignment - modal for assigning taxonomy nodes
3.2 User Interface Details
3.3 New User Interface Concepts
none
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 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: Seibt, Alina [alina.seibt]
- Maintainer: Killing, Alexander [alex]
- 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}
Approval
Approved at {date} by {user}.
Last edited: 1. Mar 2023, 10:45, Seibt, Alina [alina.seibt]