Deleting a user does not remove assigned roles

[Falco-KUB]

What steps does it take to reproduce the issue?

• When does this issue occur?

1. Assign a role to user within a Dataverse Collection.
2. Delete the user.
3. Try to create a new subcollection.
   while :InheritParentRoleAssignments is true for the parent collection.

• Which page(s) does it occurs on?
  Create new Dataverse.

• What happens?
  

• To whom does it occur (all users, curators, superusers)?
  Anyone with the permission to create a new Dataverse Collection.

• What did you expect to happen?
  Deleting a user should properly remove all assigned roles (or at least give a warning).
  The assigned role was only visible through the API, and not in the UI.
  Removing the assigned role manually via API fixed the error.

Which version of Dataverse are you using?
6.1

Any related open or closed issues to this bug report?

Screenshots:

No matter the issue, screenshots are always welcome.

To add a screenshot, please use one of the following formats and/or methods described here:

• https://help.github.com/en/articles/file-attachments-on-issues-and-pull-requests

Are you thinking about creating a pull request for this issue?
Help is always welcome, is this bug something you or your organization plan to fix?

[qqmyers]

How are you deleting a user? (The API should be checking for role assignments and returning a Bad Request error if there are any.)

[Asbjoedt]

Hi!

I deleted the user in the database, and here you get prompted to delete all foreign key constraints in other tables before you can delete the user. So that was the method.

I did so, because I thought there was no API for deleting users however, after rereading there indeed is under certain conditions, according to documentation:

Note: If the user has performed certain actions such as creating or contributing to a Dataset or downloading a file they cannot be deleted.

There's also this in the documentation:

Note: A primary purpose of most Dataverse installations is to serve an archive. In the archival space, there are best practices around the tracking of data access and the tracking of modifications to data and metadata. In support of these key workflows, a simple mechanism to delete users that have performed edit or access actions in the system is not provided. Providing a Deactivate User endpoint for users who have taken certain actions in the system alongside a Delete User endpoint to remove users that haven’t taken certain actions in the system is by design.

To be honest I didn't first try the delete user API endpoint. Also, for our specific use case I think we should just haver merged the accounts, because it was a case of same user as both local user and a Shibboleth auth user.

This one is on me I think, guys. Sorry!

[pdurbin]

Ah, yes, in this case it sounds like merging would have worked.

I dunno, deleting users from the database is not recommended. Maybe we can close this issue, now that we understand better what happened?

[Falco-KUB]

Sure, sorry for the disturbance.

[qqmyers]

FWIW - I found that roleassignment table odd as well - the one place we refer to a user that doesn't use a foreign key.