Summary: | Add new patron shows default / hardcoded patron categories after search | ||
---|---|---|---|
Product: | Koha | Reporter: | David Roberts <david.roberts> |
Component: | Patrons | Assignee: | Jonathan Druart <jonathan.druart> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | chris, david.roberts, gmcharlt, jonathan.druart, kyle.m.hall, magnus, mtj, tomascohen |
Version: | 3.16 | ||
Hardware: | All | ||
OS: | All | ||
See Also: | http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13497 | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | Small patch | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 9811 | ||
Bug Blocks: | |||
Attachments: |
Bug 13458: Display the correct patron categories
Bug 13458: Display the correct patron categories [PASSED QA] Bug 13458: Display the correct patron categories Bug 13458: specific followup for 3.16.x |
Description
David Roberts
2014-12-13 19:49:31 UTC
We can confirm this bug still appears in 3.18.2. Created attachment 34680 [details] [review] 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'. Created attachment 34682 [details] [review] 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> 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. Patch pushed to master. Thanks Jonathan! (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. Pushed to 3.18.x will be in 3.18.3 Contains string changes, holding for 3.16.8 Pushed to 3.16.x, will be in 3.16.7 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... The setting of AddPatronLists does not affect the behaviour. The hardcoded categories are shown no matter what AddPatronLists is set to. (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. (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 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 Magnus, could you please confirm this patch works for 3.16.x? (I tested it and it fixes the problem for 3.16.x) (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 :) (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 |