Delete eperson

[artlowel]

References

• Fixes Delete EPerson #730
• Requires [DS-4036] Delete EPersons even if they are referenced DSpace#2928

Description

This PR adds the ability to delete EPersons

Instructions for Reviewers

This PR adds functionality to the pre-existing delete buttons on the EPerson detail page and the EPerson overview.

After clicking a delete button you'll get a confirmation dialog.

This PR will test whether the current user should have the right to delete a certain EPerson before enabling the button using the features and authorizations system. However, there are certain rules in the backend which prevent an EPerson from being deleted, that are only checked after you send the delete request for performance reasons (e.g. you try to delete the only EPerson in a workflow group that has items). In those cases, we can't disable the button ahead of time, instead you'll get an error notification with the message from the backend if you try the delete and it fails.

Reviewers can test this PR by:

• Authenticating as an admin
• Going to Access Control → People from the admin sidebar
• Trying to delete an EPerson from the list
• Trying to delete an EPerson from the edit page
• Verifying that you are asked to confirm the deletion each time
• Verifying that if the delete succeeds you get a success notification
• Verifying that if the delete fails you get an error explaining why

Checklist

• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes TSLint validation using yarn run lint
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• If my PR includes new, third-party dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.

[lgtm-com]

This pull request introduces 1 alert when merging 456551f into a0414e1 - view on LGTM.com

new alerts:

• 1 for Unused variable, import, function or class

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (main@cd6c5b7). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #874   +/-   ##
=======================================
  Coverage        ?   79.77%           
=======================================
  Files           ?     1000           
  Lines           ?    21936           
  Branches        ?     2286           
=======================================
  Hits            ?    17500           
  Misses          ?     3437           
  Partials        ?      999           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cd6c5b7...456551f. Read the comment docs.

[tdonohue]

@artlowel : quick FYI, this looks to have a minor code conflict after I merged #873

[lgtm-com]

This pull request introduces 2 alerts when merging 5615390 into c67d2e6 - view on LGTM.com

new alerts:

• 2 for Unused variable, import, function or class

[tdonohue]

@artlowel : The code looks good overall. No comments there.

However in testing, I found a minor bug when I forced an error to occur. Here's how to reproduce it:

1. Create a new eperson (or use an existing one)
2. Find a Collection that has no workflow yet. Add that EPerson as the only member of a workflow group (it doesn't matter which one)
3. Try to delete that EPerson. An error occurs (as that's expected), but the message says: Error occured when trying to delete EPerson with id: [uuid] with code: 422 and message: OK. The problem is the "OK" in that message.

When looking at the actual response from the REST API (in Chrome DevTools), it has a different message. It shows:

{"timestamp":"2020-10-01T21:23:54.979+0000",
"status":422,
"error":"Unprocessable Entity",
"message":"Unprocessable or invalid entity",
"trace":"[a really long exception]",
"path":"/server/api/eperson/epersons/d32471a1-c625-4598-a75c-64e24fafed29"}

The message here likely should be improved/enhanced (possibly on the backend). But, it's obviously not saying "OK" :)

Beyond that minor bug, everything else seems to be working. I get a confirmation when I try to delete, and I can delete other epersons successfully.

[tdonohue]

👍 I re-tested this today with the backend PR (DSpace/DSpace#2928). The previous bug I reported is now solved. I did find a small bug in the backend PR, but that issue is unrelated to this PR. So, once the backend is ready-to-go, this PR can also be merged.

(NOTE to other reviewers. The red ❌ on this PR can be disregarded, as it's a failure in an optional check. It appears simply because the code coverage of new code in this PR is slightly lower than the percentage on main. However, the overall code coverage still improves, so this PR is good enough as-is.)

Thanks @artlowel and @Raf-atmire !

[atarix83]

@artlowel thanks for the PR

code looks good to me and I've tested the functionality successfully

[tdonohue]

Merging, as the backend PR (DSpace/DSpace#2928) was also just merged. Thanks @artlowel !