Add delete accounts ability to hubs admin panel

[robinkwilson]

In the admin panel > Accounts > Click trash icon to delete one account Similar to the bulk add accounts create a bulk delete account text field

API Endpoint considerations

DELETE request options:

• Admin only endpoint + header
• Delete using email
• Delete using accountId
• Delete accounts with matching identity(s)

DELETE Data returned options:

• Returns list of successfully deleted account ids
• Returns list of successfully deleted emails
• Returns map of identities + list of account ids or emails that were deleted by that identity

Considerations

If deleted account is room owner, what happens to the ownerless room?

If deleted account has published/drafted spoke scenes, what happens to these ownerless spoke scenes?

Potential solutions

Ownerless rooms

Next user that accesses this room is the owner

Next admin user that accesses this room is the owner

Admin account is the owner

Admin accounts have the ability to delegate the ownerless rooms or delete them

Ownerless spoke scenes

Next user that accesses the spoke scene

Automatically assigned to the admin account

Automatically assigned to the admin accounts to delegate who owns these scenes or to delete them

Potential UI adds

• Text field in admin panel > Accounts menu for bulk delete
• Create admin managed deleted owner scenes + rooms to reassign owner or delete menu ** If this option, there could be another menu that collects this waiting for reassignment, like a notification tab or TODO tab highlighted in the admin panel - might be complicated and out of scope

References other github issues: https://github.com/mozilla/hubs-cloud/issues/44 https://github.com/mozilla/hubs-cloud/issues/59 https://github.com/mozilla/hubs/issues/2314

┆Issue is synchronized with this Jira Task

[misslivirose]

I would imagine that the scenes that a user has abandoned would be left in their existing state without an owner for the original listing. There isn't a concept of "accessing the spoke scene" - it's important that we draw the distinction between the Spoke project and the scene itself. I don't see a problem with leaving a scene listing without an active owner account off the top of my head, but I could be missing something.

I would think that if a user account is deleted, their Spoke projects would remain in the database, but not accessible by any other users.

The room ownership is, I think, the most challenging to transfer here. Another option that isn't listed is the possibility (I think the work that @johnshaughnessy was looking at might touch on this) that we close rooms that are owned by a deleted account. I think that's a fairly destructive option, but then again, we are talking about deletion. :)

I am not convinced that automatically assigning the rooms to the administrator of the instance is the right call (what if there are more than one admins? Do we actually have a way to differentiate, or would they be assigned at random?) and similarly, I think we'd be expanding the feature matrix significantly to try and implement room ownership transfer capabilities at this time (what if the user someone tried to transfer to didn't have an account?). So I'm inclined to have the rooms inherit the existing "no owner" behavior (for example, rooms that are created without a signed in user) instead of doing something fancy here, but I think it merits further discussion.

[netpro2k]

We also need to consider what to do for Avatars that the user owned. It's a bit more complicated since avatars are a merged set of everything in their hierarchy (we don't duplicate the gltfs/images).

More generally users have OwnedFiles associated with their account. This is used for directly uploaded objects in Hubs/Spoke, Avatars, Scenes, etc. They may exists as pinned objects in a room, entries in a spoke scene, textures on an avatar, etc. It's pretty unclear what would be the correct behavior for deleting these. Simply making them owned by nobody is a bit concerning in terms of usage quotas.

[robinkwilson]

Users might be concerned about storage costs and want to delete the storage. Others might want to keep them around. Not sure what the retrieval process would be like.

Maybe there's an option when deleting the accounts that the admin can select, like a checkbox defaulting to unchecked:

• Checked delete account owned avatars VS Unchecked keep avatars in db
• Checked delete account owned files / pinned files / created rooms VS Unchecked keep files in db
• Checked delete account owned spoke projects VS unchecked keep spoke projects

[netpro2k]

Hmm yeah I guess since this is going to be an admin only feature, exposing it like that could work. Still unsure on the technical side if having these things with null account references is going to be an issue. Possible if they don't check all the boxes we suggest they just deactivate the account instead and you have to manually check all the boxes to actually delete the account.

[robinkwilson]

@netpro2k @misslivirose

Looking at the code, maybe dealing with dependencies -- handling scene deletion + avatar deletion + pinned file deletion -- first, might be best then tackling deleting accounts and has less dependencies to loop through. For now we can integrate deactivating accounts.

The use case I'd like to enable and the one we're getting requests for is:

Remove people's access to the hub after they have an account. Week1 cohort is added to hub, week1 event happens, then disable those week1 cohort accounts' access and add week2 cohort accounts.

Simple options for accounts feature for time being:

1. An admin can deactivate accounts in a batch or single request. Seems to be the simplest solution for now and ties into # 2 below. I'd look at how we implemented the scenes deactivation and follow that pattern.
2. An admin can delete all accounts without dependencies (likely most accounts for the above use case)
   • Accounts with dependencies can only be deactivated (scenes, pinned files in scenes, avatars). Once those dependencies are deleted or ownership is transferred, then the admin can delete those accounts.

What do you think about integrating # 1 as an MVP? With # 2 being a goal for after managing deleting scenes, projects, avatars? Let me know if I'm missing anything.

[misslivirose]

If we aren't actually implementing the ability to delete accounts, I think the fastest route forward is to just remove the 'delete' button from the panel as has been suggested. Alternatively, rename the 'Delete' button to 'Deactivate' and have it deactivate the accounts as specified.

[netpro2k]

Yep that's the path I would take first, getting rid of all the delete buttons in the admin panel. Have had it on my todo list for awhile but haven't gotten to it.

[robinkwilson]

https://github.com/mozilla/hubs/pull/2613 PR in /hubs for removing the delete buttons.

[yengalvez]

As I see is impossible to delete users. But... Why not to hide them? At least we can have it clean on the panel. Thanks