JCU/Prevent an admin from deleting their own account

[Kasinhou]

Backport of #1306 (68463d490f) from dtq-dev onto customer/jcu.

EPersonServiceImpl.delete() now refuses to delete the EPerson that is the current context user (unless authorization is being ignored, e.g. CLI/consumers), and EPersonRestRepository maps that IllegalStateException to a 400 Bad Request carrying the message, so the UI can show a friendly notification instead of a generic failure.

Verified locally: mvn -o checkstyle:check -pl dspace-api,dspace-server-webapp clean; mvn -o compile -pl dspace-api clean.

Refs dataquest-dev/dspace-customers#855

Frontend counterpart: dataquest-dev/dspace-angular#1447 — the two must ship together.

---

How this was verified

Automated — runs on this PR

The change ships with an integration test that drives the real REST API:
EPersonRestRepositoryIT#deleteYourselfForbidden logs in as an administrator, calls
DELETE /api/eperson/epersons/{own-id}, asserts 400, then asserts the account still exists.

The Run Integration Tests CI job is green on this PR, and its log shows the class executing:

Tests run: 93, Failures: 0, Errors: 0, Skipped: 0 - in org.dspace.app.rest.EPersonRestRepositoryIT

The base branch has 92 @Test methods in that class — the 93rd is this one.
Locally: mvn -o checkstyle:check -pl dspace-api,dspace-server-webapp → 0 violations.

Manual — on a live instance

Throwaway DSpace 9.3 stack (own DB / Solr / assetstore, REST on :8091), logged in as an administrator:

Backend	Request	Result
without the fix	DELETE /server/api/eperson/epersons/<own uuid>	204, and a follow-up GET → 404. The admin deleted their own account.
with the fix	the same request	400 Bad Request, follow-up GET → 200. The account survives.
with the fix	delete a different EPerson	still works — row disappears from the list

This branch is the one exercised live above.

Reviewer note — the message does not reach the client

The source commit intended to "allow client to see the error message", but the 400 body is DSpace's generic
{"status":400,"error":"Bad Request","message":"An exception has occurred"} — the text
"You, as admin user, cannot delete yourself" never reaches the browser, because
DSpaceBadRequestException is annotated @ResponseStatus(reason = "Bad Request").

This does not weaken the fix: the deletion is refused server-side either way, and the frontend does not
depend on that string (it decides from its own identity check). Flagging it so nobody later builds on the
assumption that the message is visible.

[Copilot]

Pull request overview

Prevents an administrator from deleting the currently-authenticated EPerson via the REST API, protecting the platform from accidental “self-delete” lockouts while still allowing deletion when authorization is intentionally bypassed (e.g., CLI/consumers).

Changes:

• Add a guard in EPersonServiceImpl.delete() to reject deleting the current context user (when authorization is enforced).
• Map that refusal to an HTTP 400 in EPersonRestRepository (instead of 422).
• Add an integration test covering “admin tries to delete self” and ensuring the account remains accessible afterward.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
dspace-api/src/main/java/org/dspace/eperson/EPersonServiceImpl.java	Adds server-side protection against deleting the current context user.
dspace-server-webapp/src/main/java/org/dspace/app/rest/repository/EPersonRestRepository.java	Translates the service-layer refusal into an HTTP 400 response.
dspace-server-webapp/src/test/java/org/dspace/app/rest/EPersonRestRepositoryIT.java	Adds an integration test asserting self-delete is rejected and the account still exists.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.