Bug 13458 - Add new patron shows default / hardcoded patron categories after search
Summary: Add new patron shows default / hardcoded patron categories after search
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 3.16
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on: 9811
Blocks:
  Show dependency treegraph
 
Reported: 2014-12-13 19:49 UTC by David Roberts
Modified: 2015-12-03 22:03 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 13458: Display the correct patron categories (3.27 KB, patch)
2014-12-26 09:37 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 13458: Display the correct patron categories (3.33 KB, patch)
2014-12-26 19:27 UTC, Chris Cormack
Details | Diff | Splinter Review
[PASSED QA] Bug 13458: Display the correct patron categories (3.70 KB, patch)
2014-12-27 12:08 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 13458: specific followup for 3.16.x (986 bytes, patch)
2015-01-27 15:01 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Roberts 2014-12-13 19:49:31 UTC
After performing a patron search resulting in a list of patrons, clicking on New Patron shows a default list of patron categories, not the ones configured on the system. This happens in 3.18 and on Master.

To reproduce:

1) Carry out a patron search for Smith (or other similar common name). This will bring up cgi-bin/koha/members/member.pl and a list of patrons. 
2) Click on New Patron.
3) The list of categories will contain: Adult Patron, Child Patron, Professional Patron, Organisation, Staff Patron, Statistical Patron. These will display regardless of which patron categories are configured.

This is the only page on which this happens - adding a patron on cgi-bin/koha/members/members-home.pl shows the correct list of configured patron categories.
Comment 1 Katrin Fischer 2014-12-23 21:05:23 UTC
We can confirm this bug still appears in 3.18.2.
Comment 2 Jonathan Druart 2014-12-26 09:37:02 UTC Comment hidden (obsolete)
Comment 3 Chris Cormack 2014-12-26 19:27:47 UTC Comment hidden (obsolete)
Comment 4 Katrin Fischer 2014-12-27 12:08:01 UTC
Created attachment 34707 [details] [review]
[PASSED QA] Bug 13458: Display the correct patron categories

Bug 9811 removes useful code.
Actually the AddPatronLists pref is not sent to the template from
members/member.pl.

To fix this issue, we can use the existing not clean way, or compare the
syspref value directly in the template. This second solution is
implemented in this patch.

Test plan:
1/ Set the AddPatronLists pref to 'specific'
2/ On the patron home page (members/members-home/pl), the patron search
result page (members/member.pl after launching a search) and on the
checkouts page/patron search result (circ/circulation.pl after searching
a patron using the check out), verify that the patron category list is
the specific ones.
3/ Test there are no regression with the AddPatronLists pref set to
'general'.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described and fixes the problem.

Note: I am not sure if AddPatronLists makes sense -
if you set it to general patron types, it still preselects the
wrong category type (tried organization, a child patron category
was selected). Also the name is confusiong nowadays with the
Patron list feature.
Comment 5 Tomás Cohen Arazi 2014-12-28 23:50:35 UTC
Patch pushed to master.

Thanks Jonathan!
Comment 6 Jonathan Druart 2014-12-29 14:16:49 UTC
(In reply to Katrin Fischer from comment #4)
> Note: I am not sure if AddPatronLists makes sense -
> if you set it to general patron types, it still preselects the
> wrong category type (tried organization, a child patron category
> was selected). Also the name is confusiong nowadays with the
> Patron list feature.

Agreed, cf bug 13497.
Comment 7 Chris Cormack 2014-12-30 21:30:05 UTC
Pushed to 3.18.x will be in 3.18.3
Comment 8 Mason James 2015-01-16 19:45:01 UTC
Contains string changes, holding for 3.16.8
Comment 9 Mason James 2015-01-18 00:56:18 UTC
Pushed to 3.16.x, will be in 3.16.7
Comment 10 Magnus Enger 2015-01-27 13:46:19 UTC
I am still seeing something similar to this on 3.16.7. But I don't have to do a search to see it. If I just go to the "Patrons" page (<intranet>/cgi-bin/koha/members/members-home.pl), the dropdown for adding a new patron is showing the default/hardcoded patron categories. Not sure if it is the same issue as this one or something new...
Comment 11 Magnus Enger 2015-01-27 14:00:21 UTC
The setting of AddPatronLists does not affect the behaviour. The hardcoded categories are shown no matter what AddPatronLists is set to.
Comment 12 Jonathan Druart 2015-01-27 14:45:37 UTC
(In reply to Magnus Enger from comment #11)
> The setting of AddPatronLists does not affect the behaviour. The hardcoded
> categories are shown no matter what AddPatronLists is set to.

Yes, this pref does not work, I proposed to remove it on bug 13497.
Comment 13 Jonathan Druart 2015-01-27 14:58:03 UTC
(In reply to Magnus Enger from comment #10)
> I am still seeing something similar to this on 3.16.7. But I don't have to
> do a search to see it. If I just go to the "Patrons" page
> (<intranet>/cgi-bin/koha/members/members-home.pl), the dropdown for adding a
> new patron is showing the default/hardcoded patron categories. Not sure if
> it is the same issue as this one or something new...

You are right, it does not work for 3.16.x
Comment 14 Jonathan Druart 2015-01-27 15:01:51 UTC
Created attachment 35555 [details] [review]
Bug 13458: specific followup for 3.16.x

members/member.tt uses patron-toolbar.inc which calls the Koha TT Plugin
(for Preference).
But this plugin is not loaded in the member.tt.

It works on master and 3.18.x
Comment 15 Jonathan Druart 2015-01-27 15:03:05 UTC
Magnus, could you please confirm this patch works for 3.16.x?

(I tested it and it fixes the problem for 3.16.x)
Comment 16 Mason James 2015-02-25 11:02:40 UTC
(In reply to Jonathan Druart from comment #15)
> Magnus, could you please confirm this patch works for 3.16.x?
> 
> (I tested it and it fixes the problem for 3.16.x)


I've tested this 2nd patch on 3.16.x. 

It works OK for me :)
Comment 17 Mason James 2015-02-25 11:03:48 UTC
(In reply to Mason James from comment #16)
> (In reply to Jonathan Druart from comment #15)
> > Magnus, could you please confirm this patch works for 3.16.x?
> > 
> > (I tested it and it fixes the problem for 3.16.x)
> 
> 
> I've tested this 2nd patch on 3.16.x. 


Pushed to 3.16.x, patch will be in 3.16.8