Change student tu-id group

[akwick]

Within the old system the possibility exists to add students manually to a group - at least for our system. This possibility should exist in the new system, too.

Reason: Sometimes students which are allowed to order are not part of the correct group. If they contact the HRZ, they will receive the information that our system is working incorrectly.

[akwick]

Currently, I have two ideas for a solution:

• we extend our student model with an additional field containing whether we have verified this student manually. -> check for access has to be done on the groups provided through the HRZ and on our field
• operates on pyTUID in the sense that we can extend the groups directly in this field for our system.

If we save somehow the data provided by pyTUID and can ensure that the added groups are not overwritten, the second option should be the more elegant way to do handle this issue.

[Xiphoseer]

As far as I understand the situation, we will have the middleware give us access to TU-ID and group membership. We can then look up the TU-ID in our students model and create one if it does not exist but the group matches. Every TU-ID that is registered as a Student model is the considered logged in. This allows us to simply create a Student model object for anyone who has a TU-ID but for some reason is not assigned to the appropriate LDAP group. Furthermore, we could add BooleanField to any such student, registering the student as suspended or similar.

[Xiphoseer]

Currently, the system described above is implemented, we'd need to reconfigure the CAS to test the actual group membership key when turning a tuid_user into a student automatically.

[Xiphoseer]

Closed in favor of #31 and delegate issues.