Bug 21255

Summary: memberetnry.pl is missing categories in the Category pull-down list
Product: Koha Reporter: Chris Nighswonger <cnighswonger>
Component: PatronsAssignee: Bugs List <koha-bugs>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: gmcharlt, jonathan.druart, kyle.m.hall
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18403
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21414
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Chris Nighswonger 2018-08-21 19:37:06 UTC 
In some instances, when editing a patron, the Category pulldown under the "Library management" section is missing categories.

I'm at a loss as to how to accurately describe the problem, but here goes:

1. The given patron's category shows up correctly on every other screen.
2. Navigating to the Patron Detail screen and selecting the edit option for Library use section results in the Modify Patron screen.
3. The heading on the Modify Patron screen displays the correct category.
4. However, the Category pulldown does not.
5. Furthermore, the pulldown does not even contain the correct category for the given patron.

Doing a bit of looking around turned up a few things which may or may not be related. For the given patron:

1. The problem seems to be with the child category.

2. The Koha::Patron::Categories object may contain missing or incorrect category information. Here is a snip of the object returned for the 'C' category type by this line http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=members/memberentry.pl;h=cb4d0506ac54258b29fd82602c57a6056cf822ba;hb=HEAD#l634

                                          'attrs' => {
                                                       'bind' => [],
                                                       'join' => 'categories_branches',
                                                       'order_by' => [
                                                                       'categorycode'
                                                                     ],
                                                       'where' => {
                                                                    'category_type' => 'C',
                                                                    'categories_branches.branchcode' => [
                                                                                                          'JL',
                                                                                                          undef
                                                                                                        ]
                                                                  },
                                                       'alias' => 'me'
                                                     },

3. The underlying data appears to be sound.
4. This was not a problem prior to upgrading a month ago. Unfortunately, I'm not sure what version this system was at prior to the upgrade.

Maybe this will get the discussion started and someone with more knowledge of this area of the code can give some direction to it.
Comment 1 Jonathan Druart 2018-08-29 20:47:35 UTC 
Hi Chris,

Which exact version are you using?

Do you see limitations under the "Branches limitations" column on "Home › Administration › Patron categories"?

My guess is that the patron's category of this patron cannot be displayed for the library 'JL' (check the table categories_branches)
Comment 2 Chris Nighswonger 2018-08-30 12:01:20 UTC 
(In reply to Jonathan Druart from comment #1)
> Hi Chris,
> 
> Which exact version are you using?

18.05.01.000

> 
> Do you see limitations under the "Branches limitations" column on "Home ›
> Administration › Patron categories"?

Yes. Both categories in question have a one branch limitation imposed.

> 
> My guess is that the patron's category of this patron cannot be displayed
> for the library 'JL' (check the table categories_branches)

So this caused me to change libraries in the staff interface and then attempt the steps I originally reported. This time, the categories were displayed.

This seems counter-intuitive. When in the staff interface, it would seem intuitive to think that any patrons one can see, one can perform all available operations on. If any constraints are imposed based on the current branch of the staff user, it would seem that only patrons associated with that branch should be visible.
Comment 3 Jonathan Druart 2018-09-04 19:20:17 UTC 
Agreed, this feature has been poorly implemented, I am the one to blame.

I am wondering if it makes sense to keep it as now we can limit access to patron's info by group of libraries (see bug 18403). Do you think this new feature could fit your use case?

Does it really make sense to limit access to patron's categories?
Comment 4 Chris Nighswonger 2018-09-05 13:24:49 UTC 
(In reply to Jonathan Druart from comment #3)
> I am wondering if it makes sense to keep it as now we can limit access to
> patron's info by group of libraries (see bug 18403). Do you think this new
> feature could fit your use case?

In our case, the librarians administer all libraries on campus, so we have no need to impose branch restrictions from that point of view.

> 
> Does it really make sense to limit access to patron's categories?

I guess that depends on the use case. If a library restricts administration of patron information based on the branch of the one administrating, then probably so.

On the other hand, there may be some patron information which is only accessible by some sort of "super" admin like a super-librarian concept of some sort.

I'm just not sure what to suggest other than that we need all librarians to have access to all patron information at our site.
Comment 5 Katrin Fischer 2023-04-08 21:46:21 UTC 
I believe this is fixed by bug 31422.

*** This bug has been marked as a duplicate of bug 31422 ***