Package io.meeds.social.security.service
Class AccountDeletionService
java.lang.Object
io.meeds.social.security.service.AccountDeletionService
Executes the account deletion requests recorded by
AccountDeactivationService, once their grace delay elapsed. This
service starts no transaction on its own: the caller (the job) owns the
container lifecycle, and the batch commits one transaction per processed
account — marker removal and deletion together — so the processing stays
idempotent without any cluster lock: a concurrent or replayed run finds no
marker once an account's transaction is committed, and the deletion itself
(social identity soft-deleted then IDM user removed, mirroring the users
administration deletion) is a no-op once the IDM user is gone.-
Field Summary
Fields -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionvoiddeleteAccount(String username) Deletes the account the way the users administration does: the social identity is soft-deleted first, then the IDM user is removed without broadcast — this ordering prevents any concurrent by-username resolution from resurrecting the deleted identity while the IDM user still exists.booleanprepareDeletion(String username) Re-checks the eligibility of one recorded request and, when the account has to be deleted, removes the request marker — committed together with the deletion in the per-account transaction controlled by the caller — so a replayed run finds nothing to do.voidprocessPendingDeletionRequestOf(String username) voidProcesses all the recorded deletion requests: collects the pending requesters first (the enumeration must not be paged over while its rows get deleted), then handles each account independently so one failure never prevents the other deletions.
-
Field Details
-
ACCOUNT_DELETED_EVENT
- See Also:
-
-
Constructor Details
-
AccountDeletionService
public AccountDeletionService()
-
-
Method Details
-
processPendingDeletionRequests
public void processPendingDeletionRequests()Processes all the recorded deletion requests: collects the pending requesters first (the enumeration must not be paged over while its rows get deleted), then handles each account independently so one failure never prevents the other deletions. The current transaction is committed and reopened after each account, so the batch never accumulates one big transaction and a mid-batch failure never rolls back the already processed accounts. -
processPendingDeletionRequestOf
- Throws:
Exception
-
collectPendingRequests
-
prepareDeletion
Re-checks the eligibility of one recorded request and, when the account has to be deleted, removes the request marker — committed together with the deletion in the per-account transaction controlled by the caller — so a replayed run finds nothing to do. The marker is also cleaned up for requests that can never execute anymore (revoked by an admin re-activation, user already gone, externally synchronized account or unreadable marker). Deliberately not re-checked: the admin deletion option — the request was confirmed by its user under an enabled policy, turning the option off only prevents new requests.- Returns:
- true when the account deletion must proceed
- Throws:
Exception
-
deleteAccount
Deletes the account the way the users administration does: the social identity is soft-deleted first, then the IDM user is removed without broadcast — this ordering prevents any concurrent by-username resolution from resurrecting the deleted identity while the IDM user still exists. The user content (activities, comments, documents...) is preserved by design and keeps being displayed.- Throws:
Exception
-