duplicate patron checking in the user editor is limited to the workstation OU

Bug #1185524 reported by Chris Sharp
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned
2.3
Fix Released
Undecided
Unassigned
2.4
Fix Released
Undecided
Unassigned

Bug Description

It was recently discovered by a PINES library staff member that the current (since Evergreen 1.6/2009) user editor does not check for duplicate patrons beyond the boundaries of the workstation OU. PINES relies on consortium-wide checking to prevent patrons from opening duplicate accounts all over the state. In pre-1.6 versions of Evergreen, the user editor did this checking at the consortium level. My suggestion is that we add a YAOUS to control the depth of duplicate patron searching.

Evergreen 2.3.6
PostgreSQL 9.1.9
OpenSRF 2.1.2
Ubuntu 12.04

Tags: pullrequest
Kathy Lussier (klussier)
Changed in evergreen:
status: New → Confirmed
Revision history for this message
Kyle Tomita (tomitakyle) wrote :

I ran into this similar problem with KCLS. I fixed it by hard coding in the Consortium ID. My plan is to make it an actor.org_unit_setting to have a choice to use the consortium to search or not.

Changed in evergreen:
assignee: nobody → Kyle Tomita (tomitakyle)
Revision history for this message
Kyle Tomita (tomitakyle) wrote :

I pushed a branch, http://git.evergreen-ils.org/?p=working/Evergreen.git;a=log;h=refs/heads/user/catalystit/lp1185524-duplicate_patron_checking, that has my solution. I created a library setting to choose to use a search OU of the consortium or the workstation OU.

tags: added: pullrequest
Changed in evergreen:
assignee: Kyle Tomita (tomitakyle) → nobody
Revision history for this message
Mike Rylander (mrylander) wrote :

Unfortunately, you can't simply assume that the top of the org tree will have an ID of '1'.

Additionally, as coded, this will be useless for a significant set of existing Evergreen users where they want to check more broadly than a branch, but not everywhere. Instead of having an all-or-nothing choice, I recommend allowing the selection of an org unit depth as the YAOUS, and then use the existing org_unit_ancestor_at_depth() method available in OpenILS::Application::AppUtils to get the appropriate org unit id.

I feel relatively strongly about this, so I'm setting the bug to incomplete.

Changed in evergreen:
status: Confirmed → Incomplete
Revision history for this message
Kyle Tomita (tomitakyle) wrote :

Thanks Mike for the feedback. I will work on these changes.

tags: removed: pullrequest
Changed in evergreen:
assignee: nobody → Kyle Tomita (tomitakyle)
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Since the bug has been confirmed and is a valid bug report, I have returned this status to "Confirmed". I will look into whether this is something I can work on myself since Kyle's example points me to the relevant files. I agree with Mike on the implementation - hard-coding "1" wouldn't work for PINES either.

Changed in evergreen:
status: Incomplete → Confirmed
Revision history for this message
Lebbeous Fogle-Weekley (lebbeous) wrote :

Hi Chris,

You might want to test the top two commits from this branch. I think this adds Mike's suggested changes atop what Kyle offered.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/senator/lp1185524-duplicate_patron_checking

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

Thanks, Lebbeous. Also, good catch on the setting name and group. "circ" makes more sense than "opac" for sure.

Changed in evergreen:
assignee: Kyle Tomita (tomitakyle) → nobody
Revision history for this message
Lebbeous Fogle-Weekley (lebbeous) wrote :

Thanks again all. Pushed to master, rel_2_4 and rel_2_3.

Changed in evergreen:
milestone: none → 2.5.0-alpha2
status: Confirmed → Fix Committed
tags: added: pullrequest
Ben Shum (bshum)
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.