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');
Coming from bug 27857 comment 5 (and 6).
Hi Nick, can you explain a bit more about the issue here? I am not sure what the expected behavior would be.
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)
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
(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.
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.
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.
(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)