Patron-opt in bug

Bug #510959 reported by James Fournie
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Jason Etheridge

Bug Description

This bug affects the "patron opt-in" feature. This feature is set in the opensrf.xml. When active, libraries can only search for patrons from their home library. When a patron goes to a foreign library within Evergreen that is not their home library, they may present their home library card, and a dialog will appear asking for them to consent to sharing their personal information. If they consent, the staff client will continue to the circ screen, and that patron will henceforth appear in search results. As far as I know, SITKA is the only site making extensive use of this feature.

Last year, SITKA had some multi-branch sites, which pose an added layer to the problem -- patrons should not have to opt-in at a different branch of their home library system, and they should appear in search results at all of the branches of their home library system.

I have written a patch for this that uses an org-unit setting to determine two settings:
org.patron_opt_boundary - this determines at which depth above which patrons must be opted in, and below which patrons will be assumed to be opted in
org.patron_opt_default - this is the default depth at which a patron is opted in, it is calculated as an org unit relative to the current workstation.

So as an example:
Evergreen Library Consortium (depth 0)
 - Emotive Library Federation (depth 1)
   - Happyville Library System (depth 2)
     - Pleasant Branch (depth 3)
     - Joyous Branch (depth 3)
   - Sadville Library System (depth 2)
     - Miserable Branch (depth 3)
     - Grumpy Branch (depth 3)

Currently the code would work in such a way that a Pleasant patron would have to opt-in at Joyous. If they went to Joyous and forgot their card, the librarian would not be able to search for them by name.

With my patch, each org unit may set an opt-in boundary. Thus, Happyville would set an opt-in boundary of 2, meaning that Pleasant and Joyous would count as opted, but if you go above depth 2 and outside of the Happy Library Federation, you would have to opt-in.

The second setting is the default opt-in depth. So if a Joyous patron went to Miserable library and opted in, they still wouldn't be opted in at Grumpy branch even though both are part of the same municipality. Thus, Sadville would set a default opt-depth of 2 so that patrons are opted in at the system level.

This patch makes a major change to the patron search method. Currently, the patron search method is passed a depth value, and the search is conducted at libraries at a relative depth to the current authorized workstation. Instead, I have changed this method to require a specific org unit as an argument, and the search will be conducted at all of that org unit's children. This facilitates my patch, but also provides two benefits:
1. it allows for a situation whereby if an org unit had multiple children, one could search for patrons in one of the child org units
2. it makes it more useful as an API call

Anyway, that's all. SITKA is running this on production with no problems. It will probably only work in the 1.6 branches due to the overhaul of org unit settings in trunk.

Tags: privacy
Revision history for this message
James Fournie (jfournie) wrote :
Revision history for this message
Dan Scott (denials) wrote :

For what it's worth, Conifer uses opt-in.

I would call your patch an enhancement, rather than a bug fix, but either way the goal is laudable. That said, I have not yet reviewed / tested the patch.

Revision history for this message
Mike Rylander (mrylander) wrote :

Just an initial review, without testing. The first thing that jumped out at me was that the patch removes the cloned-users-with-shared-addresses check. I can see how users with shared addresses would want to individually opt-in, but I think we'll need to make that conditional on $strict_opt_in.

As a side note, in order to make direct patch review easier (since this one is fairly deep) would you mind producing a diff with -b and -B to ignore whitespace changes?

TIA,

--miker

Revision history for this message
James Fournie (jfournie) wrote :

Hi Mike,

The cloned-users thing was an oops on my part as I hastily created this after juggling various versions of this file as we upgraded from 1.2 to 1.6. I've removed that chunk

I've run this command to produce the attached:

svn diff --diff-cmd diff -x '-b -B' > opt_in2.patch

James Fournie (jfournie)
Changed in evergreen:
status: New → Confirmed
Changed in evergreen:
importance: Low → Wishlist
Revision history for this message
Jason Etheridge (phasefx) wrote :

2011-03-29T12:11:59 <dbs> Next: Jason Etheridge to review patron opt-in patch (https://bugs.launchpad.net/evergreen/+bug/510959) - any movement on that phasefx?
2011-03-29T12:12:08 <phasefx> I applied it to a local branch off of trunk, after adjusting for the perlmod path. Applies cleanly and doesn't seem to break anything when opt-in is set to false. Haven't tested things with opt-in set to true yet. I can do that, and/or just push to trunk/rel_2_1 as is and let others test. We still need to actually add the org unit settings it uses to org_setting_type table, as well
2011-03-29T12:13:16 <eeevil> phasefx: let's push into mainline with the ou setting type? I'd hate that to be forgotten ;)
2011-03-29T12:13:24 <dbs> Cool, can you add your results so far and the latter details to the bug?
2011-03-29T12:13:26 <dbs> or that :)
2011-03-29T12:13:45 <phasefx> sure, can make the branch public too
2011-03-29T12:14:04 <dbs> phasefx++
2011-03-29T12:14:17 <phasefx> sitka++
2011-03-29T12:14:36 <dbs> sitka++ indeed

http://git.esilibrary.com/?p=evergreen-equinox.git;a=shortlog;h=refs/heads/optin

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Revision history for this message
James Fournie (jfournie) wrote :

If it lends any credence to testing, Sitka has been using iterations of this code in 1.2, 1.6 and 2.0 in production since 2009

Revision history for this message
Jason Etheridge (phasefx) wrote :
Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
milestone: none → 2.2.0
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.