1. Issue

JIRA tracks issues, which can be bugs, feature request, improvement and any other tasks you want to track. JGCP supports all of them without any modifications on data structure. Precisely, all issues of any project in Progress can be displayed automatically in Gantt Chart.

1.1. Start time

By default, JIRA has not a field corresponding to Start time of an issue. In JGCP, by default, it is a derived information of "Estimate", "Due date" and Links link dependency and containment. It is possible to use a delicate field of type Date used as "Start Time". 

Here is the algorithm:

1.2. End time

Here is the algorithm for determining the value of "End time":

When you modify the "End time" in Gantt Chart or Spreadsheet and if a custom field is specified, the custom field will be used. Otherwise, "End Time" is changed.

For a version, if the project is enabled for Greenhopper and the option "Enable integration with GreenHopper:" is enabled, the End Time of setting in GreenHopper is used. Otherwise, its release date will be used and End Date.   

1.3. Duration and Units

Duration is a time span of an issue. It depends on two factors: a total amount of time it would take to complete this issue and resource allocation. A total amount of time is kept in the fields "Original Estimate", "Remaining Estimate" and "Spent Time", but there is not an equivalent information about resource allocation in JIRA. We have to introduced a custom field to manage it, named as Units. Its value should be between 1 and 100. It represents the percentage of resource allocation. The default value is 100.

1.3.1. Leaf Issue

If the issue is not started, the duration is calculated using this formula:

Duration = Original Estimate * 100 / Units.

In this no-start state of issue, when we modify the duration, "Original Estimate" will be modified.

When the issue gets started, the following formula gets used:

Duration = (Remaining Estimate + Spent Time) * 100 / Units.

When the Remaining time is 0, the Original Estimate will be used.  

The change of duration of started issue via Gantt-chart will modify both "Original Estimate" and "Remaining Estimate".

1.3.2. Container Issue

The duration of a container is calculated using the sum of duration of its children. 

1.3.3. Version

Same as container issue, the duration of a version is calculated using the sum of duration of its children. 

1.4. Percent Done

The progress state is indicated by a pecerntage. The method of computing is different through issue type

2. Timing Issue

From scheduling behavior standpoint, all issues are divided in two categories through the value of the field "Due Date": Fixed-Scheduled issue and Auto-Scheduled one.

2.1. Auto-scheduled issue

An auto-scheduled issue is an issue whose field "Due Date" is empty. Its scheduled is yet really fixed. The above algorithm is used to reduce the "Start Time" and "End Time". For example, if unscheduled B issue is Start-to-Finish dependent on A, the Start date of B will be used as the End date of A.

An auto-scheduled issue becomes scheduled one when you move it by mouse or change the End date value in Spreadsheet. It is decorated by an '?' icon at left and on top of issue bar: 

2.2. Manual-Scheduled Issue

A Scheduled issue has a fixed "Due Date" or a working log, named as Manual-schedule, By default it is determined by the field "Due Date" or Custom field if it is setup. Once there is a working log, the issue remains in Manual-scheduled. It cannot go back to auto-scheduled.

If an issue depends on a resolved or closed issue, it becomes Manual-scheduled. It cannot go back to auto-scheduled by the context menu "Convert to Auto-Scheduled Issue". It can go back to auto-scheduled if all dependencies on the resolved issues get deleted..

2.3. Not Schedulable Issue

if an issue has a working log, this issue is not schedulable. It means this issue cannot go back neither to Auto-Scheduled, or not to Manual-Scheduled directly. The only solution to go back to schedulable issue is to delete its all working logs.

3. Scheduling Constraint

From the point of view of time constraint, most of issues are constrained by the working schedule. But in practice, some tasks have to be carried out beyond the Working Schedule such as Deployment, Database backup/restore. We reference an issue constraint by the working schedule as WorkingTime issue, and an issue without this constraint as Freetime issue. Anytime, a WorkingTime issue can become Freetime issue via context menu, and vice versa.

4. Milestone

Within the framework of project management, a milestone is the end of a stage that marks the completion of a work package or phase, typically marked by a high level event such as completion, endorsement or signing of a deliverable, document or a high level review meeting.

In JIRA, there is not such notation. JGCP takes any issue of any type as a Milestone when its "Original Estimate" is zero.

5. Container Issue

A container Issue is in fact a dynamic issue. The schedule of a dynamic task depends entirely on its children. The change of the duration and workload of a child issues will automatically update the one of container issue. The "Time Planning" of JGCP provides two modes: scheduling and tracking. All fields of a dynamic issue are read-only.

All "Due Date" and "Original Estimate" and working log are ignored. Its "Start Date", ""End Date" and its duration depends on its children. The "Start Date" and "End Date" are respectively the earliest date and the latest the "End Date" of its children.

5.1. Sub-task Management

Sub-tasks are a convenient way to organize tasks in hierarchy by classification or decomposition.

In JIRA, it is possible to enable or disable the support of Sub-task via the Administration. But there is a limitation: one level Sub-task is supported, it is not possible to create a Sub-task of a Sub-task. 

This plugin provides a possibility to bypass this limitation using a custom link. The table below show the possible result of combinations of JIRA Sub-task, Respect JIRA Rule and Custom Link: 

where "Respect JIRA Rule" and "Custom Link" are the options in the administration "Global" of this plugin.

6. Version

The version is directly supported in JGCP.  The above algorithm is used to calculated the "Start Time" and "End Time" if "Release Date" is empty. 

7. Multiple Presentations of Same Issue

It is possible that an issue will be displayed more than one time. For example, an issue is fixed in more versions. In this case, one issue will be displayed with all information such as dependency and children if its has. Other presentations play a proxy; only the fields of the root issue will be cloned and all links will be ignored. The cloned issue is displayed in dash border.