Bug 12838

Summary:	Deleting a borrower orphans that borrower's lists
Product:	Koha	Reporter:	Liz Rea <liz>
Component:	Lists	Assignee:	Fridolin Somers <fridolin.somers>
Status:	RESOLVED DUPLICATE	QA Contact:	Testopia <testopia>
Severity:	minor
Priority:	P5 - low	CC:	fridolin.somers, jonathan.druart, m.de.rooy
Version:	Main
Hardware:	All
OS:	All
See Also:	http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5763 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13417
Change sponsored?:	---	Patch complexity:	Trivial patch
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:
Attachments:	Bug 12838 - Deleting a borrower orphans that borrower's lists

Description Liz Rea 2014-08-28 02:34:24 UTC

Currently if any borrower has a list, and that borrower is deleted, the list is effectively abandoned and unable to be deleted until that list has been associated with an existent user.

A typical situation where this becomes an annoying problem:

Librarian A has a meticulously kept and well used list.
Librarian A changes jobs, her staff user is deleted.
The meticulously kept and well used list is now unable to be edited or deleted by her replacement, until the list has been updated to be associated with another staff user. This has to be done at the database level. 

There are several ways we could approach fixing this:

* simply delete all lists when a borrower is deleted (ok for regular patrons, probably not ok for staff members)

* Delete all orphaned private lists. Assign all public orphaned lists to user 0  and hide them from the OPAC interface. Possibly necessary would be a cron job to periodically clean up unclaimed lists that belong to borrower 0. Also allow privileged staff to assume ownership of a public list that belongs to borrower 0.

* ...or some other solution.

Comment 1 Fridolin Somers 2014-11-04 16:54:24 UTC

Created attachment 33204 [details] [review]
Bug 12838 - Deleting a borrower orphans that borrower's lists

Currently if any borrower has a list, and that borrower is deleted, the list is effectively abandoned and unable to be deleted until that list has been associated with an existent user.

This patch adds to a superlibrarian the ability to view/edit/delete/manage all lists.

Test plan :
- Log as not-superlibrarian user
- Go to lists module
=> You can only edit/delete your lists
- Log as superlibrarian user
- Go to lists module
=> You can do any action on any list

Comment 2 Marcel de Rooy 2014-11-05 12:43:21 UTC

Fridolin: We had discussions about superlibrarians viewing all lists in the past; the outcome generally was: don't do it for reasons of privacy.

Also note that in current master there should not be any orphaned lists anymore. Look at the code of VirtualShelves::DelBorrower. It is called when you delete a patron and it now deletes all lists of that patron. Bug 11889 was opened for a discussion about not deleting all lists.

Liz: Could you confirm that this is no longer a problem in current master?

Comment 3 Fridolin Somers 2014-11-05 15:21:07 UTC

(In reply to M. de Rooy from comment #2)
> Fridolin: We had discussions about superlibrarians viewing all lists in the
> past; the outcome generally was: don't do it for reasons of privacy.

privacy for a superlibarian ?
those users can see full patron details, circulation history, even change its password.

Comment 4 Marcel de Rooy 2014-11-05 15:52:57 UTC

(In reply to Fridolin SOMERS from comment #3)
> (In reply to M. de Rooy from comment #2)
> > Fridolin: We had discussions about superlibrarians viewing all lists in the
> > past; the outcome generally was: don't do it for reasons of privacy.
> 
> privacy for a superlibarian ?
> those users can see full patron details, circulation history, even change
> its password.

I will try to find it on Bugzilla..

Comment 5 Marcel de Rooy 2014-11-06 08:56:41 UTC

(In reply to M. de Rooy from comment #4)
> (In reply to Fridolin SOMERS from comment #3)
> > (In reply to M. de Rooy from comment #2)
> > > Fridolin: We had discussions about superlibrarians viewing all lists in the
> > > past; the outcome generally was: don't do it for reasons of privacy.
> > 
> > privacy for a superlibarian ?
> > those users can see full patron details, circulation history, even change
> > its password.
> 
> I will try to find it on Bugzilla..

See bug 5763 (there may be more, perhaps linked with bug 7310)

I personally think that we could perhaps resolve this by offering an optional third tab (or another form) in staff that allows the superlibrarian or perhaps users with a specific permission to search for lists of other users. This third tab or something like that could be switched off if the library sees it as a privacy issue. This would also prevent a mixup of all these lists for that particular staff user.

Comment 6 Fridolin Somers 2014-11-06 13:30:01 UTC

In my opinion, superlibarian user goal is to have full access in order to fix some problems : permissions, orphan datas ...
A normal user should not be superlibrarian. Only the system administrator who knows about patrons privacy and uses his access only when necessary.

Think about users that have access to the reports module, the can know what they want about patrons.

Comment 7 Jonathan Druart 2014-12-11 11:27:54 UTC

I think bug 13417 proposes a good and easy way to fix this problem.

Please mark this one as a duplicate if you agree.

Comment 8 Fridolin Somers 2014-12-11 12:56:36 UTC


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