This page is the complete catalog of business rules that govern NDReimbursementWebApp. A rule appears here when it is enforced on a code path the application executes, whether the enforcing code is the application's own page model, manager and start-up code, or behavior inherited from the BolMiddleware and SAIF.NetCore packages. The application has no local libraries and no stored procedures of its own, so there are no library or stored procedure rules in scope.
Every rule heading below is the bare rule ID, so a link such as business-rules.md#br-scr-007 resolves to the rule.
Reachability was traced from the application's entry points: the page handlers of the single NDReimbursement screen, the four hosted endpoints, and the Startup and page-model infrastructure. Behavior of the four API-client packages (NDReimbursementAPI.Client, DigitalPaymentAPIClient, DocumentsCoreAPI.Client, OneIncAPIClient) is not documented anywhere retrievable, so any rules they enforce are unknown**.
Without a current user id, PopulateModel returns false and sets ErrorMessage to "Invalid User"; display is subject to the view condition !IsSuccessful && !HasPolicyNumber.
Capability flags are derived per request, and a user with none of the four NDR roles is denied at the page-level gate (the PopulateModel "Not Authorized" fallback is a defensive branch).
Access to the page requires any one of the four NDR roles: NonDisReimbViewResource, NonDisReimbUpdateResource, NonDisReimbViewExtResource, NonDisReimbUpdateExtResource.
Trigger
Any request to the page
Enforcement
[SecurityApiAuthorize] with arguments on NDReimbursementsModel. The declaration is application code and the evaluation is package code†.
Outcome
The request is denied when the user holds none of the roles (INH-009)
A request without a CurrentUserId is rejected: PopulateModel sets ErrorMessage to "Invalid User" and returns false.
Trigger
PopulateModel
Enforcement
Check in NDReimbursementsModel.PopulateModel
Outcome
No data is loaded. The guard returns before PopulateModel assigns HasPolicyNumber, so that property keeps the earlier value set in OnRequestStart from Header. The view's ErrorMessage block renders only when !IsSuccessful && !HasPolicyNumber, so whether "Invalid User" is displayed depends on that pre-existing value
The page derives the flags IsInternalUpdater, IsExternalUpdater, IsInternalITUser, CanPrint, IsInternalReadOnly and IsExternalReadOnly on every request. A user with none of the four NDR roles is denied first by the page-level [SecurityApiAuthorize] gate, which admits only those four roles, so such a request is ordinarily rejected before PopulateModel. If the fallback branch in PopulateModel is reached, it sets IsInvalidUser and ErrorMessage to "Not Authorized" and returns false; that message is not guaranteed to be displayed (see Outcome).
Trigger
PopulateModel
Enforcement
NDReimbursementsModel.PopulateModel
Outcome
The view is shaped by the flags. The handlers do not enforce the flags (TD-APP-003). In the fallback branch the handler sets the error state only; the view's ErrorMessage block renders only when !IsSuccessful && !HasPolicyNumber, so display depends on the HasPolicyNumber value.
Pending online payments, meaning the NDR flag or a digital-payment count above zero, block the "claims saved" state. A 404 from the digital payment API counts as zero.
When GetPolicyStatements throws an HTTP status exception, the handler sets HasInvalidPolicyNumber and ErrorMessage ("is not a valid policy number" for HTTP 400) and returns false; it does not set HasNDR false. When there are no NDR statements, HasNDR is false and NdrWarningMessage is set.
Trigger
Load
Enforcement
NDReimbursementsModel
Outcome
Handler: flags and messages are set and loading stops. View: the ErrorMessage block renders only when !IsSuccessful && !HasPolicyNumber and HasInvalidPolicyNumber is not referenced, so the invalid-policy message is not rendered while a policy number is present; the warning message shows only when ErrorMessage is empty
Rules that reach the application through base classes and attributes provided by BolMiddleware and SAIF.NetCore.AuthService. They are enforced by inherited behavior, not by code in this repository. The consuming type for every rule is NDReimbursementsModel (or Startup) in this application.
The BOL web context resolves in order: BolContext cookie, re-read cookie, referring application, WebContextId form value or cid query value, session, new context.†
Trigger
Every page request
Enforcement
BolContextModel lifecycle in the base page-model chain
Outcome
The context carries the policy number the screen loads
Policy access is validated through IsValidPolicyForCurrentUser. A failure sets an error message and AccessAllowed = false. Enforcement is soft: the derived page must check AccessAllowed.†
Trigger
Policy header load
Enforcement
BolPolicyModel; the page checks AccessAllowed in Pages/NDReimbursement.cshtml (BR-SCR-011)
Outcome
The claims area is hidden. Handlers do not check the flag.
For external users, policy associations are filtered by user type: POLCY keeps those for the customer id, AGNCY keeps those whose policy AgencyId matches.†
None. The application has no local libraries, so no library-documented rule is excluded. INH-001 to INH-012 are reachable through the page-model base chain, Startup or the SecurityApiAuthorize attribute. The packages DigitalPaymentAPIClient, DocumentsCoreAPI.Client, NDReimbursementAPI.Client and OneIncAPIClient have no retrievable rules, so what they enforce is unknown**.
Note: Statements marked with † are derived from dependency library
documentation via the Legends CLI. Statements marked with ** could
not be confirmed; treat as unknown until verified.