Randomly distribute a set of course / group members  to a set of groups

1 Initial Problem

Sometimes lecturers have to deal with large amount of students in a course and with large amounts of subgroups / tutorials / workgroups. Right now there is no way in ILIAS to distribute a given amount of members onto a given set of grous randomly and evenly. For exmaple, we have lecturers who whant to distribute 350 students onto 60 groups
 
I suggest implementing another Button / function on the members tab of courses and groups (next to "Edit",  "Remove" and "Send E-Mail") which reads "Distribute Randomly to Groups". When this function is called for a set of members the course / group admin should have the chance to select a set of groups on a user friedly screen (the default case will probably be that the target groups lie within the course / group --> these groups should be listed on top as a separate list with a "check all button, all other possible groups below them, similar to the limit membership procedure) by checking the respective checkboxes. In another step / or through radio buttons before the distribution, it should be possible to select on the next screen whether the users are supposed to be added as group members or admins, dependins on the didactic scenario of the course.
 
In addition, sort of nice to have, would be to have a numeric textfield (to get the desired number of groups - X) and a button reading "Create X groups and distribute users" which will create X groups and shove users evenly and randomly into these groups. However, this could be bypassed, if batch creation of groups was possible (similar to sessions).

2 Conceptual Summary

{Please add a brief summary on how you would like the problem to be solved.}

3 User Interface Modifications

3.1 List of Affected Views

{Please list 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, please provide a link to separate feature wiki entries for each of them according to the kitchen sink template.}

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

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

9 Status

• Scheduled for: Not scheduled yet (will be set by Jour Fixe)
• Funding: Required / Interest in funding partly Universität Freiburg
• Maintainer: (will be set by Jour Fixe)
• Implementation of the feature is done by (company, developer)
• Contract settled: No | Fill in "Yes" if a contract is already settled and add Institution / Organisation in "Funding" row
• Tested by / status: (name, e-mail), (status information set after implementation)

10 Additional Information

Contact the following persons if you want to know more about this feature, its implementation or funding:

• Information about concept: Marko Glaubitz, marko.glaubitz@rz.uni-freiburg.de
  
• Information about funding: (name, e-mail)
• Information about implementation: (name, e-mail)

11 Discussion

12 Implementation

...