3.1 KiB
Purpose
Let authorized users review and maintain weekly time entries with validated hours and explicit, traceable persistence.
ADDED Requirements
Requirement: Manage Time requires profile and session readiness
Manage Time SHALL remain unavailable to SALES_REP users. For eligible users, its launcher SHALL remain disabled until SR session readiness, and data request entry points SHALL enforce the profile gate before loading time data.
Scenario: Restricted profile with a ready session
- WHEN SR session preparation succeeds for a user with
SALES_REP - THEN Manage Time remains hidden and opening it does not send its data requests
Requirement: Week navigation preserves the user's work
Manage Time SHALL restore its selected reference date, navigate in seven-day increments and retain local drafts while moving between weeks within the modal. Late responses for a different week or closed modal SHALL not replace active values.
Scenario: Navigate away and back
- WHEN the user edits an unsaved week, navigates to another week and returns
- THEN the earlier week's local edits remain available
Requirement: Entry selections are dependent and searchable
Service Request, Activity and Task Type selections SHALL support autocomplete. Activities SHALL correspond to the chosen SR, task types SHALL match Service or Non Service rows, and duplicate SR selection SHALL be rejected with row feedback.
Scenario: Duplicate SR
- WHEN a user selects an SR already used by another row
- THEN the previous selection is restored and the existing row is highlighted
Requirement: Hours are validated before persistence
Each entered daily hour value SHALL be numeric and within the inclusive range 0 through 24. The view SHALL show daily totals and reject invalid rows before any affected write.
Scenario: Invalid daily hours
- WHEN a user attempts to save a row containing 25 hours for one day
- THEN validation prevents that invalid time entry from being submitted
Requirement: Save controls creation updates and deletions
Save SHALL create new entries with POST, update changed persisted entries with PUT and apply queued persisted deletions with DELETE. Removing an unsaved row SHALL remain local. Writes SHALL use the required session and current-resource context.
Scenario: Persisted row is removed before Save
- WHEN a user removes a persisted row without saving
- THEN the deletion remains queued and no DELETE is sent yet
Scenario: Partial save failure
- WHEN some entry operations succeed and another operation fails
- THEN successful results remain reflected locally and unfinished work remains available for retry without duplicating confirmed writes
Requirement: Loading and failures are local to the time view
Manage Time SHALL display skeleton rows while loading and provide retry on data failure without discarding the user's current draft values.
Scenario: Week retrieval fails
- WHEN the active week's request fails
- THEN the modal exposes the failure and retry while protecting existing edits