Bug 31032 - Patron attributes branch limitations are unclear
Summary: Patron attributes branch limitations are unclear
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 27857
Blocks:
  Show dependency treegraph
 
Reported: 2022-06-23 17:47 UTC by Nick Clemens
Modified: 2022-10-18 14:03 UTC (History)
5 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens 2022-06-23 17:47:28 UTC
When a patron attribute is limited to some branches it seems to mean:
1 - That attribute shows on moremember, and on opac to patron, but not in patron edit screen if signed in at a different branch 
2 - It can be set for any patron from any branch on staff side, but only by libraries from the limited list
3 - The code in extended_attributes appears to ignore all branch specific mandatory attributes:
1707                 my @required_attribute_types =
1708                     Koha::Patron::Attribute::Types->search(
1709                         {
1710                             mandatory => 1,
1711                             category_code => [ undef, $self->categorycode ],
1712                             'borrower_attribute_types_branches.b_branchcode' =>
1713                               undef,
1714                         },
1715                         { join => 'borrower_attribute_types_branches' }
1716                     )->get_column('code');
Comment 1 Jonathan Druart 2022-07-04 12:54:34 UTC
Coming from bug 27857 comment 5 (and 6).
Comment 2 Katrin Fischer 2022-07-15 18:49:35 UTC
Hi Nick, can you explain a bit more about the issue here? I am not sure what the expected behavior would be.
Comment 3 Nick Clemens 2022-07-18 13:55:48 UTC
I am not sure either, that's why I filed this :-)

I guess my question is:
Does limiting an attribute to a branch(es) imply that only patrons from that branch should have the attribute?
or 
Does limiting an attribute to a branch(es) imply that only librarians from that branch can see that attribute?

i.e. What is the purpose of the limit?

Once we have that, then we can verify it works correctly

Additionally - they can't be required for any patrons, or at least we don't enforce it as we do others (delete the whole attribute node from the form and submit - not blocked)
Comment 4 Katrin Fischer 2022-07-18 18:32:07 UTC
Hm, we never used that feature, but there have been bugs reported about it that might give some insight - or at least lead to libraries using it?

I feel like maybe 'visible for the library's staff users' might be the answer:

Bug 7919 - Display of values depending on the connexion library (authorised values, patron categories, extended attributes)

Bug 15163 - Patron attributes with branch limiits are not saved when invisible
Comment 5 Jonathan Druart 2022-07-19 13:30:35 UTC
(In reply to Nick Clemens from comment #3)
> Does limiting an attribute to a branch(es) imply that only librarians from
> that branch can see that attribute?

This.
It was the goal of bug 7919, restrict some values to a list of branches.
Comment 6 Katrin Fischer 2022-07-20 07:21:52 UTC
I think the question was "patron's home library" or "staff user's logged in library", but it appears that 'logged in library' is correct.
Comment 7 Donna 2022-10-18 13:39:56 UTC
I don't know what the original intention of branch limits was, but can speak to how libraries are expecting it to work now.  When something (patron category, attribute, auth value) is limited by branch the expectation is that I can see the data, but if I edit the field, the only options I see are the ones that my logged in branch are supposed to see.  

For instance, if patron category FEE is limited to branch A and B, and I am logged in at branch C, I should be able to search for patrons in that category, display their record, see they are category FEE, but when I create a new patron, or try to edit their record, I do not have the patron category option of FEE.
Comment 8 Katrin Fischer 2022-10-18 14:03:12 UTC
(In reply to Donna from comment #7)
> I don't know what the original intention of branch limits was, but can speak
> to how libraries are expecting it to work now.  When something (patron
> category, attribute, auth value) is limited by branch the expectation is
> that I can see the data, but if I edit the field, the only options I see are
> the ones that my logged in branch are supposed to see.  
> 
> For instance, if patron category FEE is limited to branch A and B, and I am
> logged in at branch C, I should be able to search for patrons in that
> category, display their record, see they are category FEE, but when I create
> a new patron, or try to edit their record, I do not have the patron category
> option of FEE.

Exactly, I think we need to differentiate between new and existing. Because at te moment editing other library's data, we create a data loss situation :( :

See Bug 31422 - Library limitations might cause data loss

I think if you are allowed to edit other branch's data, we should add a 'keep current' option that allows you to leave values unchanged at least.

Or we'd need to add hints that these limitations can only be recommended if you take other precautions like limiting who can edit patron and item data. (would be really happy to see bug 20256 bounce back into QA queue)