[Archivesspace_Users_Group] Processors ability to delete?

Eric Milenkiewicz eric.milenkiewicz at ucr.edu
Wed Mar 8 14:01:34 EST 2017

Thanks for the feedback all and some potential workarounds. I agree that none are truly sustainable, though, in a production environment. Workflow management functionality for this would be awesome! Fingers crossed that makes it into development sometime down the line.


Eric Milenkiewicz

Manuscripts Curator

Special Collections & University Archives

UCR Library


My number one #ASpacePipeDream is for there to be some sort of workflow management functionality built-in.

-          Data entry user marks whoopsie item for deletion

-          Repo manager is notifed

-          Repo manager chooses to allow deletion or send back for review

-          Repo manager actually deletes

I say this as someone who once had a truly awesome, talented employee (at a former gig) accidentally delete an entire resource record.  (Though, this fix has made that far less likely https://archivesspace.atlassian.net/browse/AR-1313)


Lora J. Davis

Digital Archivist

The Sheridan Libraries

Johns Hopkins University

3400 North Charles Street

Baltimore, MD     21228

(410) 516-5898

ljdavis at jhu.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>] On Behalf Of Majewski, Steven Dennis (sdm7g)

Sent: Tuesday, March 07, 2017 4:10 PM

To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>>

Subject: Re: [Archivesspace_Users_Group] Processors ability to delete?

We've also run into this where people can create a resource, but can't delete it if they make a mistake and want to start over, or just want to create a test object when learning.  But in general, I think it's a good idea to make deleting a record more privileged. Maybe a useful feature would be to make the permission behavior dependent on resource status - perhaps make only published items require elevated permission to delete, or else make a exception for "draft" status or some other value.

On Mar 7, 2017, at 3:58 PM, Lisa Calahan <lcalahan at umn.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group><mailto:lcalahan at umn.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>>> wrote:

Hi Eric,

We have also run into this issue. It would be a great feature if the deletion of component records could be a separate permission from the "delete all major record types in this repository."

We have a couple of workarounds that we've used, none of which are really sustainable. 1) A student/staff person will report when they need a component record deleted and a staff person with that permission will delete the record for them (usually happens when a component record was accidentally duplicated) and a supervisor is sitting close by. 2) The repository manager or ASpace administrator will temporarily give the permission group "delete the major record types of this repository" permission to be able to delete; which is paired with a stern talking to about being careful to not delete a resource record. 3) Move multiple/various component records that need to be deleted into a "To delete" grouping/fake series at the end of the resource record to have a supervisor delete as one of the final review tasks.



On Tue, Mar 7, 2017 at 2:35 PM, Eric Milenkiewicz <eric.milenkiewicz at ucr.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group><mailto:eric.milenkiewicz at ucr.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>>> wrote:

Hi All,

We have recently hired/trained student employees on processing archival collections in ASpace, however we cannot seem to find a way of fine tuning the user permission groups to provide them with an appropriate level of access.

For example, the advanced/basic data entry staff and archivist levels do not allow permissions for resource component records to be deleted (which is often times needed while processing, as things change). This level of access is not achieved until the repository/project manager level which provides much greater permissions. Configuring the User Permission Groups also has not helped here since once the "delete the major record types in this repository" option is checked then entire Resource and Accession records can be deleted (a function we want to restrict to higher level staff).

Has anyone else run into this type of permissions issue? And if so, have you identified any workarounds?


Eric Milenkiewicz

Manuscripts Curator

Special Collections & University Archives

UCR Library

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/077b0d94/attachment.html>

More information about the Archivesspace_Users_Group mailing list