Skip to content

Delete Active Directory user

DeleteUser removes the AD entry currently referenced by m_DirUser — the account established at construction or by a prior call to Switch active user context. It is a destructive, unconditional operation with no confirmation or dependency checks before the delete.

Field Value
Operation ID OP-SU-05
Trigger Caller calls clsSystemUser.DeleteUser()
Inputs The current m_DirUser context; no explicit parameters
Outputs Boolean result
Primary components clsSystemUser.DeleteUser()
Entry point Business\SAIF.Business.Security.SystemUser\clsSystemUser.vb

Steps

  1. Delete the directory subtree. Inside a Try block, DeleteUser calls m_DirUser.m_DirEntry.DeleteTree(), which removes the entry and any child objects beneath it.
  2. Commit the delete. m_DirUser.m_DirEntry.CommitChanges() is called immediately after DeleteTree().
  3. Report success. If both calls complete without raising an exception, isOkay is set to True.
  4. Report failure. If DeleteTree() or CommitChanges() raises an exception, it is caught, isOkay is set to False, and the exception is swallowed — no ApplicationException is thrown and no exception detail is surfaced to the caller.*
  5. Return the outcome. The method returns isOkay.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Caller calls DeleteUser]) --> Delete[m_DirUser.m_DirEntry.DeleteTree]
    Delete --> Commit[CommitChanges]
    Commit --> Success([Return True])
    Delete -.exception.-> Catch[Catch exception]
    Commit -.exception.-> Catch
    Catch --> Fail([Return False; exception swallowed])

Failure and edge-case behavior

  • Any failure during the delete or commit — including a missing or already-deleted entry, permission errors, or connectivity issues — is reduced to a bare False return; the underlying exception detail is discarded rather than logged or wrapped.*
  • The operation acts on whatever m_DirUser currently references; if no user was successfully loaded (e.g., a prior Switch active user context call failed and left a stale or null reference), the behavior of DeleteTree() against that state is not explicitly guarded in this method.*
  • There is no check for dependent objects, active sessions, or business preconditions (such as pending claims or payments tied to the account) before deletion — the delete is unconditional once called.

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts.

Sources

  • Business\SAIF.Business.Security.SystemUser\clsSystemUser.vb