Skip to content

Set worker context

This operation establishes an application session scoped to a worker rather than a specific claim. It reuses the same ChangeContext() pipeline as claim-number and claim-ID entry (security evaluation and subclass retrieval), but the worker-only ClaimContext constructor does not populate ClaimNumber, which changes how claim data resolves in practice.

Field Value
Operation ID OP-AC-02
Trigger Caller calls SetWorkerContext(inWorkerID As Decimal)
Inputs Worker ID (Decimal)
Outputs Active worker-scoped ClaimContext, claim-data lookup attempt, updated ClaimSecurity snapshot, subclass-specific retrieved state
Primary components ClaimAppManager.SetWorkerContext, ClaimAppManager.ChangeContext, ClaimContext, ClaimSecurity, clsClaimData
Entry point Application\SAIF.Application.Claim\ClaimAppManager.vb

Steps

  1. SetWorkerContext(inWorkerID As Decimal) checks inWorkerID > 0.
  2. If true: creates New ClaimContext(0, inWorkerID) (claim ID 0, worker ID inWorkerID) and calls ChangeContext() (step 2).
  3. If false (zero or negative): the method returns without creating a context, calling ChangeContext(), or setting a caller-facing message.* Unlike the two SetClaimContext overloads, there is no Else branch here.
  4. ChangeContext() runs the same pipeline as Set claim context: OnContextChanged(), then OnCheckSecurity(), then OnRetrieve().
  5. OnContextChanged() calls GetClaimData(), which reads Context.ClaimID first.

  6. Because the worker-only constructor sets ClaimID = 0, Context.ClaimID > 0 is false, so GetClaimData() falls through to clsClaimData.GetData(DPI, Context.ClaimNumber) — and Context.ClaimNumber was never assigned for a worker-only context, so it retains its default empty-string value.**

    • Sub-step: clsClaimData.GetData is the same retrieval call embedded in Set claim context.

    Origin: Claim retrieval is implemented by clsClaimData.GetData in SAIF.Business.View.Claim. 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. - Context.WorkerID is never read by GetClaimData() in this library's source, so the worker ID supplied to SetWorkerContext does not directly drive claim resolution in the base ClaimAppManager implementation.** - As in claim-number entry: Message defaults to ClaimAppConstants.CLAIMNOTFOUND and the context is marked not-set; if m_ClaimData.IsValid becomes true, Message clears and MarkContextSet() runs instead. 4. OnCheckSecurity() runs identically to the claim-context flow: ClaimSecurity.CheckClaim(ClaimData) evaluates conflict (BR-001), exposure (BR-002), hostile-worker (BR-003), and health-issue access (BR-004); MarkViewOnly() runs by default, and a failed conflict check falls back to CheckForSecurityOverride(). - Sub-step: CheckForSecurityOverride() delegates to ClaimServices.HasOverrideAcess.

    Origin: The security-override lookup is implemented by ClaimServices.HasOverrideAcess in SAIF.Business. 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. - On a failed override: MarkNoAccess() runs and Message = ConfidentialAccessDeniedMessage (BR-001). 5. OnRetrieve() (abstract) runs in the concrete subclass to load application-specific state for the resolved context; this library does not implement it directly.*

Process flow

The following diagram visualizes worker-context entry, including the claim-number resolution gap described in step 3.

flowchart TD
    Start([Caller invokes SetWorkerContext]) --> Valid{WorkerID > 0?}
    Valid -->|No| NoOp([No context change;<br>no message set])
    Valid -->|Yes| NewCtx[Create ClaimContext<br>ClaimID = 0, WorkerID = input]
    NewCtx --> ChangeContext[ChangeContext]
    ChangeContext --> GetData[GetClaimData:<br>ClaimID = 0, falls back to<br>blank ClaimNumber lookup]
    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 worker ID of zero or less is silently ignored: no context is created, ChangeContext() does not run, and no message is set for the caller — this differs from the explicit PLEASEENTERCLAIM messaging used by the claim-number and claim-ID overloads.*
  • Because GetClaimData() only branches on Context.ClaimID and Context.ClaimNumber, and the worker-only ClaimContext constructor leaves ClaimNumber blank, a worker-context request resolves claim data through a blank claim-number lookup unless a subclass overrides GetClaimData() to use Context.WorkerID directly. Whether any subclass provides such an override could not be confirmed from this library's source.**
  • All security-evaluation and no-access behavior described for Set claim context applies identically once ChangeContext() begins.

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

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