Skip to content

Load screen

Steps

  1. The path base and empty route direct the request to the NDReimbursement page (BR-APP-008).
  2. The Security API role check admits users holding any of the four NDR roles (BR-APP-001, INH-009, INH-010, INH-011, INH-012) †.
  3. The inherited page model resolves the web context and policy header (INH-001, INH-002, INH-003, INH-004, INH-005, INH-006, INH-007) †. 3a. OnGet calls PopulateModel only when the web context policy number is nonblank. Otherwise it sets HasPolicyNumber to false and returns the page without loading statements (no-policy state).
  4. PopulateModel rejects a missing user (BR-APP-002): it sets "Invalid User" and returns before assigning HasPolicyNumber, which keeps its earlier OnRequestStart value, so the message is displayed only if !IsSuccessful && !HasPolicyNumber holds. It then derives the capability flags (BR-APP-003); a user with no NDR role is ordinarily denied by the step 2 gate, and the defensive fallback only sets IsInvalidUser and "Not Authorized" state.
  5. The page loads statements for the policy. On an HTTP status exception (HTTP 400 is the invalid-policy case) the handler sets HasInvalidPolicyNumber and ErrorMessage and returns false; it does not set HasNDR false, and the view does not reference HasInvalidPolicyNumber. No NDR statements gives HasNDR false and a warning message (BR-SCR-009).
  6. The page computes the due-date state (BR-SCR-001), claim editability and cash-flow flags (BR-SCR-003, BR-SCR-004), reimbursable claims (BR-SCR-006), pending online payments (BR-SCR-008) and developer-access options (BR-SCR-010).
  7. If loading throws, OnGet catches the exception, logs it, sets HasPolicyNumber and IsSuccessful to false and sets an error message; the page is still returned.
  8. The view renders the claims area only when a policy, an NDR statement and access are all present (BR-SCR-011). When access is not allowed, the claims area is simply not rendered; this does not set HasNDR false or a warning, which belong only to the no-statements path in step 5.

Process flow

The diagram shows how a request is authorized, the no-policy, load-error, no-statements (HasNDR false with a warning) and denied-access (claims area not rendered) outcomes, and that the claims area is rendered only when the policy, an NDR statement and access are all present.

flowchart TD
    A["Request"] --> B{"Has an NDR role?"}
    B -- No --> C["Access denied †"]
    B -- Yes --> D["Resolve context †"]
    D --> P{"Policy number present?"}
    P -- No --> N["No-policy state, no statements loaded"]
    P -- Yes --> E{"User id present?"}
    E -- No --> F["ErrorMessage set to<br>Invalid User,<br>loading stops"]
    E -- Yes --> G["Load statements"]
    G -- "Exception caught" --> X["Error message, no claims"]
    G -- "HTTP status exception" --> Y["HasInvalidPolicyNumber and<br>ErrorMessage set,<br>HasNDR unchanged,<br>loading stops"]
    G --> H{"NDR statements present?"}
    H -- No --> I["HasNDR false,<br>warning message set,<br>claims area not rendered"]
    H -- Yes --> K{"AccessAllowed?"}
    K -- No --> Z["Claims area not rendered"]
    K -- Yes --> J["Render claims area"]

Note: Statements marked with † are derived from dependency library documentation via the Legends CLI. They describe inherited behavior from the indicated origin library and should be verified if the dependency version changes.

Sources

  • src/NDReimbursementWebApp/Pages/NDReimbursement.cshtml.cs
  • src/NDReimbursementWebApp/Pages/NDReimbursement.cshtml
  • src/NDReimbursementWebApp/Managers/NDR/NDReimbursementManager.cs
  • src/NDReimbursementWebApp/Startup.cs