Preferred Name and Keywords Stay After Purging Patron
Bug #1802166 reported by
John Amundson
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
3.2 |
Won't Fix
|
Medium
|
Unassigned | ||
3.3 |
Won't Fix
|
Medium
|
Unassigned | ||
3.4 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Evergreen 3.2.1
When choosing the option to "Completely Purge Account", any preferred names or name keywords attached to the patron continue to exist in the database.
Is there any reason to not anonymize these like the rest of the fields on the account when it is purged?
I've attached a screenshot of the deleted record pulled up in the web client, (via database ID). Notice the purged status of the account and the how the preferred names and keywords persist.
Changed in evergreen: | |
status: | New → Confirmed |
Changed in evergreen: | |
milestone: | none → 3.3-beta1 |
assignee: | nobody → Jason Stephenson (jstephenson) |
tags: | added: pullrequest |
Changed in evergreen: | |
milestone: | 3.3-beta1 → 3.3-rc |
Changed in evergreen: | |
milestone: | 3.3-rc → 3.3.1 |
Changed in evergreen: | |
milestone: | 3.3.1 → 3.3.2 |
Changed in evergreen: | |
milestone: | 3.3.2 → 3.3.3 |
Changed in evergreen: | |
milestone: | 3.3.3 → 3.3.4 |
Changed in evergreen: | |
milestone: | 3.3.4 → 3.3.5 |
Changed in evergreen: | |
milestone: | 3.3.5 → 3.4.2 |
Changed in evergreen: | |
milestone: | 3.4.2 → 3.4.3 |
Changed in evergreen: | |
milestone: | 3.4.3 → 3.4.4 |
Changed in evergreen: | |
milestone: | 3.4.4 → 3.5.1 |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
I have pushed a branch that fixes this for master/3.3: user/dyrcona/ lp1802166- purge-preferred -names in the working repository.
https:/ /git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ dyrcona/ lp1802166- purge-preferred -names
I had made a branch for 3.2, but realized that backporting this fix is dangerous because there are other changes to the actor.usr_delete function between rel_3_2 and master. If the rel_3_2 function and the master function have the same upgrade number, then someone could update their 3.2 installation and miss getting the new features of actor.usr_delete when upgrading to 3.3 or beyond later.
Because of this, I have set the 3.2 target for this bug to Won't Fix. If someone thinks we should fix this in 3.2, I can push the branch, but whoever merges this into master and rel_3_2 will need to know to use different upgrade numbers for each branch. (I think I've seen this done in one or two cases prior to this.)