Skip to content

Deny self-registration check

This operation manages the EXT_USER_DENY_SELF_REG block list. Registration validators call it to determine whether a user-type and source-system group combination is allowed to self-register, and administration flows use the same object model to insert, update, or delete deny-list rows.

Field Value
Operation ID OP-EU-02
Trigger Registration validation or deny-list maintenance request
Inputs User-type code, source-system group ID, customer-requested flag, reason text
Outputs Matching deny-list row(s) or persisted EXT_USER_DENY_SELF_REG change
Primary components clsUserDenySelfRegistration.GetUserDenySelfRegistration, clsUserDenySelfRegistrationCollection.GetUserDenySelfRegistrations
Entry point Business\SAIF.Business.External.Users\clsUserDenySelfRegistration.vb

Steps

  1. Build the lookup key from the registration context. Callers supply the external-user type code and the customer-group identifier that represents the group being registered.
  2. Retrieve an existing deny-list row when the exact pair is needed. GetUserDenySelfRegistration reads the row keyed by CUSTOMER_GROUP_ID and EXT_USER_TYPE_CODE (SQL-027, EXT_USER_DENY_SELF_REG).
  3. Retrieve all matching rows for validation scenarios. GetUserDenySelfRegistrations runs the same keyed filter as a collection load so registration validators can test Count > 0 (BR-EU-02, SQL-027, EXT_USER_DENY_SELF_REG).
  4. Use the result to block registration when a row exists. clsNewUserArgs calls this collection helper for agency, provider, policyholder, and injured-worker registrations; any returned row causes the validator to return False and leave an error message on the caller (BR-EU-02).
  5. Insert a new deny-list row when administration adds a block. BeforeInsert stamps create/update metadata and inserts the user type, group ID, customer-requested flag, and reason text (SQL-007, EXT_USER_DENY_SELF_REG).
  6. Update an existing row with optimistic concurrency. BeforeUpdate rewrites the same fields and increments UPDATE_NUM; a zero-row result surfaces as a DB-contention error (BR-EU-05, SQL-048, EXT_USER_DENY_SELF_REG).
  7. Delete a deny-list row when the block is removed. BeforeDelete deletes by the same composite key (SQL-054, EXT_USER_DENY_SELF_REG).

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Registration or admin request]) --> Lookup[Load deny-list rows for type and group]
    Lookup --> Match{Match found?}
    Match -->|Yes| Block([Registration blocked or row opened for maintenance])
    Match -->|No| Allow([Registration may continue or admin may add a row])
    Allow --> Save{Persist change?}
    Save -->|Insert or update| Write[Write deny-list row]
    Save -->|Delete| Delete[Remove deny-list row]
    Write --> Done([Return persisted result])
    Delete --> Done
    Block --> Done

Failure and edge-case behavior

  • The composite key means one deny-list row governs one user-type and customer-group combination.
  • Updates and deletes can fail with DB-contention messaging when another session changed the same row first (BR-EU-05).
  • Registration callers treat any matching row as a hard block; there is no partial-warning path in the traced code.

Sources

  • Business\SAIF.Business.External.Users\clsUserDenySelfRegistration.vb
  • Business\SAIF.Business.External.Users\clsNewUserArgs.vb