Skip to content

User search

This operation runs the dynamic user-search query exposed by clsUserCollection.GetUsers(...). It starts from the base EXT_USER projection, joins the related person, user-type, company, access-group, and email tables, and appends only the predicates that the caller supplied.

Field Value
Operation ID OP-EU-10
Trigger Search UI or support workflow submits user-search criteria
Inputs Test-user flag, access-group code, customer ID, partial AD ID, partial email, partial name, status code, user-type code, optional row limit
Outputs Collection of matching clsUser rows
Primary components clsUserCollection.GetUsers(inDPI, inAccessGroupCode, inCustomerID, ...)
Entry point Business\SAIF.Business.External.Users\clsUser.vb

Steps

  1. Start from the base user projection. The search method uses the same core clsUser.Criteria.RetrieveSqlStatement projection that normal user retrieval uses, swapping the search placeholder for company name text.
  2. Join the related search tables. The query adds left joins to PERSON, EXT_USER_TYPE, EXT_USER_ACCESS_GROUP, COMPANY, PERSON_EMAIL, and EMAIL_ADDRESS so name, company, access-group, and email filters can be applied (SQL-020, EXT_USER, PERSON, EXT_USER_TYPE, EXT_USER_ACCESS_GROUP, COMPANY, PERSON_EMAIL, EMAIL_ADDRESS).
  3. Apply the required test-user filter first. Every search binds :TestUserFlag and restricts the result set to either test users or non-test users.
  4. Append optional filters only when the caller supplied them.
  5. Partial AD user IDs become upper(active_directory_id) like :ActiveDirectoryID.
  6. Access-group filters match g.ext_user_access_group_code exactly.
  7. Customer filters match t.customer_id exactly and also search credential_1_id with a wildcard pattern.
  8. Partial email filters match lower(e.email_address) like :Email.
  9. Partial name filters search first name, last name, or company name.
  10. Status and user-type filters match their exact stored codes.
  11. Apply an optional row limit after the dynamic query is assembled. When the caller supplied inRowLimit, the method wraps the search and appends where ROWNUM <= ....
  12. Load the resulting rows into clsUser objects. col.Load(...) runs the dynamic SQL and returns the materialized collection to the caller.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Search request]) --> Base[Build base user query]
    Base --> AddFilters[Append only the supplied filters]
    AddFilters --> Limit{Row limit supplied?}
    Limit -->|Yes| Wrap[Apply ROWNUM limit]
    Limit -->|No| Execute[Execute query]
    Wrap --> Execute
    Execute --> Done([Return matching users])

Failure and edge-case behavior

  • Customer-ID search always includes the credential_1_id fallback pattern in the traced path because searchOnlyIW is hard-coded to False.
  • A row limit truncates the search after the filter set is built; it does not change which predicates are applied.
  • Because the query uses left joins, missing related person, company, or email rows do not exclude the base user row unless the caller filtered on those values.

Sources

  • Business\SAIF.Business.External.Users\clsUser.vb