Forum .LRN Q&A: what is the privilege structure of dotLRN?

What confuses me is that you can be guest *and* be a professor or staff at the university (or is the employment then at a different university?). What is the difference between guest and external - they sound like the same thing? I guess if Guest is relabled "Can View Private Class Info" then the structure starts to make sense to me. However with that interpretation, and with the definition of private information above, how does it make sense to be a professor and have "Can View Private Class Information" set to false if this has the consequense that you can't see member lists of your own class?

Are there any plans to build a dotLRN interface to customize the permissions of variuos user types and of the Access and Guest fields?

By private information, I mean all student/member contributions to a class: name, email address, forum contributions, shared files, email exchanges.  We does this by restricting access at the portlet level so that Guests cannot see the Members, Survey, Forums, Member List page, or receive emails.  They can see FAQs, Documents, Calendar, News, Info and Custom Portlets, Syllabus and the Staff List - any portlet that displays group info only.

But there is a hole that you pointed out: it is possible to be a Guest and an Administrator in the same group, which has a sneaky presentation: the user is still restricted from the seeing the portlets, but has access to the Control Panel.  We know this is not pretty or desirable, but for Sloan, guest admins are a near rare occurence.  More often than not, the exception is a Limited Access admin, which does adhere to the letter and spirit as I currently understand it.  What we need to do is prevent Guests from being made admins.  And now that you have reminded me of all this, besides entering as ticket for it, there's not much preventing me from asking that it be done on SloanSpace V2 (besides the time to do it).

As for Guest and External, the difference is that one is a Role and one is a Type.  Again, Types are not completely defined/designed.  Putting any user in a particular Type does not prevent them from filling any Role.  This renders the Type category virtually useless right now, but in the future, we want it to be useful, and provide a way to define constituency groups (including alumni) as a group and as having specific access (alums need that defined differently than students, etc.).  However, I am speaking off the cuff and I will certainly not be the one who codes this nor may I be the non-technologist who decides how this will ultimately work.  I just know what I think Sloan needs it to do for Sloan.  Caroline Meeks, Don Baccus, Andrew Grumet and I and others have had many lengthy conversations about this, and we expect to revisit the idea more than once in the future.

"Are there any plans to build a dotLRN interface to customize the permissions of various user types and of the Access and Guest fields?"

This is not on our immediate horizon, though it is always lurking in the background, smirking at us and rubbing its hands with evil glee, waiting for us to try and figure it out once and for all...

"So Guest is really a strange name for "Can view Data Contributed by users and data about users (user data for short)".

It's just the opposite.  Guest is a strange name for CANNOT view...

Though it does seem nonsensical and overly granular at face-value, we needed to err on the side of flexibility to satisfy users.  If someone makes a student a guest who can't see private data, they have made a mistake and I correct it for them.  We try to explain clearly what guest and limited access mean so that group admins use each appropriately, but occasionally, I do a little corrective intervention, which takes about 1 minute of my time.  However, we cannot have fixed types because there are two access levels for students, although I agree that there are ways to improve what we currently have.  As they are now, the Types are all the same for privileges (at least to me); the user does not see their "Type" and it is the user's access level that is important from a site wide perspective.

But yup, it's still more confusing than it ideally should be.

This is actually a specific example of a more general usability problem for many complex apps--namely defining roles and assigning permissions to those roles. As we're seeing here, roles can vary pretty dramatically from one organization to the next, depending on staffing, laws, and other factors. You have the same problem, for example, with content management, where authors, editors, reviewers, publishers, multimedia creators, etc., can vary widely in their responsibilities from one organization to the next.

To solve this problem more generally, I think you need a couple of pieces:

1. An intuitive interface that lets administrators define roles by assigning fairly granular permissions.
2. One or more default role sets that organizations can use to start with and then edit as they get a clearer understanding of their needs.
3. Some wizards to help administrators understand how their own situational needs translate into choices for role parameters.

dotLRN could be the prototypical application for OpenACS to work out these UI issues.

So we can work together as a community, I'm posting the use case I am programming to today.

Guest/read_private_data  use case:

Alumni Notes Community

In general we do not want to give alumni read_private_data privilege.
However in certain communities we (such as the alumni notes community) they need to be able to access forums so they do need read_private_data.
We do want alumni to be able to browse communities and classes so we can not make them Limited Access Users.

Proposed Short Term Solution:

Check read_private_data at the dotLRN level.  BUT let communities override it through a link on the control panel and give all members this privilege (probably by not checking it at all).

Do not let classes override. - Classes are covered by the Buckley amendment, Communities are not.  By default we give communities and classes the same protection, but we are not obligated to give communities this legal protection.