24 lines
1.4 KiB
Markdown
24 lines
1.4 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Asset views SHALL display the estimated final package expiry
|
|
|
|
Asset detail and summary views using `/api/c/v1/asset/info` SHALL prefer `estimated_final_expires_at` over `current_package_expires_at` for the user-facing final expiry. The client SHALL use `expiry_estimate_status`, `days_until_final_expiry`, and `is_expiring` when those fields are returned, and SHALL NOT calculate a replacement final expiry locally.
|
|
|
|
#### Scenario: Exact final expiry is available
|
|
|
|
- **WHEN** `expiry_estimate_status = exact` and `estimated_final_expires_at` is present
|
|
- **THEN** the client SHALL display the estimated final expiry date
|
|
- **AND** the client SHALL display the returned remaining-day value when available
|
|
|
|
#### Scenario: Asset is approaching final expiry
|
|
|
|
- **WHEN** `is_expiring = true` or the backend returns an applicable expiry level
|
|
- **THEN** the client SHALL apply the existing expiry highlight/reminder presentation
|
|
- **AND** the client SHALL use the backend value rather than recalculating the threshold
|
|
|
|
#### Scenario: Final expiry cannot be estimated
|
|
|
|
- **WHEN** `expiry_estimate_status` is `none`, `waiting_activation`, or `invalid_data`, or the estimated date is null
|
|
- **THEN** the client SHALL show the corresponding empty/pending state
|
|
- **AND** the client SHALL not present `current_package_expires_at` as if it were the final calculated expiry
|