Skip to main content

Asset UI Overview

Summary​

The Asset Management user interface is delivered inside the HR Suit React (Vite) single-page-application monorepo. The client-facing surface lives in the client-hrms-portal application. The asset experience is not a standalone module: it is presented as a single tab (module="asset") of the shared HR Operations page, complemented by an employee self-service view. The UI communicates with monolith-shaped compatibility endpoints rather than calling the asset service natively, and its maturity is classified as partial.

Audience​

  • Developers integrating with or extending the asset UI surface.
  • QA engineers validating the two asset entry points.
  • Support engineers triaging asset UI behaviour.
  • Solution architects assessing frontend/backend boundaries.
  • Security engineers reviewing frontend versus backend enforcement.
  • Product owners and implementation partners scoping asset capabilities.

Reference Content​

Framework and application​

The asset UI is built on React with Vite as part of a monorepo. The client portal application (apps/client-hrms-portal) hosts all asset screens. There is no dedicated asset micro-frontend; the asset views are composed from shared page primitives.

Two entry points​

Entry pointRoutePage/componentAudience
Admin asset management/hr-operations/assetsHrOperationsAssetsPage (HrOperationsPage, module="asset")Admin / manager
Employee self-service/assetsEssAssetsPageEmployee

There are exactly two asset routes. A legacy hash route (asset) redirects to /hr-operations/assets. Both routes are wrapped with protectedPage(<ProtectedRoute>).

Asset UI as an HR Operations tab plus ESS​

The admin asset surface renders as the asset tab of HrOperationsPage, titled "Asset Management" (or "My Asset Requests" for employee-only contexts). The employee surface is a read-only self-service list page. This shared-page composition means asset functionality inherits the HR Operations workspace loading and shell behaviour rather than owning a bespoke layout.

Native versus compatibility​

The frontend talks to monolith-shaped compatibility endpoints (the HR Operations workspace, asset request creation, asset status changes, and asset deletion). It does not invoke the asset service through native asset APIs. A gateway asset-routing feature flag can transparently route the asset slice to the asset service, but the frontend is unchanged by that cutover.

Maturity and confirmed exclusions​

The implementation status is partial. The following are verified as absent from the UI and must not be assumed present:

  • No dedicated asset detail route or detail view.
  • No dedicated assignment screen (assignment is via the form's Assign To field plus approve to Issued).
  • No return, damage, loss, or retire controls.
  • No in-UI document upload, list, or download.
  • No audit or timeline viewer.
  • No reservation UI.
  • No bulk actions beyond Excel import.
  • No client-side pagination control tied to real API paging.

UI architecture​

Source References​

  • UI/salary-ui/apps/client-hrms-portal/src/App.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/pages/hr/HrOperationsPage.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/ess/EssPages.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/components/AppLayout.tsx

See Also​

Keywords​

asset ui, hr operations tab, self service, compatibility endpoints, partial maturity

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-17
  • Review cycle: Quarterly