Add project availability rate for people

[lredor]

Add project availability rate for people

Context

In addition to public holidays and absence periods, we need to specify that a person is not necessarily available at 100% for a given project.

Today, when a person is present on a working day, that day is implicitly considered fully available for the project. In practice, a person may be only partially allocated to a project, for example 20%, 50%, or 80%.

This means that one day of presence does not necessarily equal one full day of work available for project tasks.

Need

Allow defining, for a person on a project, an availability rate expressed as a percentage.

Examples:

• A person available at 100% on the project: 1 day of presence = 1 available day.
• A person available at 50% on the project: 1 day of presence = 0.5 available day.
• A person available at 20% on the project: 1 day of presence = 0.2 available day.

This rate should complement:

• public holidays;
• absence/unavailability periods;
• optional start/end dates for the person’s involvement.

Expected Behavior

When computing a person’s available capacity for a project:

1. Non-working days, public holidays, and absences should be excluded.
2. On the remaining days where the person is present, the project availability rate should be applied.
3. The available capacity should therefore be weighted by this rate.

For example, over a 5-working-day week:

• the person is present for the full week;
• project availability rate: 60%;

The available project capacity is 5 * 0.6 = 3 days.

If the person has 1 day of absence during that week:

• present days: 4;
• project availability rate: 60%;

The available project capacity is 4 * 0.6 = 2.4 days.

Possible Modeling

Today, a project only stores a list of members. This is not sufficient for this feature because the availability rate is not an intrinsic property of the person, but information attached to the person’s involvement in a specific project.

For example, the same person may be available:

• 80% on project A;
• 20% on project B;
• 0% on project C for a given period.

To support this, the project membership should be represented by a dedicated model concept instead of a direct list of people.

For example, introduce a ProjectMember or ProjectAllocation concept containing:

• a reference to the Person;
• an availabilityRate property, expressed as a percentage between 0 and 100;
• optional start/end dates if the allocation period needs to be scoped later.

The Project would then contain a list of these allocation/membership objects instead of, or in addition to, the current direct list of members.

The default availability rate should be 100.

Migration should be considered for existing projects: existing members should be converted or interpreted as project allocations with an availability rate of 100%.

User Interface

The current UI only allows users to manage the list of project members. This is not sufficient because there is no place to edit information attached to the membership itself.

The project members UI should therefore evolve from a simple member selection/list to a table or structured editor showing one row per project member/allocation.

Each row should allow editing at least:

• the selected person;
• the project availability rate.

The availability rate should be displayed as a percentage:

• label: Project availability
• default value: 100%
• constraints: value between 0 and 100

This UI should make it possible to keep the existing workflow of adding/removing project members while also editing their project-specific availability.

Acceptance Criteria

• It is possible to define a project availability rate for a person.
• The rate is expressed as a percentage between 0 and 100.
• The default value is 100%.
• The rate is taken into account when computing capacity/availability.
• Absences and public holidays take precedence: an absence day always represents 0 available day, regardless of the rate.
• A person available at 50% on a project only contributes 0.5 day per present working day.