Bug 4945 - Patron search is limited by default to the currently logged-in library
Summary: Patron search is limited by default to the currently logged-in library
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Kyle M Hall
QA Contact: Bugs List
URL: /cgi-bin/koha/members/members-home.pl
Depends on:
Blocks: 6253
  Show dependency treegraph
Reported: 2010-07-06 18:56 UTC by Owen Leonard
Modified: 2014-12-07 20:03 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:

Proposed fix (4.66 KB, patch)
2010-08-20 15:50 UTC, Owen Leonard
Details | Diff | Splinter Review
Alternative patch with new preference (6.32 KB, patch)
2011-02-24 10:31 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Leonard 2010-07-06 18:56:35 UTC
The patron search form includes an option to limit by library which is hidden by default, and by default it selects the library at which the current user is logged in. This behavior is undesirable because there is no visual indication that the search is being limited. If the form field his hidden by default, it should also default to "Any."
Comment 1 Jane Wagner 2010-07-06 19:01:03 UTC
If Independent Branches are on, then it should limit by library.  Otherwise, I think you should get the choice.  Maybe in the search line, add another pulldown for library?
Comment 2 Owen Leonard 2010-07-06 19:04:22 UTC
There is another pulldown for library. It's hidden by default along with the patron category option. You can display them by clicking the [+]. The library selector should default the current library only if IndependantBranches is on.
Comment 3 Owen Leonard 2010-08-12 20:03:10 UTC
I'd really like to see this bug get fixed before the release of 3.2. As it is this patron search is going to appear to be completely inaccurate to my librarians, who deal with patrons from many different libraries.

I think the logic should work this way:

 - if the form has been submitted with a "branch" value, preselect that branch in branchloop.
 - if IndependantBranches is on, preselect the logged in user's branch in branchloop.
 - in ALL OTHER CASES the preselected branch should be "Any." It simply doesn't make sense to have the default case be a search limited to the logged-in user's branch.
Comment 4 Owen Leonard 2010-08-20 15:50:29 UTC
Created attachment 2558 [details] [review]
Proposed fix

This is a high-priority bug for my library, so I took a stab at fixing this. Comments and corrections are welcome.

I couldn't figure out how (or whether) GetBranchesLoop could be convinced to return a list of branches without selecting one, so I swapped GetBranchesLoop with GetBranches. This will preselect a branch only if a branch has been submitted as part of a query.
This does NOT preselect the correct branch when IndependantBranches is turned on.
I also added a template variable which is true if a query has been submitted with a branch or a category so that the extra form fields can be displayed, reminding the user that they added limiters to their query.
Comment 5 Ian Walls 2010-09-24 13:56:16 UTC
The expanded options should be set to display in any case where either branch or category code are not 'Any'.

It may make more sense to create a new system preference to govern whether the currently logged in branch is pre-selected, rather than simply using IndependentBranches.  This would give libraries the flexibility in their workflow to filter on their branch or not in patron search, independent of the other restrictions IndependentBranches implies.  IndependentBranches should trump this system preference.
Comment 6 Nicole C. Engard 2010-12-27 13:09:17 UTC
has anyone else taken a stab at this? It's a big deal for new libraries who migrate and one that is often reported as a bug until I point out the plus sign :)
Comment 7 Nicole C. Engard 2011-01-04 14:06:34 UTC
I have tested and signed off on this partial patch.  It works as you described and it is an improvement over the way it worked before.  Hopefully it will be accepted and someone else can solve the last missing piece.
Comment 8 Chris Cormack 2011-01-11 02:34:41 UTC
Patch pushed, please test and hopefully create a follow up patch to finish off this bug
Comment 9 MJ Ray (software.coop) 2011-02-02 08:52:17 UTC
This bug is mentioned in:
Fix for Bug 4945 - Patron	search is limited by default to the currently logged-in library http://lists.koha-community.org/pipermail/koha-patches/2011-January/013499.html
Comment 10 Marcel de Rooy 2011-02-24 10:31:26 UTC Comment hidden (obsolete)
Comment 11 Marcel de Rooy 2011-02-24 10:32:48 UTC
Comment on attachment 3200 [details] [review]
Alternative patch with new preference

Oops, attached to wrong bug
Comment 12 MJ Ray (software.coop) 2011-03-02 18:48:00 UTC
This bug is mentioned in:
Bug 3319 Followup: Fix	compatibility with fix for bug 4945 http://lists.koha-community.org/pipermail/koha-patches/2011-February/013912.html
Comment 13 Sharon Moreland 2011-03-02 23:19:50 UTC
Not sure where to report this, but I found a place where the [+] option is missing: cgi-bin/koha/members/member-flags.pl?
Comment 14 Owen Leonard 2011-03-03 17:32:03 UTC
(In reply to comment #13)
> Not sure where to report this, but I found a place where the [+] option is
> missing: cgi-bin/koha/members/member-flags.pl?

Display of the [+] option is dependent on the existence of the branch data: <!--TMPL_IF Name="branchloop"-->. The following templates share the same include which displays the search form:


All would display the [+] if the scripts were modified to pass "branchloop" data.
Comment 15 Chris Cormack 2011-09-12 22:17:26 UTC
This is still sitting awaiting a sign off
Comment 16 Liz Rea 2011-09-22 15:18:45 UTC
changed back from does not apply to p5 normal, as we need the 2nd half.