Asset Command View
The asset detail page is the one-page operating view for a single asset. It puts identity, current responsibility, lifecycle dates, service health, permitted financial facts, record quality, and the complete activity conversation into one responsive page. There are no tabs to hunt through: the most urgent context and next action stay near the top, while supporting facts remain available in the detail rail.
ams/assets/view/{id}, where the id is encoded rather than the raw database id.
The Assets module must be enabled and the viewer must hold the base asset
permission. An invalid or missing encoded id returns a not-found page instead of opening a
different asset.
How the page is organised
The page deliberately reads in operational order:
- Identity header — recognise the asset and take the most relevant permitted action.
- Attention strip — see exceptions that need follow-up now.
- Operational cards — understand responsibility, lifecycle, service, finance, and disposal.
- Detail rail — check specifications, custom data, accessories, quality, and provenance.
- Activity & comments — read and continue the asset's chronological record.
Identity header
The header is designed to answer “am I looking at the right asset?” before anything else. It shows the asset photo when one is stored, with a cube placeholder when it is not, followed by the asset tag, title, and any available status, condition, location, category, description, and labels. Missing optional facts are omitted rather than replaced by misleading values.
The action area chooses the best eligible next step as the prominent button. Other eligible actions move into the Actions dropdown. A read-only viewer can therefore see the same asset context without being offered operations they cannot perform.
Attention strip
The strip appears only when the asset has an actionable exception. Each item names the condition and includes its useful context, such as the due date, disposal reference, or quality score.
| Attention item | When it appears |
|---|---|
| Acceptance pending | A released or pending-acceptance custody has not yet been accepted. |
| Return overdue | The current custody due date has passed. |
| Open issues | One or more unresolved service issues are linked to the asset. |
| Open work orders | One or more maintenance records are still in an open workflow state. |
| Audit overdue | The next audit date has passed. |
| Warranty expiring or expired | The warranty is inside the configured reminder window or has already ended. |
| Disposal waiting | An open disposal exists and the viewer may see disposal details. |
| Low record quality | The latest quality score is below the configured threshold. |
Operational cards
Current responsibility
This card reads the current custody record, which is the source of truth for who or what holds the asset. It shows the holder name and target type, custody status, effective date, due date, primary caretaker, accountable owner, and endorsement reference when available. The endorsement reference links to its document only when the viewer has custody access.
If there is no active custody, the card says so plainly. It advertises availability for assignment only when the asset is actually eligible and the viewer can start that action. A legacy “issued to” projection without a matching custody row is shown as a reconciliation warning instead of being presented as trustworthy custody.
Lifecycle snapshot
The lifecycle card collects dates and policy facts that determine what should happen next: last and next audit, warranty expiry, purchase date, expected end-of-life date, whether the asset is requestable, and its default depreciation profile when that financial context is available. Unscheduled or unrecorded dates are identified as unavailable rather than treated as zero.
Service health
Every user who can view the asset can see its service summary; the
asset_maintenance permission controls maintenance management, not this read-only
summary. The card shows condition, counts of open issues and work orders, completed service
cost when there is one, the open issue list, the newest maintenance record, and the total
maintenance-history count. Links lead to the detailed
Service and Maintenance workspaces.
Finance and disposal
Financial and disposal data is intentionally permission-sensitive. These two permissions are related but not interchangeable:
| Permission | What it unlocks on this page |
|---|---|
asset_view_financial |
The Financial snapshot: acquisition cost and each financial book's cost basis, accumulated depreciation, impairment, net book value, last posted period, useful life, and status. It also allows the lifecycle card to show the depreciation profile. |
asset_finance_view |
The latest Disposal card, when a disposal exists, including its reference, status, reason, method, request date, and financial book. It also controls the deep link into the Accounting workspace; because that link sits in the Financial snapshot, both finance permissions are needed to see the link itself. |
asset_finance_view and therefore cannot see the disposal's sensitive
details. The action is suppressed without leaking the disposal record.
Detail rail
The right rail keeps supporting facts visible without competing with the operational cards. It contains:
- Specifications — category, type, brand, catalog model, model number, serial number, vendor, location, order number, criticality, data classification, storage-media flag, and end-of-life date when recorded;
- Custom details — values validated and formatted from the asset category's current custom-field schema;
- Accessories — each linked accessory and its optional note;
- Record quality — the stored quality badge and the time it was scored; and
- Record details — UUID when present, created date and creator, and last updated date.
Empty sections use explicit “no data” messages; they do not invent specifications or scores. On wide screens the rail stays beside the main content. At tablet width the main content comes first and the rail follows it. Summary cards become a single column below 1200 px, and on small phones the identity block, action buttons, and fact grids stack to full width.
Contextual actions and permission gates
The page does not use one fixed action menu. It derives eligibility from the current custody, status-label rules, open disposal state, the logged-in person's relationship to the custody, and their permissions. For an unassigned asset, checkout and endorsement are offered only when its status is deployable and not archived (or no status is set) and no disposal is open.
asset_custody is the parent gate for every modern custody action. A child
permission such as asset_transfer, asset_receive, or
asset_endorsement_create does not make its action appear unless the viewer also
has asset_custody. Personal acceptance and return actions still require this
parent gate in addition to their identity checks.
| Action | Key eligibility on this page |
|---|---|
| New endorsement | No current or legacy assignment; deployable, non-archived status; no open disposal; asset_custody + asset_endorsement_create. |
| Check out | No current or legacy assignment; same status/disposal checks; asset_checkout. |
| Accept | The custody awaits acceptance, the viewer is its target/caretaker/accountable person, and they have asset_custody. |
| Reject | The same identity and parent checks, but only while custody is pending_acceptance. |
| Request return | Active custody; asset_custody; and the viewer is a custody actor, has checkout authority, or is an administrator. |
| Transfer | A compatible current custody state; asset_custody + asset_transfer. |
| Receive | A compatible current custody/return state; asset_custody + asset_receive. |
| View document | The current custody came from an endorsement and the viewer has asset_custody. |
| Report issue | asset_issue_report. |
| Audit asset | asset_audit. |
| Edit | asset_update. |
| Legacy check-in / receipt / return | Shown only to safely recover an older “issued to” projection that has no current custody row; checkout authority or assignee identity applies to the corresponding action. |
When several actions are valid, the view promotes the most context-relevant one — for example accepting a pending handover or receiving a returning asset — and keeps the rest in the secondary dropdown.
Activity & comments
The bottom card is one unified feed, not separate lifecycle and comment panels. It merges the asset event ledger with the comment thread and applies the configured ascending or descending sort direction to both streams. The composer is positioned consistently with that direction, and the count in the card header updates when a new comment is posted.
Events can include custody handovers, receipt and return steps, audits, service issues and maintenance, and finance/disposal activity written by their owning workflows. A service issue that produced both an event and its mirrored comment is shown once, using the recorded pair mapping (with a legacy fallback), so the activity story is not double-counted. Issue or Helpdesk links appear only when their module and permission gates allow them.
Posting and managing comments
| Capability | Rule |
|---|---|
| Post a comment | The composer requires asset_comment and supports @-mentions plus file attachments. |
| Delete a comment | Requires delete_asset_comment. Comments are not edited in place. |
| Protected system entries | Description and automatic change-note comments remain non-deletable. |
| Empty feed | The page explicitly says that no activity has been recorded yet. |
What still lives in a specialist workspace
The command view provides enough context to understand the asset without turning every domain ledger into a second full application. Use the linked workspaces for the complete maintenance schedule and history, issue workflow, custody document, audit campaign, depreciation runs, financial postings, or disposal approvals and evidence. Their summary data on this page comes from those same models rather than a separate, editable copy.