dotLRN programmatically prevents users from ending up in a class or community more than once, by omitting current members from the list of users who can be added to the group. However, we at Sloan have figured out how to get around this silly restriction. :) Start up one process moving a group of users from one class to another, and while it is running use another browser window to manually add admins, one of whom is also part of the group being moved. Works like a charm. :) Unfortunately the rest of the code assumes this will never happen, so this user cannot do some things, including dropping the extra membership.
The question is, can this be prevented? The code to add a user to a group does not appear to check to see if the user is already a member of the group before adding them, but I don't believe that would help in this case anyway. The bulk move of users is done within a transaction, so a check for the existance of the user in the group before the manual add would not see them until the transaction finished, and by then it would be too late. Adding this check would catch the case where the user was manually added before the bulk move got to her, but not the other way around.
If it was possible to put an actual uniqueness constraint on the table holding the relations then Oracle would take care of this, but the uniqueness dotLRN requires is too restrictive for the general case.
Suggestions? Is this even going to happen often enough to be worth worrying about?
