[Archivesspace_Users_Group] Former users and data loss

Wed Mar 8 10:38:29 EST 2017

On Mar 8, 2017, at 10:32 AM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:

It appears to be a misfeature that deleting a user also deletes the agent record for that user, which is what the backend model for user does.

I believe removing those last three lines would fix the problem:
https://github.com/archivesspace/archivesspace/blob/master/backend/app/model/user.rb#L244-L246

i.e. remove the User object but leave the Agent object. Links are from User to Agent, so I don’t think there would be any unexpected side effects. As a test, I removed a User record only on a test site in MySQL, and display still shows their id as the author.

I will test this further if there is a consensus that this is the desired behavior.

Downside of this method is that a lot of the organizational info for the person like title and department is attached to that User record, and that would be handy to know for the Audit.

So perhaps everyone should follow Yale’s guide and NOT delete users, but this might still be a good code change to prevent complete loss of the trail in case someone does delete a User.

— Steve.

On Mar 8, 2017, at 10:24 AM, Caldera, Mary <mary.caldera at yale.edu<mailto:mary.caldera at yale.edu>> wrote:

Hi,

Our Yale ArchivesSpace User management Policy, prohibits the deletion of user records for the very reasons noted. The relevant section is as follows. –

Access Control
•         The creation, deactivation, and the changing of user accounts and privileges must be carried out only by trained and authorized staff (i.e. the Yale ArchivesSpace Committee).
•         Access to ArchivesSpace will be limited to the Yale NetIDs of people who are members of the ArchivesSpace Active Group. This single Active Group will have access to all three instances of ArchivesSpace at Yale: dev, production, and test. Even though access will be allowed to the same three instances, that does not mean that each will have the same set of privileges. For example, only developers will have privileges in the dev instance.
•         The person enacting any change to a user account must be different from the person requesting the change.
•         Accounts should never be deleted from the ArchivesSpace database; instead, when a user no longer requires access to the ArchivesSpace database, their account will be deactivated.
•         Accounts will be deactivated by following these three steps:
o    The ArchivesSpace username will be preceded with a “zzz_” in the ArchivesSpace database.
o    The Yale NetID will be removed from the ArchivesSpace Active Directory group.
o    Any repository roles associated with that account will be removed.
•         Inactive accounts will be periodically reviewed to determine if any need to be deactivated.
•         Accounts may be re-activated -- but only after a request has been issued and approved by following the same procedures required for requesting a new account -- by removing the “zzz_” from an existing username and then following the same procedure for the addition of any new ArchivesSpace account.
Sincerely,
Mary
_______________________________
________________________________

Mary Caldera,
Head of Arrangement and Description
Manuscripts and Archives
Yale University Library
P.O. Box 208240
New Haven, CT  06520-8240
203/432-8019

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org]On Behalf Of Olivia S Solis
Sent: Tuesday, March 7, 2017 7:02 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Former users and data loss

Hello all,

The Briscoe Center is in the process of adopting ArchivesSpace and has been testing it out in a sandbox. We took note of a potential problem in the future regarding hypothetical former employees who may have been ASpace users at one point. Presumably, we would delete them after they moved on to other work. I wanted to see what a user's trail might look like after he/she were deleted from the system, so I created an appraisal event with a user (my dog Chicken) as the authorizer.

The results are mixed. While in some fields it looks like the data is retained, in some fields it is not. For instance:

  *   In the Events Browser, the former employee/user appears as the authorizer and record creator
  *   Within the event itself, the agent link is blank
  *   In the resource record the event is linked to, the agent links field is empty, but the created and Last modified fields list the now deleted user

Before you delete an agent record, ArchivesSpace does warn you that you will lose all references to it in the database, including references to it in other records. How have some of you anticipated handling this situation? Leave former employees in the system and change their passwords? Is there a workaround for some of the loss of data or am I missing an obvious solution to this?

Thanks!
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
livsolis at utexas.edu<mailto:livsolis at utexas.edu>
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

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