[$50] Admins should be able to modify the actual start and completion dates of a milestone

[vikasrohit]

As of now, we don't allow any one to update the actualStartDate and completionDate of a milestone. We assume that CA/Copilots would always start the milestones one time and they don't need back entries. However, in practical, many time we need to update the milestones dates to a date in past when copilots/CAs forget to updates the dates of the milestones on time. To facilitate that use case for CAs/copilots we need to equip admins with feature of updating the timeline of a phase in past as per requirement by CA/copilot. Followings are the places which need to be updated for an admin:

1. Ability to update the start date of an activated phase
2. Ability to update the start date of an activated timeline
3. Ability to update actualStartDate and completionDate fields of any milestone (Please right now both of these fields are allowed in PATCH request for a milestone. We need to limit these fields to be updated only by admins.)

[maxceem]

1. When we edit phase we use the next form which let us edit not only start date but other properties of a phase including deleting phase:

   

   • So far when phase is completed, we don't show such edit form at all. So for admins we would have to show it even after phase is completed.
   • Which fields should be able admin to edit in this form after phase is completed? Only Start Date or any other?

2. Ability to update the start date of an activated timeline

   So far we don't have any UI to update the start date of timeline even before it's activated. I guess ideally, the start date of timeline should be updated automatically based on the milestones inside. Though, so far we don't update the start date of timeline automatically. And actually we don't really use it. Which way to go you prefer?

   1. Fix server-side to update start date of timeline automatically.
   2. Add some UI to update timeline start date.
   3. Don't do anything.

3. Ability to update actualStartDate and completionDate fields of any milestone

   To confirm:

   1. If milestone has active status, for admin users we should show actualStartDate for editing.
   2. If milestone has completed status, for admin users we should show actualStartDate and completionDate for editing.

[vikasrohit]

1. Let the admin update all fields
2. If we do 1 and it has cascading effect, of phase start date update, on the start date of the timeline, I think we don't need to do anything there.
   On automatic update of timeline based on milestone updates, I don't yet fully understand the need of updating the timeline based on milestone's start date, though we are doing that for the end date. In fact, we do that, I guess there is no sense of maintaining the start and end dates in the timeline except having a quick access to the start-end and duration of the timeline which is in fact the only use case as of now as well. 😬 Let me know your further thoughts, I am trying to clean up the relationship between timeline and milestones in general considering that it can be a generic module to be reused by other services as well.
3. Yes for both

[maxceem]

2. Let me know your further thoughts, I am trying to clean up the relationship between timeline and milestones in general considering that it can be a generic module to be reused by other services as well.

   For the timelines so far I don't see general logic. The only thing I see we actually never use start/end date of timeline we always calculate it using milestones or get from phase, which is also kind of redundant, as we always have milestones for phase to calculate start/end date and duration.

   So at the moment, I'm biased to remove any usage of start/end of timeline. And also never updated start/end date for timeline (which we do now). And always use milestones only. We can come back to this if need it for somethings in the future.

[vikasrohit]

Yep, Agreed. And in fact we discussed internally to clean up the complexity involved in the milestones themselves. Here is summary of our new clean model:

1. Add new fields called plannedDate and actualDate
2. Ignore existing date fields e.g. startDate/actualStartDate/endDate/completionDate
3. Ignore duration field as well
4. In very simple words, a timeline would be a collection of milestones which act as simple points and does not have any duration
5. Now it is all upto the client how they want to use and render the timeline
6. We can also get rid of redundant date and duration fields on the timeline object as well

If you notice, this approach will make the logic of milestone management very simple e.g. we won't need any cascading updates when a new milestone is created or existing milestone is updated for any field. I would make the logic of progress calculation of the timeline very easy and straightforward. It would make the movement of the milestones within timeline very simple as well.
Let me know what do you think about this. I would like to get this going and completed before we get the green signal for work management features. In our theory, backward compatibility is also not so much difficult in this case, we can simply do plannedDate=startDate and actualDate=completionDate for all existing milestones and our new rendering logic would render the timeline correctly even for the existing phases.

[maxceem]

I like the approach as it looks super simple and straightforward, unlike what we have now.
One note comes to mind. You previously noticed, that in future, you would like to use the timeline with milestones for challenges phases like registration, submission, review and so on. As such phases may go in parallel, the suggested simple approach would not be enough for such cases.

For the rest of features which we currently have, this approach sounds good to me.

Should we do such changes in the current dev branch? Or this should be done only for new changes in workstream branches server-side and client-side?

[vikasrohit]

I think parallel phases is also workable with this approach as we can add two milestones for a phase one for the start and another for the end and there can be two milestone with same date.

The backend end changes for workstream is already in dev, right? So, I guess, we should be okay to have this in dev as well, however, for now, lets keep the changes in separate branches for both front end and back end. And lets see how this logic works, especially for the existing timelines.

[maxceem]

I think parallel phases is also workable with this approach as we can add two milestones for a phase one for the start and another for the end and there can be two milestone with same date.

So you mean that new milestones, would be just point marks, and we would fully decide how to use them clients side. So for the challenge phases we would need 2 milestones to define one challenge phase, something like this:

[
   { 
      type: "registration-start",
      plannedDate: "12 September"
   },
   }
      type: "registration-end",
      plannedDate: "17 September"
   }
]

So we would also need 2 milestone types for each challenge phase, one to indicate start, and another one to indicate the end.

The backend end changes for workstream is already in dev, right?

Right, for server-side workstream is already in dev. So we can add new changes to the new branch.

For the client side we have workstream changes separately. So the question for client-side is, should we make such changes in dev so we can release new milestones earlier? Or should we make changes to milestones only in workstream branch so we would release new milestones together with workstreams.

[vikasrohit]

So we would also need 2 milestone types for each challenge phase, one to indicate start, and another one to indicate the end.

Yes, exactly.

For the front end, please create new branch out of dev and we would resolve the conflicts or will redo the changes in a another feature branch out of workstreams branch.