Bug ID: 18403
Summary: Hide patron information if not part of the logged in
user library group
Change sponsored?: ---
Severity: new feature
Priority: P5 - low
Assignee: [hidden email] Reporter: [hidden email] QA Contact: [hidden email] CC: [hidden email], [hidden email]
Add the ability to hide patron record information from any other library
(outside the group).
This patchset adds a new feature that will allow libraries inside a
single Koha installation to restrict access to information of patrons
The group of libraries feature is introduced by bug 15707, see this bug for
Let's imagine that 2 groups G1 and G2 are defined and that they include 2
each G1a, G1b and G2c, G2d: logged in users attached to G1a will only see
information from G1a and G1b.
To add more flexibility, a new user permission named
will drive this behavior. If set, the patron will be able to see patron's
of any libraries.
If the restriction is set, the logged in user will not be able to search, show,
delete patron's information of patrons attached to groups of libraries outside
In situations we need to refer to a patron, for holds and checkouts for
and his information cannot be viewed, a text "A patron from library G1A" will
Considered unecessary or outside the scope of this bug report:
* The report module is not affected by this feature for obvious reasons
* The firstname and surname of guarantors, basket (acq) managers, patrons
to orders are still displayed.
* Log viewer: Can only be staff
* patron list: you cannot add patrons from another group of librairies, but can
see/delete from list (too much rewrite, or we can test for patron one by one?).
* "Patron card creator" tool is not impacted by this feature.
* Upload patron images is not impacted by this patch, should it be?
- Upload patrons
- Clean borrowers tool (This can can done easily updating
with Koha::Patrons->search_limited in search_upcoming_membership_expires and
search_patrons_to_anonymise but we will need to move GetBorrowersToExpunge to
We can discuss these different points but will be other bug reports not to add
more complexity to this first patchset.
You will find a test plan in the following commit messages.
Start by creating different group of libraries and patrons with and without the
new permission. Open different browser sessions to ease the tests.
Note that all patches have to be applied to test the different test plans.
For QAers (and others) a techical note will be added to the commit messages of
patchset. I would recommend you to read them one by one to understand the
steps of this development.
+ Special attention should be payed to the REST api changes
+ Should we restrict the logged in user to libraries from his group when
he wants to set his library (Home › Circulation › Set library)?
This is more a follow-up for bug 15707. It could be moved on its own bug report
IMPORTANT NOTE: At the moment the feature only works for 1 level depth, see
bug 15707 comment 166+ for the discussion
It means that if we have:
groupA1_library2 is not considered a child of groupA1.
Note that this can change.
should return green
To ease future changes we are passing a logged_in_user variable to templates.
It contains the Koha::Patron object representing the logged in patron.
This will be very useful for this patch and even after (for instance we will be
able to replace easily loggedinusername and loggedinusernumber).
This is the method that will be called on the logged_in_user variable sent to
the template. Moreover we will check that the logged in user can access patron'
information when access to members/* and some circulation scripts will be done.
Login with a patron that only have the 'edit_borrowers' permission.
You should be able to access patron's information of patrons inside of your
Before this patchset the borrowers permission module contains only 1 permission
borrowers => 1
borrowers => '*'
had the same behavior.
Moreover, now that we have 2 permissions, 'CAN_user_borrowers' is set when all
permissions of 'borrowers' are set.
We need to update the different occurrences of these tests.
Login with a patron that is not allowed to see patron's information for patrons
outside of his group. Try to access patron's information from scripts of the
module (members/*) and circ/circulation.pl.
You should be able to access patron's information of patrons outside of your
and get "You are not allowed to see the information of this patron."
If you try and access a patron page with a borrowernumber that does not exist,
should get "This patron does not exist"
A new C4::Output subroutine is created in this patch:
Executed at the beginning of the script it will permit not to copy/paste all
different checks to know if the logged in user is authorised to see patron's
The design here can be discussed, but I did not find an alternative with as
On the way I refactor what we did with 'unknowuser' previously: it will now
work with all
patron pages, not only the few that used it.
Note that the 'or die "Not logged in";' part should not be needed, but... who
I think it could be used as a safeguard later. I am willing to sed and remove
Changes in discharge.pl are mainly indentation changes.
With this patch we should now have a $patron variable that refer to the patron
want to access. That will be very useful to remove plenty of code in members/*
only pass this variable to the template (instead of 1 variable per patron's
This patch modifies the patron search code to limit the libraries to the
the logged in user is allowed to access
Search for patrons
You should not see patrons you are not allowed to see.
I am really glad to have refactored all the patron searches before
write this patch. It tooks me ~40 l to acchieve this job and affect all
From where patrons it's about patrons, we do not want to display the libraries
from all the system, but only the ones from the group.
- See the overdues (circ/overdue.pl) and make sure you can only see overdues
patrons part of your group (do not forget to test the CSV export).
- Search for patrons, the 'library' filters (headers and left side) should only
display libraries from your group
- Search for article request by patron's library: only the libraries from your
group should be displayed
There is already a HidePatronName syspref to hide patron's information
record detail pages and the hold list.
With the HidePatronName enabled, make sure the patron's information are
the catalogue and hold list pages. If the logged in user is not allowed
to see the
patron's info, no link and no cardnumber will be displayed
With he HidePatronName disabled, make sure the patron's information are
if the logged in user is allowed to see the patron's info.
This patch improves the existing patron-title.inc include file to
information. Using it everywhere patron's details are displayed will
homogenise the way they are displayed. The file takes now a patron
should be, in the future, the only way to use it), that way we can call
method on it to know if patron's information can be shown by the logged
NOTE: I am not sure this syspref makes sense anymore. Should not we
Most of the time when we search for patrons we do not want to search for all
but just the ones the logged in user is allowed to see the information.
This patch takes care of that by adding a new search_limited method to
When called this method only search for patrons that the logged in user is
Patron autocomplete search should be limited
Here we are just refactoring a code that have been copied into 3 different
libraries_where_can_see_patrons is a terrible method's name, feel free to
something better. The method return a list of branchcodes to be more efficient,
instead of Koha::Libraries
Sometimes we do not have the patron object, for instance for the patron
we will need to know if the logged in user can modify patron's from a given
This new subroutine 'can_see_patrons_from' will then be useful
Limit patron's modifications based on logged in patron permissions.
Create some patron's modification requests at the OPAC
Make sure the logged in staff user see (or not) the modification depending his
The number of modification displayed on the mainpage should be correct as well.
Same as previously you will need to request dischages at the OPAC.
On the staff interface the logged in user should not be allowed to see
from patrons outside his library group.
The number of discharges waiting displayed on the mainpage should be
correct as well.
Technically a kid from your library group could have a guarantor
attached to another
group of library, let's deal with this case.
- Create a kid from your library group
- With a superlibrarian staff user create a guarantor that is outside of
the group of
libraries of the kid
- Login with a limited staff user and confirm that on the patron detail
page you do not
see the link to the guarantor detail page.
Note that you see the firstname and surname of the guarantor
Q. should it be hidden?
There is something wrond here, the userenv is no set and so we cannot
Should we set the userenv or filter on the libraries using
WAITING FOR FEEDBACK HERE.