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

Here's a summary of my interpretation of the following roles in .LRN

- Members
- Limited Access User
- Limited Access Guest User

Members:
Users who have central approved access to the system (either due to having an approved mail address or being added by the site wide admin). A member has access to all user information and communication tools (forums) in communities and/or classes to which he/she is enrolled.

Limited Access User:
Users have the same rights as members but are added to the class by the class-admin (anything I am forgetting).

Limited Access Guest User
Users have rights only to access content in communities / classes but are not allowed to see communication and member information after added to a community / class.

My Question;
- Why can't a community admin add a "Limited Access user" like in a class (it is only possible to add a "Limited Access Guest User")?
- What are other differences between the roles above (this is important)?

Oliver

It's easier if you realize that  Guest and Limited Access as two separate independent settings.

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

Hi Caroline, hi Oliver,

I started searching for this "protect_private_p" parameter nearly one hour ago and did not find it. Could it be removed from the current dotLRN version?
I looked at dotlrn-members-portlet.tcl/.adp and noticed that three properties are created/used:
1. admin_p
2. spam_p
3. read_private_data_p

The last one is the interesting property. It is evaluated by using the function 'dotlrn::user_can_read_private_data_p'.
Having a closer look to the source code I saw that the 'protect_private_data_p' is a global parameter and not a parameter which could be set for each community.

So, my results:
In (my) current installation parameter 'protect_private_data_p' seems to be missing; the function uses the default value 1 instead. Therefore a limited access guest user can not see the list of members.
But even if the parameter was there, it would be used for all communities.

And telling community admins to create only limited access users will not work, too, because in the current dotLRN version, a community admin can not set up a limited access user, but only a limited access guest user. To change this, I could delete just one or two lines in the admin-adp-file, but I think, the programmers followed a special thought, when implementing this.

So, what to do best:
Either restore missing parameter 'protect_private_data_p' again, which would allow one setting for all communities, or giving community admins the possibility of creating limited access users?

Greetings,
Martin

Hi Martin,

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.

Martin,

at this point we should keep any changes in this area to an absolute minimum.

How about the following:

1. Make the descriptive texts for these two functions understandable on the class admin page so no one has to ask this kind of question again (we can use parts of Caroline's explanation above).

2. Fix the follow up pages where users are actually added (these need to be simplified and references to MIT and Sloan need to be removed).

2. Add the "Add a Limited Access User" text and link back to community admin page that sets read_private_date=t when adding a user (just cut and paste from the class page). By passing read_private_data_p=t to user-add in the URL a community admin can create a non-guest limited access user.

Example:
http://MY.DOTLRN.SERVER.EDU/dotlrn/clubs/tennisclub/user-add?type=student&can_browse_p=0&read_private_data_p=t

(this works on the test servers)

Carl

P.S. Just reported this bug: https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=515