43 lines
2.6 KiB
Markdown
43 lines
2.6 KiB
Markdown
# workload-actions Specification
|
|
|
|
## Purpose
|
|
|
|
Identify workload actions owned by the signed-in user and allow eligible users to create actions for opportunity products.
|
|
|
|
## Requirements
|
|
|
|
### Requirement: Action enrichment respects prerequisite data
|
|
Workload Action enrichment SHALL use distinct product revenue identifiers after the product cycle and successful or reused CRM SR loading. Unavailable SR data SHALL leave action state unknown rather than treating it as an empty result.
|
|
|
|
#### Scenario: SR prerequisite fails
|
|
- **WHEN** CRM SR loading fails for a completed product cycle
|
|
- **THEN** action enrichment is blocked and its badges do not assert that no actions exist
|
|
|
|
### Requirement: Ownership determines the action badge
|
|
The action badge SHALL aggregate returned actions for the opportunity products and mark a match when an action owner equals the general Token Relay principal. Missing principal or failed lookups SHALL not count as confirmed nonmatches.
|
|
|
|
#### Scenario: Actions exist for other owners
|
|
- **WHEN** returned actions have no owner matching the known principal
|
|
- **THEN** the badge indicates no matching ownership while its tooltip retains the returned actions
|
|
|
|
### Requirement: Read attempts are bounded and partial coverage is disclosed
|
|
Each action lookup SHALL make at most five total attempts and stop on success or session supersession. The current lookup SHALL expose `hasNext` as additional unqueried actions rather than implying that all pages were loaded.
|
|
|
|
#### Scenario: More action pages exist
|
|
- **WHEN** a successful action response sets `hasNext=true`
|
|
- **THEN** the tooltip states that additional actions exist and pagination is not enabled
|
|
|
|
### Requirement: Action forms use validated lookup selections
|
|
The Action form SHALL load team members and lookup values with the workload credential, support searchable selections, and submit selected codes rather than arbitrary typed search text. Required inputs and the date range SHALL be validated before Save.
|
|
|
|
#### Scenario: Search text is not an option
|
|
- **WHEN** the user types a value without selecting a valid lookup result
|
|
- **THEN** the text is not submitted as a valid option value
|
|
|
|
### Requirement: Action creation is explicit and preserves failure state
|
|
Saving a valid action SHALL send current-user attribution, UTC dates and a notes array, lock duplicate submission while pending and show a result toast. A failed create SHALL retain the form without automatically retrying the POST.
|
|
|
|
#### Scenario: Create fails
|
|
- **WHEN** the server rejects an action creation
|
|
- **THEN** the form remains available with the entered data and no automatic duplicate POST is issued
|