I am writing to report a critical and fundamental bug in how ProjectLibre calculates the Work for a task when using resources with non-standard calendars.
The core of the issue is that ProjectLibre incorrectly calculates the total Work based on the project's default calendar and fails to update this value after a resource with a custom calendar is assigned. This makes planning with resources on different work schedules unreliable and requires manual correction, defeating the purpose of the software's automation.
Environment:
ProjectLibre Version: 1.9.8
Operating System: Windows 11
Steps to Reproduce the Bug:
The bug can be reliably reproduced with the following simple steps:
Create a new, blank project. (The default project calendar is 8 hours/day).
Go to Resources > Calendar and create a new Base Calendar. Name it "6h_work_day" and configure it for a 6-hour workday (e.g., 08:00-12:00 and 13:00-15:00).
Go to the Resource Sheet and create a new resource named "Dev_A".
In the Base Calendar column for "Dev_A", assign the custom "6h_work_day" calendar.
Return to the Gantt Chart. Create a new task and open the "Task Information" dialog.
Under the "Advanced" tab, set the Task Type to Fixed Duration.
Go back to the "General" tab and set the task's Duration to 10 days.
Observe at this point: ProjectLibre immediately calculates the Work as 80 hours (10 days * 8 hours/day from the project's default calendar).
Now, assign the resource "Dev_A" to this task.
Expected Result:
After assigning the "Dev_A" resource (who works 6 hours/day), the Work field for the task should automatically recalculate to reflect the resource's actual availability. The correct calculation is:
10 days * 6 hours/day = 60 hours.
Actual Result:
The Work field remains incorrectly locked at 80 hours. The software completely fails to update the Work value based on the assigned resource's specific calendar. The only way to fix this is to manually type "60h" into the Work field.
Analysis and Impact:
This is a critical calculation bug because it breaks the fundamental formula of Work = Duration x Units. The software seems to perform an initial calculation based on the project's default settings and then never re-evaluates it when resource-specific data is provided.
The impact is severe:
It makes the software unreliable. Project plans become inaccurate for any project involving part-time staff, contractors, or any resource on a non-standard schedule.
It forces error-prone manual work. Users have to manually calculate and override the work for every single task, which is inefficient and introduces a high risk of human error.
The problem gets exponentially worse when multiple resources with different calendars are assigned to the same task.
I have attached a series of PDF files that visually document these steps and the resulting incorrect calculation. This behavior seems to be a foundational flaw rather than a minor issue.
Thank you for your attention to this matter. I hope this detailed report is helpful for the development team to address this bug in a future release.
Thank you for the note.... that is complex code but should work. We will take a look at it and having rewritten the code in the Cloud AI version will see if we can back fix on the desktop.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello ProjectLibre Community,
I am writing to report a critical and fundamental bug in how ProjectLibre calculates the Work for a task when using resources with non-standard calendars.
The core of the issue is that ProjectLibre incorrectly calculates the total Work based on the project's default calendar and fails to update this value after a resource with a custom calendar is assigned. This makes planning with resources on different work schedules unreliable and requires manual correction, defeating the purpose of the software's automation.
Environment:
ProjectLibre Version: 1.9.8
Operating System: Windows 11
Steps to Reproduce the Bug:
The bug can be reliably reproduced with the following simple steps:
Create a new, blank project. (The default project calendar is 8 hours/day).
Go to Resources > Calendar and create a new Base Calendar. Name it "6h_work_day" and configure it for a 6-hour workday (e.g., 08:00-12:00 and 13:00-15:00).
Go to the Resource Sheet and create a new resource named "Dev_A".
In the Base Calendar column for "Dev_A", assign the custom "6h_work_day" calendar.
Return to the Gantt Chart. Create a new task and open the "Task Information" dialog.
Under the "Advanced" tab, set the Task Type to Fixed Duration.
Go back to the "General" tab and set the task's Duration to 10 days.
Observe at this point: ProjectLibre immediately calculates the Work as 80 hours (10 days * 8 hours/day from the project's default calendar).
Now, assign the resource "Dev_A" to this task.
Expected Result:
After assigning the "Dev_A" resource (who works 6 hours/day), the Work field for the task should automatically recalculate to reflect the resource's actual availability. The correct calculation is:
10 days * 6 hours/day = 60 hours.
Actual Result:
The Work field remains incorrectly locked at 80 hours. The software completely fails to update the Work value based on the assigned resource's specific calendar. The only way to fix this is to manually type "60h" into the Work field.
Analysis and Impact:
This is a critical calculation bug because it breaks the fundamental formula of Work = Duration x Units. The software seems to perform an initial calculation based on the project's default settings and then never re-evaluates it when resource-specific data is provided.
The impact is severe:
It makes the software unreliable. Project plans become inaccurate for any project involving part-time staff, contractors, or any resource on a non-standard schedule.
It forces error-prone manual work. Users have to manually calculate and override the work for every single task, which is inefficient and introduces a high risk of human error.
The problem gets exponentially worse when multiple resources with different calendars are assigned to the same task.
I have attached a series of PDF files that visually document these steps and the resulting incorrect calculation. This behavior seems to be a foundational flaw rather than a minor issue.
Thank you for your attention to this matter. I hope this detailed report is helpful for the development team to address this bug in a future release.
Best regards,
Marcos
Thank you for the note.... that is complex code but should work. We will take a look at it and having rewritten the code in the Cloud AI version will see if we can back fix on the desktop.