Bug 13668 - Creator of an SQL report shoudl be NULL when the staff patron is deleted
Summary: Creator of an SQL report shoudl be NULL when the staff patron is deleted
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Database (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 5334
  Show dependency treegraph
 
Reported: 2015-02-04 17:40 UTC by Katrin Fischer
Modified: 2024-01-17 16:17 UTC (History)
3 users (show)

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


Attachments
Bug 13668: Add foreign key on saved_sql.borrowernumber (3.52 KB, patch)
2016-01-13 15:15 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 13668: Add foreign key on saved_sql.borrowernumber (3.58 KB, patch)
2016-01-13 22:26 UTC, Joy Nelson
Details | Diff | Splinter Review
Bug 13668: Add foreign key on saved_sql.borrowernumber (3.64 KB, patch)
2016-01-13 22:35 UTC, Danielle Elder
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2015-02-04 17:40:39 UTC
When deletig a staff patron his/her reports are still linked to his/her former borrowernumber. It would be better to delete the connection to the creator when the staff patron is deleted.
Comment 1 Nick Clemens 2015-02-04 20:45:46 UTC
FWIW I would kind of like to know who created a report even if they are removed from the system.  Maybe link it to the deletedborrowers table and display in red or with a note?  Some people's reports you might want to save, and some delete, harder to suss out if all set to null.
Comment 2 Katrin Fischer 2015-02-05 12:47:31 UTC
The idea behind this is that we shoudln't keep information about people (staff or patrons) forever in the database. When you have left the library, there should be a point where they are no longer saving things about you in their computer systems.
Comment 3 Nick Clemens 2015-02-05 19:28:11 UTC
Agreed.  My thinking was factoring in bug 13667. Once deletedborrowers is cleared, borrowernumber seems a fairly anonymous piece of info, but that might just be how we use it as staff here. As far as I can tell, the statistics table doesn't null out borrowernumber when deleting a patron either.  Not a big deal and okay with this solution, just giving my 2 cents
Comment 4 Katrin Fischer 2015-02-05 22:40:55 UTC
Hi Nick, I understand your point - we are a bit crazy here about saving/deleting things :)
Comment 5 Jonathan Druart 2016-01-13 15:15:33 UTC Comment hidden (obsolete)
Comment 6 Joy Nelson 2016-01-13 22:26:03 UTC Comment hidden (obsolete)
Comment 7 Danielle Elder 2016-01-13 22:35:49 UTC
Created attachment 46623 [details] [review]
Bug 13668: Add foreign key on saved_sql.borrowernumber

saved_sql.borrowernumber refers to a borrowernumber, the DB structure should
reflect this constraint.

Test plan:
0/ Do not execute the update DB entry
1/ Add a new patron
2/ Use this patron to create a new report
3/ Delete the patron
4/ Execute the DB entry
5/ The saved_sql.borrowernumber for this report should have been set to NULL
6/ On the reports table, the column 'Author' should be empty.

Signed-off-by: Joy Nelson <joy@bywatersolutions.com>

Signed-off-by: Dani Elder <danielle@bywatersolutions.com>
Comment 8 Jonathan Druart 2016-02-02 17:20:30 UTC
Need to think about it (merge deletedborrowers with borrowers table).