Forum .LRN Q&A: Class / Communities AND Different Types of Users (Limited/Guest/etc.) Class / Communities AND Different Types of Users (Limited/Guest/etc.)

A Limited Access User can not add himself to a new class or community through the Manage Memberships page.

At Sloan this role is used for non-MIT students who are officially enrolled in a class.  For example a cross registered Harvard student. By US law they can have full access within that class (including seeing the class list) but can not see other classes.

A Guest is a non-student, for example an Alum or an Admit.  At Sloan they sometimes give them the right to join classes to "browse" them. But, by law, (The Buckley Amendment) they can not see the names of the students in the class.  Access to Forums is turned off just because it would have been too hard to remove the names from the posts (especially if you consider it might be in the body of a reply).

The law is an anti stalking law, the issue is if someone knows that someone else is in a specific class that meets at a specific place and time they might wait after class for them.  Please remember that is a very very barebones summary of the law which was not written with web in mind. Sloan's choices are based on the council of an MIT lawyer very familiar with the law.  Please don't try to second guess whether or not this would be effective. Believe me I've listened to plenty of that and at the end of the day its all about what MIT lawyers say needs to be done.

On the other hand, Sloan just one day realized that almost everyone seems to ends up being admin of some student group or something and decided they wanted to restrict Community Admin creating new users to Limited Access & Guest.  Note that subgroup admin can not add new members at all.

Note there is yet another privacy control.

In parameters there is "protect_private_data_p".  If this is set to 0 for a community this turns off the checking that keeps "Guests" from seeing people's names.  In other words for communities with "protect_private_data_p" = 0 there is no difference between a Guest and a non-Guest.

Sloan uses this for the Sloan Spouse's Club, and the new Admit communities where all the members are likely to be guests (non-MIT students) and it's important that they be able to see each other's names and know who is in the group.

The names of these controls are inherited from Sloan's jargon and the US laws Sloan must follow and MIT's interpretation of what following these laws implies.

In summary:

Limited Access = can't join another group even if its open.

Guest = can't see who else is in any group, even if they are member.

A specific user can be any of the 4 possible permeations.

Hope that helps,

Caroline

Thanks for pointing out that protect_private_data_p did not make it into dotLRN1.0, I hadn't realized that. Sorry.

It will be up to TAB as to which of solution is put into dotLRN.

For the short run, I actually recommend both. Perhaps with a parameter 'admin_can_create_only_guests_p' to toggle whether any individual class/community's admin can create non-guest users.  This seems like the sort of decision that is very likely to change from institution to institution and perhaps from group to group.

For the long run, (dotLRN 2.0 or beyond) it would be good to look at how as many institutions as possible have set up permissioning and new user creation privileges and rework the UI.  IMO, the current system suffers from not having Pind's Rule of 5 met.