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

https://openacs.org/forums/message-view?message_id=156482

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.

Yes, it is .LRN-only.

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.

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 ...