<div dir="ltr">All,<div><br></div><div>Posting here in the hopes of getting thoughts/feedback before submitting as a potential feature request through JIRA.</div><div><br></div><div>For the second time now, an otherwise well-meaning, highly trained professional staffer at our institution has accidentally deleted a resource record.  I have a few thoughts as to why this keeps happening, and at least one feature request is already in JIRA to address them.  Namely:</div><div><br></div><div>1. When an archival component is deleted from a resource record, the resource record "refreshes" and places the user back at the top/collection level of the record.  Thus, a user (Repository Manager/Project Manager/Advanced Data Entry) deleting multiple archival components from a resource may find themselves in a "groove" wherein they keep scrolling from the top collection, down to the archival object to be deleted, selecting the archival object, hitting "delete," and rinsing and repeating the above.  Twice now we've had users not realize they were still at the RESOURCE level (not object level) when they hit delete and, therefore, bye bye resource.</div><div><br></div><div>2. The popup that confirms deletion is truly intended doesn't highlight what content is actually being deleted (archival component, resource, etc.)?<br><br>Both of the above would be addressed by implementing feature request <a href="https://archivesspace.atlassian.net/browse/AR-1132">AR-1132</a>.</div><div><br></div><div>However, I'm also wondering about the feasibility of a feature that would park "deleted" items (resources, objects, etc.) in a staging area before they are well and truly removed permanently from the db.  The idea initially came when I first contacted Lyrasis (we're hosted) to see about data recovery after our first improper deletion.  Mark Cooper wrote back:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I can also make a feature request to ArchivesSpace to put deleted items into a "staging" state, where they are actually deleted (removed from the database) when purged via the interface or through a background job.</blockquote><div><br></div><div>This could be a good model (especially as background jobs get built out more).  In our particular institutional setting (and perhaps for others), it would be ideal if the purge could only be instituted as a background job by the System Administrator, but, perhaps for others, you may want it to just be done as a regular cron job or something without user input.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Lora</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Lora J. Davis<br>Collections Archivist<br>Colgate University Libraries<br>13 Oak Drive<br>Hamilton, NY 13346<div>Tel:  (315) 228-6376<br>Fax: (315) 228-7934</div></div></div></div>
</div></div>