Add Resource Unavailability Management

[lredor]

Summary

Introduce the ability to manage resource unavailability periods in Pepper.

This first iteration is limited to storing and managing unavailability information for resources. It does not impact task scheduling, workload calculation, or Gantt planning.

The objective is to provide a foundation for future planning features that will take resource availability into account.

Motivation

Project managers need to record periods during which a resource is unavailable, such as:

• Vacation
• Public holidays specific to a resource
• Training sessions
• Sick leave
• Other planned absences

At this stage, the information is purely informational and is not used by the scheduling engine.

Scope

Included

• Define unavailability periods for a resource.
• Create, update, and delete unavailability periods.
• Display existing unavailability periods associated with a resource.
• Persist unavailability information in the project model.

Excluded

• Impact on task scheduling.
• Impact on Gantt dates.
• Impact on workload or capacity calculations.
• Conflict detection between tasks and unavailability periods.
• Reporting or analytics based on availability.

Domain Model Proposal

Introduce a new concept named UnavailabilityPeriod.

UnavailabilityPeriod

Attributes:

• startDate : Date
• endDate : Date
• description : String [0..1]

Person

A Person owns zero or more unavailability periods:

Person
└─ unavailabilityPeriods : UnavailabilityPeriod [0..*]

This evolution only introduces the storage and management of the information. No scheduling behavior is associated with these periods yet.

Functional Requirements

FR1 - Create an Unavailability Period

A user can create an unavailability period for a resource.

An unavailability period contains:

• Start date
• End date
• Optional description/reason

FR2 - Update an Unavailability Period

A user can modify the properties of an existing unavailability period.

FR3 - Delete an Unavailability Period

A user can remove an existing unavailability period.

FR4 - Display Unavailability Periods

A user can view all unavailability periods associated with a resource.

FR5 - Data Persistence

Unavailability periods must be persisted in the Pepper model and restored when reopening a project.

User Stories

Create an unavailability period

As a project manager,

I want to record a period during which a resource is unavailable,

So that this information is available for future planning activities.

Update an unavailability period

As a project manager,

I want to modify an existing unavailability period,

So that availability information remains accurate.

Delete an unavailability period

As a project manager,

I want to remove an obsolete unavailability period,

So that the resource availability data stays up to date.

Acceptance Criteria

AC1 - Creation

Given an existing resource,

When a user creates an unavailability period,

Then the period is associated with the resource and displayed in the UI.

AC2 - Modification

Given an existing unavailability period,

When a user updates its properties,

Then the changes are persisted and displayed immediately.

AC3 - Deletion

Given an existing unavailability period,

When a user deletes it,

Then it is removed from the resource and no longer displayed.

AC4 - Persistence

Given a project containing unavailability periods,

When the project is saved and reopened,

Then all unavailability periods are restored correctly.

Related Issues

This issue is a prerequisite for future resource-capacity and planning improvements.

In particular, it is related to:

• How to determine working days ? #12, which introduces resource allocation and workload management concepts.
• Determine the end time based on the start time and a duration #8, which covers planning and scheduling capabilities that may later take resource availability into account.

This issue intentionally focuses on introducing and managing unavailability data only. The integration of these periods into scheduling algorithms and workload computations will be addressed in follow-up issues.

Notes

Future enhancements may include:

• Capacity calculations based on availability.
• Automatic task rescheduling.
• Detection of planning conflicts.
• Resource utilization reporting.
• Visualization of absences in planning views.