Forum .LRN Q&A: Upcoming change in privacy/guest handling

Hi everyone,

This is a heads up, and a chance for me to make sure this is okay before doing a pretty large commit.

The HEAD of the dotlrn-2-0 branch currently has a bug where regular non-admin users can't view or post to forums.  A number of folks have run into this bug.  More here

The bug, itself a showstopper, also reveals some significant deficiencies .LRN's implementation of privacy protection.  After discussions with OpenACS OCT (many (most?) of whom also weigh in on .LRN technical matters) we decided that we ought to fix the problem at its root, and converged on a new design for privacy/guest handling.  That is what I'm getting ready to commit.

Some good news is that privacy/guest handling isn't very widely used yet, so the number of changed files is smaller than it would have been otherwise.  Some not-so-good news is that the number of changed files is still large (>30) and that there will be database updates.

This is going to affect folks who have deployed or are about to deploy on the 2.0 branch.  I can work with any such folks to write upgrade scripts if necessary.  This feels like a pretty big change to be doing on a branch, but we're trying to fix a showstopper bug and the alternative is a band-aid style fix which isn't very appealing either.

I should be ready to commit either tonight or early next week.  Please post a reply if you have an opinion or stake in this.  Thanks.

Posted by C. R. Oldham on

So this is a .LRN-only change?  You *did* post this to the .LRN forum, so it would imply that...


Posted by Andrew Grumet on
Yes, it is .LRN-only.
Posted by Carl Robert Blesius on
Thanks for your hard work on this Andrew.

The earlier you can commit the better (so we can test it).

We have been waiting for this fix before going public in Heidelberg.

Posted by Andrew Grumet on
Changes have been committed on the dotlrn-2-0 branch.  Files affected are in these packages: dotlrn, dotlrn-portlet, forums-portlet.  The packages were tagged with "pre-privacy-update" prior to committing.

The development was done against oracle.  Queries were ported to postgresql but have not been as carefully tested.

Also, there is one dependence outside of .LRN that should be resolved ASAP.  It concerns user imports in the acs-authentication module.  I haven't committed the change because it falls under OpenACS which is governed by a separate process.

The following patch should be applied to packages/acs-authentication/tcl/sync-procs.tcl:

RCS file: /cvsroot/openacs-4/packages/acs-authentication/tcl/sync-procs.tcl,v
retrieving revision 1.31
diff -u -r1.31 sync-procs.tcl
--- packages/acs-authentication/tcl/sync-procs.tcl  31 Oct 2003 10:29:19 -0000 1.31
+++ packages/acs-authentication/tcl/sync-procs.tcl  21 Feb 2004 02:38:02 -0000
@@ -415,9 +415,8 @@
                                    -can_browse=$can_browse_p \
                                    -user_id $user_id

-                                acs_privacy::set_user_read_private_data \
+                                dotlrn_privacy::set_user_is_non_guest \
                                    -user_id $user_id \
-                                    -object_id [dotlrn::get_package_id] \
                                    -value $read_private_data_p


Note that this patch adds .LRN-specific code into a non-dotlrn file.  However, the file already has dotlrn-specific code in the form of a call to dotlrn::user_add.  This is probably an area that needs cleaning up but we won't address it here.

Posted by Andrew Grumet on
I've just committed an Oracle upgrade script for the new privacy code, for systems upgrading to 2.0 from code older than February 20, 2004.  The file is


It's on the dotlrn-2-0 branch.  If you're already on the dotlrn-2-0 branch, you'll want to run this in SQL*Plus.  So far this has only been tested against a simple install, so I'd recommend practicing on a copy of your database first.

Posted by Don Baccus on
Can you communicate directly with Collaboraid on that dotLRN-specific snippet?  The auth code is theirs so I think you should run it by them to get it committed before we cut 5.0.3 which is VERY SOON (the plan is to bind .LRN 2.0 to OACS 5.0.3).

Later I'd like to see if we can come up with a clever way to avoid the dotlrn specific calls but we need to roll this out the door.  We could probably define a simple service contract and have the auth code call each implementation when a new user is added ... then write a .LRN implementation (plug-in) which for now would be the only one ...

Posted by Andrew Grumet on
Just sent email to Lars.