|
|
|
|
@@ -0,0 +1,207 @@
|
|
|
|
|
## ADDED Requirements
|
|
|
|
|
|
|
|
|
|
### Requirement: Platform Audit Event Investigation
|
|
|
|
|
|
|
|
|
|
The admin frontend SHALL provide platform audit event list and detail views using `GET /api/admin/audit/events` and `GET /api/admin/audit/events/{event_id}`. It SHALL preserve the documented event, actor, scope, resource, result, risk, request and investigation-reference fields, use stable codes for filters, and prefer backend display names.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Filter and inspect audit events
|
|
|
|
|
|
|
|
|
|
- **WHEN** an authorized platform user filters audit events by documented time, action, category, actor, source, result, risk, scope, resource or linkage parameters
|
|
|
|
|
- **THEN** the frontend MUST send the documented parameter names and stable code values
|
|
|
|
|
- **AND** it MUST render the paginated `items`, `total`, `page`, `page_size` and `retention` response
|
|
|
|
|
|
|
|
|
|
#### Scenario: Open an event detail
|
|
|
|
|
|
|
|
|
|
- **WHEN** the user opens an event returned by the list or another investigation reference
|
|
|
|
|
- **THEN** the frontend MUST pass its `event_id` unchanged to the detail endpoint
|
|
|
|
|
- **AND** it MUST display backend snapshots and names without replacing historical values with current account or resource names
|
|
|
|
|
|
|
|
|
|
### Requirement: Stable Investigation Reference Navigation
|
|
|
|
|
|
|
|
|
|
The frontend SHALL navigate between audit views only through stable identifiers returned by the APIs. `investigation_refs.actor_ref`, `resource_refs`, `request_id`, `correlation_id`, `integration_refs`, Integration `linkage`, and stable Integration `resource` references SHALL be the authoritative navigation sources.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Navigate through a returned reference
|
|
|
|
|
|
|
|
|
|
- **WHEN** an audit or Integration response contains a non-empty supported investigation reference
|
|
|
|
|
- **THEN** the frontend MUST pass the returned identifier and type unchanged to the corresponding actor, resource, request, correlation or Integration view
|
|
|
|
|
|
|
|
|
|
#### Scenario: A reference is unavailable or unreliable
|
|
|
|
|
|
|
|
|
|
- **WHEN** the required reference is empty, absent, unsupported, or its linkage `fidelity` indicates that a relationship is unavailable
|
|
|
|
|
- **THEN** the frontend MUST hide or disable the related navigation action
|
|
|
|
|
- **AND** it MUST NOT infer a relationship from names, timestamps, summaries, adjacent rows or resource text
|
|
|
|
|
|
|
|
|
|
#### Scenario: Link identifiers are not generated by the frontend
|
|
|
|
|
|
|
|
|
|
- **WHEN** the frontend needs a `correlation_id` or `integration_id`
|
|
|
|
|
- **THEN** it MUST use a value returned by an API
|
|
|
|
|
- **AND** it MUST NOT generate, concatenate or guess the identifier
|
|
|
|
|
|
|
|
|
|
### Requirement: Actor, Resource, and Link Timelines
|
|
|
|
|
|
|
|
|
|
The admin frontend SHALL provide actor-event, resource-event, request-link and correlation-link timelines through the documented endpoints. It SHALL support an explicitly pasted Access Log `request_id`, while all other navigation values SHALL come from returned stable references.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Inspect actor behavior
|
|
|
|
|
|
|
|
|
|
- **WHEN** a user follows `actor_ref.kind/id` or opens an account by its stable ID
|
|
|
|
|
- **THEN** the frontend MUST call `/api/admin/audit/actors/{kind}/{id}/events`
|
|
|
|
|
- **AND** action and resource filters MUST use stable values returned by audit data
|
|
|
|
|
|
|
|
|
|
#### Scenario: Select an exact resource result
|
|
|
|
|
|
|
|
|
|
- **WHEN** a user searches with a supported `resource_type` and exact `keyword` and selects a result
|
|
|
|
|
- **THEN** the frontend MUST pass `items[].resource_type/resource_id` unchanged to the resource timeline
|
|
|
|
|
- **AND** it MUST identify `historical=true` as a historical-snapshot match
|
|
|
|
|
|
|
|
|
|
#### Scenario: Query a request copied from Access Log
|
|
|
|
|
|
|
|
|
|
- **WHEN** a platform user explicitly pastes a request ID from Access Log
|
|
|
|
|
- **THEN** the frontend MAY query `/api/admin/audit/requests/{request_id}/timeline` with that exact value
|
|
|
|
|
- **AND** it MUST NOT claim that the endpoint scans Access Log or archived object storage
|
|
|
|
|
|
|
|
|
|
### Requirement: Retention, Pagination, and Time Semantics
|
|
|
|
|
|
|
|
|
|
All audit list and timeline views SHALL use the documented pagination and `retention` contract. Time filters SHALL be RFC3339 timestamps with timezone information, and `created_to` SHALL be treated as an exclusive upper bound.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Respect the online retention window without a global prompt
|
|
|
|
|
|
|
|
|
|
- **WHEN** a response contains `retention.online_from`, `archived_before` and `timezone`
|
|
|
|
|
- **THEN** the frontend MUST preserve the retention semantics in its data contract without displaying a global online-window banner
|
|
|
|
|
- **AND** it MUST NOT interpret an empty online result as proof that no historical event exists
|
|
|
|
|
|
|
|
|
|
#### Scenario: Page through a timeline
|
|
|
|
|
|
|
|
|
|
- **WHEN** the user changes page or page size
|
|
|
|
|
- **THEN** the frontend MUST use `page` and `page_size`, respect the maximum page size of 100, and preserve the active filters
|
|
|
|
|
|
|
|
|
|
### Requirement: Finance Investigation Timeline
|
|
|
|
|
|
|
|
|
|
The admin frontend SHALL query `GET /api/admin/audit/finance/timeline` with any documented stable finance condition, including shop, wallet, order, payment, refund, recharge, approval, third-party trade, actor or correlation identifiers. Monetary values SHALL remain integer fen in application data, and authority SHALL follow `amount_authority`.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Open finance history from a business record
|
|
|
|
|
|
|
|
|
|
- **WHEN** a user opens finance history from an order, refund, recharge, wallet or shop with a stable backend ID
|
|
|
|
|
- **THEN** the frontend MUST send the matching documented query parameter
|
|
|
|
|
- **AND** it MUST allow the server to complete related facts instead of assembling a local timeline
|
|
|
|
|
|
|
|
|
|
#### Scenario: Display an authoritative amount
|
|
|
|
|
|
|
|
|
|
- **WHEN** a finance node returns an amount and `amount_authority.authoritative=true`
|
|
|
|
|
- **THEN** the frontend MUST treat the referenced table and field as authoritative
|
|
|
|
|
- **AND** it MUST only convert integer fen for presentation and MUST NOT reconcile conflicting facts locally
|
|
|
|
|
|
|
|
|
|
### Requirement: Risk Investigation
|
|
|
|
|
|
|
|
|
|
The admin frontend SHALL provide risk overview and event-detail views using `/api/admin/audit/risks/overview` and `/api/admin/audit/risks/events`. Filters SHALL use codes returned in overview collections, and the selected time range SHALL not exceed 31 days.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Drill down from a risk summary
|
|
|
|
|
|
|
|
|
|
- **WHEN** a user selects a risk, result, action, source or signal represented by the overview
|
|
|
|
|
- **THEN** the frontend MUST use the returned stable code for the supported event-list filter
|
|
|
|
|
- **AND** backend `name` values MUST be used only for display
|
|
|
|
|
|
|
|
|
|
#### Scenario: Select a range longer than 31 days
|
|
|
|
|
|
|
|
|
|
- **WHEN** the user attempts to query more than 31 days
|
|
|
|
|
- **THEN** the frontend MUST prevent submission and explain the maximum range
|
|
|
|
|
|
|
|
|
|
### Requirement: External Integration Investigation
|
|
|
|
|
|
|
|
|
|
The admin frontend SHALL provide Integration overview, list and detail views through the documented endpoints. It SHALL preserve provider, direction, operation, raw result, derived result category, duration, state-change, trigger, resource, linkage, attempt, content-summary, fidelity and retention fields.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Apply overview filters to the list
|
|
|
|
|
|
|
|
|
|
- **WHEN** a user selects an overview provider, direction or result
|
|
|
|
|
- **THEN** the frontend MUST map `providers[].code` to `provider`, `directions[].code` to `direction`, `results[].code` to `result`, and `results[].category` to `result_category`
|
|
|
|
|
- **AND** it MUST use `name` only as display text
|
|
|
|
|
|
|
|
|
|
#### Scenario: Display Integration trend categories
|
|
|
|
|
|
|
|
|
|
- **WHEN** the overview returns trend points
|
|
|
|
|
- **THEN** the frontend MUST preserve the five categories `processing`, `succeeded`, `indeterminate`, `failed` and `not_sent`
|
|
|
|
|
- **AND** it MUST use only the documented `hour` or `day` bucket
|
|
|
|
|
|
|
|
|
|
#### Scenario: Inspect an Integration detail
|
|
|
|
|
|
|
|
|
|
- **WHEN** a user opens an `integration_id` returned by a list, event reference or notification target
|
|
|
|
|
- **THEN** the frontend MUST query the detail with that value unchanged
|
|
|
|
|
- **AND** it MUST present the capability as read-only without recovery, modification, deletion or export actions
|
|
|
|
|
|
|
|
|
|
### Requirement: Role-Specific Resource Activity
|
|
|
|
|
|
|
|
|
|
The frontend SHALL use the agent and enterprise resource-activity endpoints according to the authenticated subject. Agent activity SHALL support `iot_card`, `device`, `asset_allocation_record`, `exchange_order`, `shop` and `enterprise`; enterprise activity SHALL support only authorized `iot_card` and `device` resources.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Open an agent resource activity
|
|
|
|
|
|
|
|
|
|
- **WHEN** an agent opens activity for a supported resource
|
|
|
|
|
- **THEN** the frontend MUST use ICCID for a card, VirtualNo for a device, or the documented stable business number for another supported resource
|
|
|
|
|
- **AND** it MUST NOT send or infer the agent identity or shop scope as query data
|
|
|
|
|
|
|
|
|
|
#### Scenario: Open enterprise asset activity
|
|
|
|
|
|
|
|
|
|
- **WHEN** an enterprise user opens an authorized card or device activity
|
|
|
|
|
- **THEN** the frontend MUST use ICCID or VirtualNo with the enterprise endpoint
|
|
|
|
|
- **AND** it MUST render only the subject-safe projection without platform actor, risk, internal reason or before/after fields
|
|
|
|
|
|
|
|
|
|
#### Scenario: A stable subject identifier is missing
|
|
|
|
|
|
|
|
|
|
- **WHEN** a business response does not contain the required ICCID, VirtualNo or stable business number
|
|
|
|
|
- **THEN** the frontend MUST hide the activity entry
|
|
|
|
|
- **AND** it MUST NOT substitute a display name or internal identifier intended for another subject
|
|
|
|
|
|
|
|
|
|
### Requirement: Business Audit Entries
|
|
|
|
|
|
|
|
|
|
The frontend SHALL add role-appropriate audit entries to card, device, shop, enterprise, order, refund and wallet list/detail contexts without changing existing business API URLs. Platform entries SHALL use backend internal IDs; agent and enterprise entries SHALL use their documented stable business identifiers.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Open platform asset or business history
|
|
|
|
|
|
|
|
|
|
- **WHEN** a platform user opens audit history from a card, device, shop, enterprise, order or refund record
|
|
|
|
|
- **THEN** the frontend MUST use the corresponding `resource_type` and backend `response.data.id` with the resource timeline
|
|
|
|
|
|
|
|
|
|
#### Scenario: Open wallet or transaction history
|
|
|
|
|
|
|
|
|
|
- **WHEN** a user opens audit history for a wallet, order or refund with a stable ID
|
|
|
|
|
- **THEN** the frontend MUST offer the applicable finance timeline query
|
|
|
|
|
- **AND** the resource timeline MAY also be offered only when a stable resource reference is available
|
|
|
|
|
|
|
|
|
|
#### Scenario: Preserve existing operation logs
|
|
|
|
|
|
|
|
|
|
- **WHEN** new audit entries are introduced on asset pages
|
|
|
|
|
- **THEN** existing asset operation-log features MUST remain available
|
|
|
|
|
- **AND** the UI MUST distinguish the existing operation logs from the new cross-system audit investigation
|
|
|
|
|
|
|
|
|
|
### Requirement: Controlled Notification Integration Target
|
|
|
|
|
|
|
|
|
|
The frontend SHALL resolve a notification through `GET /api/admin/notifications/{id}/target` before opening an Integration detail. It SHALL open the detail only when the target is available, has `target_type=integration_log`, and contains a non-empty `target_key`.
|
|
|
|
|
|
|
|
|
|
#### Scenario: Open an Integration notification
|
|
|
|
|
|
|
|
|
|
- **WHEN** target resolution returns `available=true`, `target_type=integration_log`, and a non-empty `target_key`
|
|
|
|
|
- **THEN** the frontend MUST pass `target_key` unchanged as the Integration `integration_id`
|
|
|
|
|
- **AND** it MUST open the controlled internal Integration detail route
|
|
|
|
|
|
|
|
|
|
#### Scenario: Notification target cannot be used
|
|
|
|
|
|
|
|
|
|
- **WHEN** the target is unavailable, has another type, lacks `target_key`, or maps to no registered route
|
|
|
|
|
- **THEN** the frontend MUST not navigate or execute an arbitrary URL
|
|
|
|
|
- **AND** it MUST preserve the notification content and show a safe unavailable-target message
|
|
|
|
|
|
|
|
|
|
### Requirement: Audit Authorization and Read-Only Boundary
|
|
|
|
|
|
|
|
|
|
The frontend SHALL enforce the final platform, agent and enterprise route and action permissions, while preserving backend authentication, authorization and data-isolation enforcement. All capabilities in this change SHALL remain read-only.
|
|
|
|
|
|
|
|
|
|
#### Scenario: A subject lacks audit permission
|
|
|
|
|
|
|
|
|
|
- **WHEN** the current subject lacks the configured permission for an audit page or business entry
|
|
|
|
|
- **THEN** the frontend MUST hide or disable that page or entry and MUST NOT call the endpoint as a fallback
|
|
|
|
|
|
|
|
|
|
#### Scenario: An audit request is rejected
|
|
|
|
|
|
|
|
|
|
- **WHEN** an endpoint returns `400`, `401`, `403` or `500`
|
|
|
|
|
- **THEN** the frontend MUST use shared validation, authentication, authorization and server-error handling
|
|
|
|
|
- **AND** it MUST preserve the current investigation state when retrying would be unsafe or misleading
|
|
|
|
|
|
|
|
|
|
#### Scenario: A user inspects an audit record
|
|
|
|
|
|
|
|
|
|
- **WHEN** any audit, risk, finance, Integration or subject-activity view is displayed
|
|
|
|
|
- **THEN** the UI MUST NOT provide mutation, recovery, deletion, risk-disposition, blocking or export actions
|
luo