Forum .LRN Q&A: Public Portals in dotLRN

I may not fully understand, but if the problem is that the request processor is blocking access because the pages are within the package directory of non-publich package, then can't you just move the pages somewhere else, or hack the request processor to Do the Right Thing?

Hi Roberto

This was one of the first things we realised when we started looking at dotLRN - our solution (which is not ideal, but works part way) was to develop an auto-registration + membership facility, which can be linked to email patterns.

Basically it works like this - I added 3 parameters for the Main Site:

• AutoAddTodotLRN [0 or 1] (Automatically add users to a default dotLRN community?)
• AutoAddUseEmailPattern [0 or 1] (If AutoAddTodotLRN, then only emails matching dotLRN email pattern are AutoAdded)
• AutoAdddotLRNCommunityID [int] (If AutoAddTodotLRN, the ID of the dotLRN community that people who register will automatically join)

and hooked into the email patterns stuff already in dotLRN. I also amended the registration pages a bit, to do the checking and dotLRN membership bit.

I then created a community called the Open Community, and used it's community_id to set AutoAdddotLRNCommunityID.

So once I turned AutoAddTodotLRN on, I could have everyone who registered with the site automatically added to the Open Community, and I could restrict this by using email patterns if I didn't want everyone who registered to join automatically.

As I mentioned, it's not the same as having a public area (as it requires the user to register), but it's someway there.

Another possible solution, that ocurred to me as I write this, is to create a community (like my Open Community) to act as the public area, create a user (say, Guest, or Anonymous) who is a limited guest user (although if they are guest, they can't see forums, so you might want to hack that!) and hack the login to default to that user if no login data is entered. Again, not ideal, but a bit closer to the ideal maybe??

Just my quasi-random thoughts on the problem :)

<Raad>

Hi Roberto,

I  know exactly what your problem is, I don't have a solution but I can tell you the history of it and maybe that will help us get to a solution.

When dotLRN was delivered to Sloan last year I did a lot of bug fixing to get it ready for launch. One of the bugs was there was no membership check on any page that displayed community content except the portal. So if someone url hacked, or  if one user forwarded another a notification with urls linking directly to say a page in forums, that user was able to see the forum message even if they were not a member of that community.

Obviously this was unacceptable, and the obvious solution seemed to be to require community membership to read a class or any package mounted under it.

This fix lead to one immediate problem.  You could no longer use the register page of the community you wanted to join, because since you  weren't a member yet, you couldn't view it.  The simple fix to that was to pass the community_id to the register page of dotLRN package you were currently in rather then the one you wanted to join.

The second problem  I didn't find for 6 months when I tried to create public portals and found the same code Ben Bytheway found and ran into the same problem you did.  I don't see how the public portals can work with the permission set up currently on dotLRN.

One  thing you should be aware of is that the public portal code has never been used so even without the permissions settings it may not work.  You should coordinate with the people contemplating a portals rewrite and see if they are even planning on keeping it.

It's possible that an analogous solution to the register page might work. You might be able to set up the dotLRN pages to take a portal_id and then use the dotLRN package one level up to display the community's public portal.

I didn't try this because the problem I was trying to solve for Sloan was slightly different then what you are trying to do.  I wanted to replace the uninformative Security Violation page at any url within a community with a page customized for each community that gave a link to join that community if the user had permission to join (i.e. the community is open and the user is a full access user).  Thus if someone is following a link from a forwarded notification to a forum message of a community they are not a member of a useful and informative page is displayed.  I never found a way to do that without hacking the request processor and it was a "nice-to-have" feature not a requirement so it was never implemented.

Caroline,

Thanks a lot for posting this history and your thoughts. Please let's keep this flow of ideas coming through.

Re: Public portals, they have worked fine in our tests, but I haven't found the usual UI for editing the portal and adding new portlets. We've added portlets to it via Tcl or PL/pgSQL. The problem is as you describe: we had to give dotlrn_user read permissions on the whole community for a non-member to be able to view the non-member portal. But as a consequence s/he could see everything else in the community, which is not what we want.

I like your idea of passing the community_id up to be displayed by the portal of the community the user belongs to. I'll explore that.

Hmm, the feature you were trying to get working would be a really nice one to have indeed. Perhaps it can come out as a by-product of this discussion.

Thanks again.

-Roberto

.LRN is very user-centric, so it seems you'll have to mess with the user-id.

If you want to use the non-member portals, which is probably the way to go, you may look into adding a default-dotlrn-user with appropriate permissions and than redirect non-registered visitors and non-dotlrn-user using this default-dotlrn-user_id.

What happens if you add object_id 0 as a dotlrn_user (remember https://openacs.org/forums/message-view?message_id=107004)?

We actually hacked something up along these lines as a demo for Copenhagen University.

We looked at the public portal, but decided against using it, because it would require the group admin to maintain two portals. Whenever he adds a portlet or rearranges things, he'd have to do the same add/rearrange to the non-member portal.

Instead, what we did was make some changes to the permission structure, so that portlets actually check permissions on the relevant packages before displaying themselves. That way, you'll only see what you're allowed to see.

Here are a few links for you to try it out:

If you simply visit

http://nik.collaboraid.net

you'll see a list of publicly accessible courses.

You can browse those (currently 'that') course, and see whatever the admin has allowed you to see.

Then if you login with the 'admin' link from this page:

http://nik.collaboraid.net/register/

you can visit:

http://nik.collaboraid.net/dotlrn/classes/computerscience/computerandnetworksecurity/computerandnetworksecurityfall20032004/public-access

(also linked off of the class admin page), where you can define the public access of the group with the checkboxes and the 'make public' and 'make private' buttons.

Try it out.

The code can be downloaded here:

http://www.collaboraid.biz/developer/nik-packages.tgz

It hasn't been committed because it's a hack. It's a hack because we had zero time to do it, and because .LRN permissions are a hack in the first place.

But please do take a look, and if someone has the time and courage to clean it up and commit it (the tarball also contains a number of other interesting new features, such as easy access to archived courses, anonymous forums postings, etc.), then please go ahead.

/Lars

Aldert,

Re non-member portal ... As I mentioned, the problem is that the administrator has to maintain both portals in order for it to make sense.

Ideally, I'd like that choice to be up to the course admin, so he/she can choose which users get to see which portal, based on group memberships or permissions.

However, that's more work. So as it stands, I think it makes more sense to forget about the non-member portal for now.

I haven't thought about the calendar. Currently there's only the community calendar and a personal calendar. Are you thinking that there'd be a third non-member community calendar?

What would that be used for?

/Lars

Has anyone actually succeeded in putting this into .LRN so a non registered user (read: The Public) can access a file in the file-storage of a community?