Skip to content

Set claim context

This operation establishes a claim-scoped session for a ClaimAppManager subclass. The caller supplies either a claim number or a claim ID; the manager creates a ClaimContext, loads the corresponding claim data, evaluates the caller's security access to that claim, and finally invokes the subclass-specific retrieval logic.

Field Value
Operation ID OP-AC-01
Trigger Caller calls SetClaimContext(inClaimNumber As String) or SetClaimContext(inClaimID As Decimal)
Inputs Claim number (String) or claim ID (Decimal)
Outputs Active ClaimContext, populated clsClaimData, updated ClaimSecurity snapshot, subclass-specific retrieved state, and a caller-facing Message
Primary components ClaimAppManager.SetClaimContext, ClaimAppManager.ChangeContext, ClaimContext, ClaimSecurity, clsClaimData
Entry point Application\SAIF.Application.Claim\ClaimAppManager.vb

Steps

  1. SetClaimContext(inClaimNumber As String) checks inClaimNumber.Trim.Length > 0.
  2. If true: creates New ClaimContext(inClaimNumber) and calls ChangeContext() (step 3).
  3. If false (blank input): clears m_ClaimData, calls MarkContextNotSet(), and sets Message = ClaimAppConstants.PLEASEENTERCLAIM (BR-006). ChangeContext() is not invoked on this path.
  4. SetClaimContext(inClaimID As Decimal) checks inClaimID > 0.
  5. If true: creates New ClaimContext(inClaimID, 0) and calls ChangeContext() (step 3).
  6. If false (zero or negative): clears m_ClaimData, calls MarkContextNotSet(), and sets Message = ClaimAppConstants.PLEASEENTERCLAIM (BR-006). ChangeContext() is not invoked on this path.
  7. ChangeContext() runs the context-change pipeline in a fixed order: OnContextChanged(), then OnCheckSecurity(), then OnRetrieve().
  8. OnContextChanged() loads claim data for the new context:
  9. Calls GetClaimData(), which reads Context.ClaimID; if it is greater than zero, it retrieves the claim through clsClaimData.GetData(DPI, Context.ClaimID), otherwise through clsClaimData.GetData(DPI, Context.ClaimNumber).

    Origin: Claim retrieval by ID or claim number is implemented by clsClaimData.GetData in SAIF.Business.View.Claim, executed on behalf of this operation. That library is documented in the previous format, so no per-operation page exists; see Retrieve claim summary data in the SAIF.Business.View.Claim documentation set. - Sets Message = ClaimAppConstants.CLAIMNOTFOUND and calls MarkContextNotSet() by default. - If m_ClaimData.IsValid is true: clears Message and calls MarkContextSet() instead. - On failure (claim not found or invalid): the context remains not-set and Message retains CLAIMNOTFOUND. 5. OnCheckSecurity() evaluates the caller's access to the loaded claim: - Calls ClaimSecurity.CheckClaim(ClaimData), which evaluates conflict access (BR-001), exposure access (BR-002), hostile-worker/secure-claim access (BR-003), and health-issue access (BR-004) against the claim's flags. - Calls MarkViewOnly() unconditionally as the default post-security role.

    Origin: MarkViewOnly() sets the single effective application security role defined by AppManagerBase in SAIF.Application. That library is documented in the previous format, so no per-operation page exists; see Security role assignment in the SAIF.Application documentation set. - If ClaimSecurity.ConflictAccess is false: calls CheckForSecurityOverride(). - Sub-step: CheckForSecurityOverride() delegates to ClaimServices.HasOverrideAcess(DPI, ClaimData.ClaimID, SecurityPrincipal.UserName.ToString).

    Origin: The security-override lookup is implemented by ClaimServices.HasOverrideAcess in SAIF.Business, backed by an override-security table read. That library is documented in the previous format, so no per-operation page exists; see Claim authorization and visibility checks (step 4, SQL-014) in the SAIF.Business documentation set. - If the override check also returns false: calls MarkNoAccess() and sets Message = ConfidentialAccessDeniedMessage (BR-001). - If the override check returns true: no-access is not applied; the caller keeps the view-only role assigned in the previous bullet. 6. OnRetrieve() is abstract in ClaimAppManager and executes only in the concrete subclass, which loads its own application-specific state for the now-validated claim context. This library does not implement OnRetrieve() itself.*

Process flow

The following diagram visualizes the claim-context-entry control flow.

flowchart TD
    Start([Caller invokes SetClaimContext]) --> Valid{Claim number or ID valid?}
    Valid -->|No| Blocked([Context not set;<br>PLEASEENTERCLAIM message])
    Valid -->|Yes| NewCtx[Create ClaimContext]
    NewCtx --> ChangeContext[ChangeContext]
    ChangeContext --> GetData[GetClaimData via<br>clsClaimData.GetData]
    GetData --> IsValid{ClaimData.IsValid?}
    IsValid -->|No| NotFound([Context not set;<br>CLAIMNOTFOUND message])
    IsValid -->|Yes| ContextSet[MarkContextSet]
    ContextSet --> CheckSecurity[CheckClaim: conflict,<br>exposure, hostile, health-issue]
    CheckSecurity --> ViewOnly[MarkViewOnly]
    ViewOnly --> Conflict{ConflictAccess false?}
    Conflict -->|No| Retrieve[OnRetrieve in subclass]
    Conflict -->|Yes| Override{Security override granted?}
    Override -->|Yes| Retrieve
    Override -->|No| NoAccess([MarkNoAccess;<br>confidential-access message])

Failure and edge-case behavior

  • A blank claim number or a claim ID that is zero or negative leaves the manager out of context and sets Message = PLEASEENTERCLAIM; ChangeContext() never runs for these inputs (BR-006).
  • A claim number or ID that resolves to no row (or an invalid clsClaimData) leaves the context marked not-set with Message = CLAIMNOTFOUND, and OnCheckSecurity()/OnRetrieve() still execute against the unpopulated claim data since ChangeContext() does not short-circuit after OnContextChanged().*
  • A conflict claim without conflict access and without an override is marked NoAccess and returns ConfidentialAccessDeniedMessage, which names the responsible adjuster and phone number when available, or the generic ERRORCONFIDENTIALCLAIM message otherwise.
  • OnRetrieve() has no base implementation; if a subclass does not override it, no application-specific data is loaded even though the context and security state are otherwise valid.*

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

Sources

  • Application\SAIF.Application.Claim\ClaimAppManager.vb
  • Application\SAIF.Application.Claim\ClaimContext.vb
  • Application\SAIF.Application.Claim\ClaimSecurity.vb
  • Application\SAIF.Application.Claim\ClaimAppConstants.vb