Harmonize Approval and Waiting List Process in Courses/Group

1 Initial Problem

By now, the approval process and the waiting list process in courses do not harmonize very well:
Especially, there is one problem:

• Course has 1 free place with waiting list, and registration with approval
• 2 users make applications for membership,
  both join the list of applicants (not on the waiting list because so far no one has become a course member)
• User 1 is approved by the course admin, and becomes a course member;
  now user 2, however, does not change to the waiting list but remains in the list of applicants
• Now some user 3 registers for the course which is already full:
  This user joins the waiting list; now there are actually a waiting list and a list of applicants in PARALLEL!
• Finally, user 1 is removed from the course:
  User 3 moves up from the waiting list, while user 2 remains on the list of applicants

• an approval that is actually necessary can be bypassed via the waiting list
• users who are "stuck" on the list of applicants are overtaken

2 Conceptual Summary

To get rid of this conceptional weakness, we suggest the following solution for courses with approval and waiting list:

• The 'Join' page looks like with normal approval-protected courses, and so does the the situation after a user applied for the course; there is no clue of any waiting list by that time.
• Applying users then get on the list of applicants.
• When the course administrator (or tutor) approves an application, the user becomes a course member (until here, everything is state-of-the-art).
• Suggest there aren't any free places anymore in the course by that time:
  If now some additional user registers for the course, he/she should NOT get on the waiting list but on the list of applicants.

3 User Interface Modifications

3.1 List of Affected Views

• crs/members/crs_member_administration
• crs/join

3.2 User Interface Details

There should be an additional action for course administrators (and tutors) in the list of applicants: 'Set on waiting list'.
This would mean that the administrator generally approves someone's suitability for the course but doesn't abrogate the maximum number / waiting list mechanism.

3.3 New User Interface Concepts

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: Suittenpointner, Florian [suittenpointner]
• 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.

• FH Bielefeld Kaiser, Sascha [skaiser]

7 Discussion

Halm, Linda [lindahalm], FH Bielefeld, 28.2.16: We are also interessted in this feature, as we are working with wating lists very often within courses.

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