BigPicture Gantt is not updated with Task's Actual Start/Finish Date

[Cesar Barragan]

I am fairly new to BigPicture.

I created a bunch of JIRA Tasks and arranged them using BigPicture Gantt chart according to my Planned Start/Finish Dates (01/08/2021).
So when I complete such tasks and enter the Actual Start/Finish Date (01/29/2021) along with the logged hours  (which for whatever reason it is not the same as the Planned one). I would expect to see that change in the Gantt, but no, I still see the Task in the same original date.

Is it possible to automatically have the tasks updated in the Gantt with the Actual Start/Finish Date once I have completed and updated the Task using JIRA? I really need to now if this is possible since we need to know how the completion date will affect the overall planning and timing for linked Tasks

[Anna-SoftwarePlant]

Hello @Cesar Barragan 
Let me shed more light on the logic behind synchronization. By default, our app requires two points on the timeline (in other words, two dates) to generate a taskbar and determine the start and endpoints. Those points in time are the task's 'Start date" and 'End date' and are stored as 'Start date' and 'End date' custom fields by default.

However, BigPicture allows you to map also other fields to represent Start & End Date. In general, there are three main strategies for task synchronization:

• Not synchronized - use this option if you do not want to update Jira issues while still planning using the Gantt module. Changes to date estimates will not sync to Jira, which means that task start and end dates might differ from Jira issues' estimates.
• Two 'Date picker' (or 'Date time picker') fields - recommended when assignees work on multiple tasks simultaneously.
• One 'Date picker' (or 'Date time picker') field and a time estimate field (Original estimate or Time spent + Remaining estimate) - recommended for working on one task at a time.

In our documentation, you will find more about synchronization settings of the Start & End dates.

As you noticed, the End Date could be mapped only to one field. Therefore a solution may be setting up the value of the Resolved field in the currently synchronized with the End Date field. 3rd party automation tools (e.g., Script Runner may be useful here).

If you have further questions, I will gladly answer them. 

Best,
Anna / SoftwarePlant

[Andrei Maroz]

Hey @Anna-SoftwarePlant 
We've recently moved to Jira Cloud and considering using BigGantt for our project. I've confitured that and in general everything looks great but there is one problem I can't solve.
When I resize the task on the Gantt to change the End date I see that End Date is updated on the Gantt and in the task itself but then in 5-8 seconds looks like BigGantt resets End Date back to Start Date no matter what the estimate is (1 hour or 1 week).
The same time I don't get the same problem with the Start Date field.

May be you can help me to understand what I'm missing in the configuration.

[Anna-SoftwarePlant]

Hi @Andrei Maroz

The basic question is, in how many Programs is a given issue? End Date is a task attribute, and its value in every Program Box must be equal. Therefore if a task is in the scope of another program, please check if it has any dependency links or period modes that influence auto-scheduling. 

Once you click on a taskbar, you can check in how many Progam Boxes a given issue is included.

[Andrei Maroz]

@Anna-SoftwarePlant I'm afraid there must be something else impacting that. As far as I understand I don't have any dependencies that can influence the End Date of tasks. This is what I have for a Task I'm experimenting with:

Perhaps there are some other configurations in BigGantt or Jira that manage the logic of End Date field

[Andrei Maroz]

Just for future reference if someone face the same problem. I didn't manage to find the root cause of my problem so I created my own custom field ("Estinated End Date" of a Date picker type) and linked BigGantt 'End Date' with my own custom field. In this case syncrhonisation works correttly.