Feature Wiki

Information about planned and released features

Tabs

Alternatives for Repository Tree Picker for Container Operations Move, Copy, Link

1 Initial Problem

  • A campus management system creates 800 courses in a category, assigns course administrators. The category list is too long to be handled by a human and renders slowly. Thus the "view" permission is taken away for the global user role.
  • A university teacher has [user+course admin] and can read the course but not view the encompassing category. If he or she wants to move some content inside his or her course from top level "Content"-tab to a folder, he or she cannot do this: The tree part that would be needed is not displayed (no view permission) and thus the intended landing point cannot be selected. 
  • All copy / link / move actions are affected. 

Global Administrator or any other role with VIEW PErmission at category can copy
[User + course admin] cannot copy because her or she cannot see the category and thus cannot select target point

Users need to have an "unbroken" chain of "View" and "Read" permissions in the repository tree to be able to user the tree in copy / link / move operations.

If there is, for example, one category in the path to an object, to which a user only has "Read" but not "View" permission, even local operations (even within the context such as "copy a file inside a course from one folder to another") cannot be executed at all.

2 Conceptual Summary

Solution for "Adopt Content" in 5.4 
In 5.4 the "Adopt Content" action allows to copy / link / move even IF there is NO View permission for the upper container: In addition to the tree there is a "My Courses and Groups". 
In the tab "My Courses and Groups" all courses and groups at which the user has "Copy" permission are displayed.  From this course the objects can be copied. At no step the presentation of the tree is required. 

1. Step: Current Solution to move / copy / link WITHOUT View permission in upper container.
2. Step: context-free presentation
3. Step

Sugested solution: Generalise the "Adopt Content" approach to be used in List GUI actions, too
For copying / moving linking actions starting from ListGUI this approach taken, too:
The options for target / source selection in repository should be:

  1. "Tree" (exists)
  2. "My Courses and Groups" (so far only in "Adopt Content" and nowhere else)
  3. "This Context" (new) (or "This {Course / Group / Folder / Category / Learning Sequence}") -> Shows the content of the current object as a tree (repo picker)<sub/><sup/>
BUT: Modal for Picker is an obstacle
This situation is made more difficult by the suggestion to introduce a modal-based repository picker. We can exlude
  • tabs in modal
  • View control 
How can this be done?

3 User Interface Modifications

3.1 List of Affected Views

Target Selection:

Course (Action Menu) > Copy Course (Step 1/2)
Group (Action Menu) > Copy Group (Step 1/2)
Folder (Action Menu) > Copy Folder (Step 1/2)
Category (Action Menu) > Copy Category (Step 1/2)
Learning Sequence (Action Menu) > Copy Learning Sequence (Step 1/2)

Course (Action Menu) > Move Course (Step 1/2)
Group (Action Menu) > Move Group (Step 1/2)
Folder (Action Menu) > Move Folder (Step 1/2)
Category (Action Menu) > Move Category (Step 1/2)
Learning Sequence (Action Menu) > Copy Learning Sequence (Step 1/2)

basically any object in the repository:  ListGUI -> Action Menu of Object > {Move, Copy, Link}

Source Selection

{Course / Group / Folder / Category / Learning Sequence} > Content > Manage > Adopt Content > Step (1/2)
{Course / Group / Folder / Category / Learning Sequence} > Content > Manage > Copy > Step (1/2)
Add New Item  > Option 2: Copy { ~ } > Step (1/2)

3.2 User Interface Details

introduce two new tabs

3.3 New User Interface Concepts

none

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 Contact

  • Author of the Request: Glaubitz, Marko [mglaubitz]
  • 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.}

6 Funding

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

7 Discussion

8 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: 23. May 2019, 14:18, Tödt, Alexandra [atoedt]