CDLUC3 / ezid-service

4 stars 0 forks source link

Delete account: Facebase #77

Closed mariagould closed 4 years ago

mariagould commented 4 years ago

Facebase Consortium is canceling its EZID service. Group and user account need to be deleted. User has registered no identifiers.

Shoulder: ark:/88119/f7 User: facebase Group: facebase

mariagould commented 4 years ago

@jkunze the shoulder for Facebase Consortium needs to be marked as inactive in the database. I have disabled the shoulder access in EZID and deleted the group and user.

This account had created no identifiers so our protocol is to remove the user account and group rather than move this into a maintenance status.

jkunze commented 4 years ago

Just to confirm, should I mark the shoulder as inactive? (It seems possibly a case of actually removing the shoulder, its minter, and recycling the NAAN.)

jkunze commented 4 years ago

Tried marking it as inactive, but it generated an error on stg where it's still referenced.

rushirajnenuji commented 4 years ago

Hey @jkunze - sorry I was not aware of this shoulder. You're right, it was active on Stage - I've now unhooked it from Stage so it can be deleted. Can you please try it again?

rushirajnenuji commented 4 years ago

@mariagould - quick question - usually we delete groups/users via scripts that Greg had developed. Did you delete them via the UI? Was the operation successful?

mariagould commented 4 years ago

Sorry for the trouble/confusion @rushirajnenuji and @jkunze !

Re: removing groups/users - I thought I could do this myself because I do have that ability via Admin UI and thought this was how we handled a previous situation with the Caltech account. Perhaps I was mistaken and I should have only unhooked the shoulder myself and let Rushiraj handle deleting the user/group by running the scripts. Will the scripts include stage too? In any case I'm sorry for messing this up.

Re: flagging/removing shoulders my only concern about recycling is that we have sometimes run into issues where the NAAN or prefix was inadvertently also used by other user accounts (a recent situation with UCLA & UT Austin for instance). But if we can ensure that is not the case I'm fine with recycling if that seems best.

jkunze commented 4 years ago

So this doesn't come back to haunt us, I've just followed protocol and marked it inactive. I'm all done with my bit now.

rushirajnenuji commented 4 years ago

Hey @mariagould - sorry I was wrong!

Re: removing groups/users - I thought I could do this myself because I do have that ability via Admin UI and thought this was how we handled a previous situation with the Caltech account.

It looks like the deletion performed via the UI was actually successful. The user and group were deleted from the production environment. We still had those records in stage, but I went ahead and removed them from stage database as well.

mariagould commented 4 years ago

Thanks @rushirajnenuji. Let's discuss the optimal workflow for these types of things at our next call.