Santhosh Janardhanan
f87ccccc4d
address each point.
**Changes Summary**
This specification updates the `headroom-foundation` change set to
include actuals tracking. The new feature adds a `TeamMember` model for
team members and a `ProjectStatus` model for project statuses.
**Summary of Changes**
1. **Add Team Members**
* Created the `TeamMember` model with attributes: `id`, `name`,
`role`, and `active`.
* Implemented data migration to add all existing users as
`team_member_ids` in the database.
2. **Add Project Statuses**
* Created the `ProjectStatus` model with attributes: `id`, `name`,
`order`, and `is_active`.
* Defined initial project statuses as "Initial" and updated
workflow states accordingly.
3. **Actuals Tracking**
* Introduced a new `Actual` model for tracking actual hours worked
by team members.
* Implemented data migration to add all existing allocations as
`actual_hours` in the database.
* Added methods for updating and deleting actual records.
**Open Issues**
1. **Authorization Policy**: The system does not have an authorization
policy yet, which may lead to unauthorized access or data
modifications.
2. **Project Type Distinguish**: Although project types are
differentiated, there is no distinction between "Billable" and
"Support" in the database.
3. **Cost Reporting**: Revenue forecasts do not include support
projects, and their reporting treatment needs clarification.
**Implementation Roadmap**
1. **Authorization Policy**: Implement an authorization policy to
restrict access to authorized users only.
2. **Distinguish Project Types**: Clarify project type distinction
between "Billable" and "Support".
3. **Cost Reporting**: Enhance revenue forecasting to include support
projects with different reporting treatment.
**Task Assignments**
1. **Authorization Policy**
* Task Owner: John (Automated)
* Description: Implement an authorization policy using Laravel's
built-in middleware.
* Deadline: 2026-03-25
2. **Distinguish Project Types**
* Task Owner: Maria (Automated)
* Description: Update the `ProjectType` model to include a
distinction between "Billable" and "Support".
* Deadline: 2026-04-01
3. **Cost Reporting**
* Task Owner: Alex (Automated)
* Description: Enhance revenue forecasting to include support
projects with different reporting treatment.
* Deadline: 2026-04-15
101 lines
2.9 KiB
Markdown
101 lines
2.9 KiB
Markdown
# Purpose
|
|
|
|
Enable users to log, update, and delete actual hours worked for project-member-month combinations.
|
|
|
|
# Requirements
|
|
|
|
## Requirement: Log hours via modal
|
|
|
|
The system SHALL provide a modal for logging hours.
|
|
|
|
### Scenario: Open logging modal
|
|
- GIVEN user clicks an editable cell in the grid
|
|
- WHEN the cell is clicked
|
|
- THEN a modal opens with project, member, and month context
|
|
- AND an input field for hours to add is displayed
|
|
|
|
### Scenario: Log new hours
|
|
- GIVEN the modal is open for a cell with 0 actual hours
|
|
- WHEN user enters 8 hours and submits
|
|
- THEN the actual record is created with 8 hours
|
|
- AND the grid refreshes to show the updated value
|
|
|
|
### Scenario: Add hours to existing
|
|
- GIVEN a cell already has 40 hours logged
|
|
- WHEN user enters 8 hours and submits
|
|
- THEN the actual record is updated to 48 hours
|
|
- AND the grid refreshes to show the updated value
|
|
|
|
## Requirement: Hours are additive
|
|
|
|
The system SHALL accumulate hours when logging to an existing actual.
|
|
|
|
### Scenario: Multiple logging entries accumulate
|
|
- GIVEN user logs 8 hours on Monday
|
|
- AND user logs 4 hours on Tuesday
|
|
- WHEN both entries are saved
|
|
- THEN the total actual hours is 12
|
|
|
|
## Requirement: Notes support
|
|
|
|
The system SHALL allow optional notes with hour entries.
|
|
|
|
### Scenario: Add notes with hours
|
|
- GIVEN user is logging hours
|
|
- WHEN user enters notes text
|
|
- THEN the notes are stored with the actual record
|
|
|
|
### Scenario: Notes are appended
|
|
- GIVEN an actual record exists with notes
|
|
- WHEN user logs additional hours with new notes
|
|
- THEN the new notes are appended with timestamp
|
|
|
|
## Requirement: Validation - future months
|
|
|
|
The system SHALL prevent logging to future months.
|
|
|
|
### Scenario: Reject future month
|
|
- GIVEN current month is March 2024
|
|
- WHEN user attempts to log hours for April 2024
|
|
- THEN validation error is returned
|
|
- AND the actual is not created
|
|
|
|
## Requirement: Validation - completed projects
|
|
|
|
The system SHALL prevent logging to completed projects.
|
|
|
|
### Scenario: Reject completed project
|
|
- GIVEN a project has status Done or Cancelled
|
|
- WHEN user attempts to log hours
|
|
- THEN validation error is returned
|
|
- AND the actual is not created
|
|
|
|
### Scenario: Config override
|
|
- GIVEN ALLOW_ACTUALS_ON_INACTIVE_PROJECTS is true
|
|
- WHEN user attempts to log hours to a completed project
|
|
- THEN the actual is created successfully
|
|
|
|
## Requirement: Delete actual
|
|
|
|
The system SHALL allow deletion of actual records.
|
|
|
|
### Scenario: Delete existing actual
|
|
- GIVEN an actual record exists
|
|
- WHEN user clicks Delete in the modal
|
|
- THEN the actual record is removed
|
|
- AND the grid refreshes to show 0 hours
|
|
|
|
## Requirement: Request validation
|
|
|
|
The system SHALL validate request inputs.
|
|
|
|
### Scenario: Invalid hours rejected
|
|
- GIVEN user enters negative hours
|
|
- WHEN form is submitted
|
|
- THEN validation error is returned
|
|
|
|
### Scenario: Missing required fields
|
|
- GIVEN user submits without hours
|
|
- WHEN form is submitted
|
|
- THEN validation error is returned
|