Hyrax: Delete an Admin Set

[mjgiarlo]

As a user who has the ability to manage Admin Sets, I should see a button on the Admin Set show view (next to the Edit button) that allows me to delete the Admin Set. When I click the button, I should be asked to confirm the deletion. When the Admin Set is deleted, all relationships pointing at the Admin Set should also be destroyed.

Comments on the above, @jcoyne @hannahfrost @ggeisler?

[jcoyne]

Technically, this should be implemented as a background job as you might be re-indexing thousands of objects. Should we ask if the user wants to move the objects to a different admin set?

[ggeisler]

Yeah, I agree we need to offer the user the opportunity to move the objects to another admin set before deleting them.

[mjgiarlo]

@hannahfrost @ggeisler Do y'all think this needs design, or should we wing it and use our best judgment?

[ggeisler]

I don't think the basic action needs design, @mjgiarlo, you describe it well in your initial comment. Probably obvious but the key things are using the danger color for the button and asking for confirmation (with a way to easily cancel) before destroying anything. (Similar to the Deactivate user button in https://github.com/projecthydra-labs/hyku/issues/444.)

But if we've agreed that the user should be able to move objects to a different admin set before proceeding with deleting the admin set, the interaction and wording on the confirmation dialog gets more complex. I wouldn't have a problem if you guys want to take a crack at it without a design, as long as I retain the right to suggest (hopefully only minor) changes after seeing the implementation...

[mjgiarlo]

as long as I retain the right to suggest (hopefully only minor) changes after seeing the implementation... (@ggeisler)

Yes, of course! Always.

[hannahfrost]

@mjgiarlo @ggeisler I think an admin set should only be deletable when it is empty. This seems like an appropriate safeguard for a repository application. So the user will need to have the option to move the content to a different admin set (including the default one) or deleting the contained works deliberately before deleting the admin set. I realize that this complicates the UI. Design needed?

[mjgiarlo]

@hannahfrost :speech_balloon:

the user will need to have the option to move the content to a different admin set (including the default one)

Yeah, this is the bit that could benefit greatly from some design, IMO. Another option, depending on how visible we want to default admin set to be, would be to toss things into the default admin set if the user does not manually select another admin set as a destination for works that would be orphaned by deletion of their admin set.

[ggeisler]

It sounds like your "another option" above, @mjgiarlo, might also warrant some design thinking (unless the idea is to just automatically toss any objects in a to-be-deleted admin set to the default admin set, which would be easiest to do, but might be too subtle to be good UX?).

So either doing a design or having a developer try to implement it without a design is fine with me; if you want a design just put it in design needed and prioritize it and I'll come up with some ideas.

[mjgiarlo]

Thanks, @ggeisler. Let's see what the peeps most likely to work on this think about it:

@atz @jcoyne @tdonohue if you were working on this issue, would you be comfortable whipping up a PR without a design, or would you prefer we have more design available?

[tdonohue]

Taking a look at this today, it sounds like there are several outstanding questions that a design (or at least finalized user needs) could answer relating to this ticket:

• Can admin sets be deleted if they have content? Or only if empty?
• If it must be empty, we also need a way to bulk move works to a different (or several different) admin set(s).
• If it can be deleted while content exists in it, what happens to the existing content? Does it get auto-moved elsewhere? Is it also deleted? (yikes) Or, are you presented with options for what to do with the content?

My gut says the easiest implementation is likely to require the admin set is empty before it can be deleted. However, that implies we need a separate ticket for bulk moving works between admin sets. We would also need a way to communicate in the UI that an admin set can only be deleted when empty (e.g. grayed out delete button with mouse over text or some better design).

So, in summary here, I don't know we need a full design, but I think we need some decisions on when an admin set is deletable, etc.

[hannahfrost]

@tdonohue Regarding your second bullet, there is already a ticket for that. https://github.com/projecthydra-labs/hyku/issues/347

My sense is a little design work will make it easier to move this forward. I'll work with @ggeisler on that.

[mjgiarlo]

@tdonohue @jcoyne @ggeisler @hannahfrost Let's talk through this in our stand-up today.

[ggeisler]

@tdonohue:

My gut says the easiest implementation is likely to require the admin set is empty before it can be deleted. However, that implies we need a separate ticket for bulk moving works between admin sets. We would also need a way to communicate in the UI that an admin set can only be deleted when empty (e.g. grayed out delete button with mouse over text or some better design).

I agree with this. This ticket will be easier (and have a better UX) if we can assume https://github.com/projecthydra-labs/hyku/issues/347 supports moving Works between admin sets.

[tdonohue]

Claiming. As discussed in standup today, I'll begin this implementation in Sufia. Will implement as described above (only delete admin sets if empty. If non-empty, display a disabled delete button with messaging).

[tdonohue]

A brief update: After running into issues with the Sufia implementation (see https://github.com/projecthydra/sufia/issues/3041), and based on feedback from @jcoyne, I've decided to split this work into two (related) PRs:

1. A basic implementation for Sufia, which is simply a delete button (with no validation that the AdminSet is empty). For Sufia, that will mean that deleting a non-empty AdminSet will simply detach all works from that AdminSet (this behavior is inherited from CC). The basic implementation is in https://github.com/projecthydra/sufia/issues/3041
2. A full implementation for Hyrax, which changes the current behavior of CC/Sufia to first validate that an AdminSet is empty before allowing deletion to occur. This will be in a forthcoming Hyrax PR (based on the Sufia one).