Schedule iterations on cadence start day

Requirements #354977 (comment 911380741)

1. All scheduled iterations need to start on the same day as the cadence start day.

2. Start date of cadence cannot be edited once the first iteration has started.

3. Start date of cadence can be edited anytime before the first iteration has started. In this case, the dates of the iterations, if any exists in the cadence, should be re-aligned.

   Example.

   1. If I create a cadence with a start date of Jun 6
   2. It is May 1 and I update the cadence to start the cadence on May 1
   3. The two iterations in June would have their dates changed to May 2-8 and May 9-15 respectively

added frontend groupproject management labels

#353349 (closed) is blocking backend issues so I separate this task from that issue.

added to epic &7567 (closed)

mentioned in epic &7567 (closed)

Setting label(s) devopsplan sectiondev based on groupproject management.

added devopsplan sectiondev labels

@euko, please can you add a type label to this issue to help with issue discovery in issue reports.

added auto updated label

set weight to 2

changed milestone to %14.10

added [deprecated] Accepting merge requests label

added workflowready for development label

mentioned in issue gitlab-org/quality/triage-reports#6909 (closed)

added Stretch label

mentioned in issue gitlab-org/quality/triage-reports#6995 (closed)

mentioned in issue gitlab-org/quality/triage-reports#7074 (closed)

@euko for automatic cadences we will see iterations automatically created as soon as the cadence is created. So we'll never beable to change start date? Or perhaps we can stipp change it if start_date > Date.today?

@mcelicalderonG

It does make sense to allow changing start date when the earliest iteration of a cadence has not started yet -> a user wants to start the cadence earlier.

One edge case I haven't considered: you create a new cadence with the start date set to May 2 (a weekly cadence with 2 iterations in advance) then update the start date to June 6. There is going to be a gap in-between iterations like this:

- May 2, 2022 - May 8, 2022
- May 9, 2022 - May 15, 2022

(notice the gap here)

- Jun 6, 2022 - Jun 12, 2022
- Jun 13, 2022 - Jun 19, 2022

In all other cases, changing the start date doesn't really have any effect but the db record gets updated nonetheless and shown to the user. As an example, create a new cadence set to start in the future. We can choose Apr 11. Pushing back the cadence's start date to Apr 14 won't have any effect.

@gweaver From the technical viewpoint, I don't think we have a bug or serious blocker here. We can even close this issue (or kick it down the road.) The fact that I can change start date like this does confuse me. It's even a "document smell". Do you think we could ask @uhlexsis for help? (how to best deal with the UX here?)

@euko so given:

1. Start date of cadence cannot be edited once the first iteration has started.
2. Start date of cadence can be edited anytime before the first iteration has started.
3. If I have created a cadence with a start date of May 2 and it is before May 2.
4. And I update the start date to be Jun 6.
5. The two upcoming iterations would automatically have their dates changed to Jun 6-12 and Jun 13-19 respectively.

There would still only be 2 iterations and no gap. Conversely...

1. If I create a cadence with a start date of Jun 6
2. It is May 1 and I update the cadence to start the cadence on May 1
3. The two iterations in June would have their dates changed to May 2-8 and May 9-15 respectively

There would also still only be 2 iterations and no gap.

So the validations would be:

1. Start date of cadence cannot be edited once the first iteration has started.
2. Start date of cadence can be edited anytime before the first iteration has started.

I thought initially that we may want to disallow the scenario where a cadence with a start date in the future can be updated to a start date in the past. But I'm not sure if we want to enforce this or not given we want to eventually allow people to import historical iterations/sprints from other tools and allow an issues closed_at date to be manually set.

To really address the "gap problem", the iterations are based on a fixed duration in weeks. So no matter where a start date gets set, we could update the dates on the iterations to match the fixed number of weeks and naturally fit within the time period. This is more or less how Pivotal Tracker behaves FWIW. It's sort of similar to the use case of updating the duration of each iteration within a cadence.

WDYT? Am I missing anything?

Thank you @euko! The behavior @gweaver describes makes sense to me. If we are not doing that already I think we could definitively modify existing iterations start and end date as long as the cadences start date hasn't passed yet.

how to best deal with the UX here?

I might be missing something, @euko, but wouldn't all this happen in the backend? In the frontend you might have to show an error message if you try to update a cadences start date that has already started iterations, but that could come from the backend too. WDYT?

@gweaver, unless I misunderstood you are describing what we need to implement correct? (how the feature should work?)

If not:

Start date of cadence cannot be edited once the first iteration has started.

Not true. The start date of a cadence can be edited (try it right now.)

1. If I have created a cadence with a start date of May 2 and it is before May 2.
2. And I update the start date to be Jun 6.
3. The two upcoming iterations would automatically have their dates changed to Jun 6-12 and Jun 13-19 respectively.

Again no. The two upcoming iterations stay and two additional upcoming iterations are added. With the final state being:

- May 2, 2022 - May 8, 2022
- May 9, 2022 - May 15, 2022
- Jun 6, 2022 - Jun 12, 2022
- Jun 13, 2022 - Jun 19, 2022

The two iterations in June would have their dates changed to May 2-8 and May 9-15 respectively

Sorry! That's not what happens currently. Changing the duration or the number of cadences created in advance does affect the iterations but adjusting the start date doesn't do anything.

@mcelicalderonG

I might be missing something, @euko, but wouldn't all this happen in the backend?

Yeah right. I initially thought we could simply hide away the start date input box from the edit form (now added backend.) We are discussing how the feature should work now:

To really address the "gap problem", the iterations are based on a fixed duration in weeks. So no matter where a start date gets set, we could update the dates on the iterations to match the fixed number of weeks and naturally fit within the time period. This is more or less how Pivotal Tracker behaves FWIW. It's sort of similar to the use case of updating the duration of each iteration within a cadence.

It'd be good to loop in a product designer. I want us to work together more closely if their capacity allows.

(edit: if Start date of cadence cannot be edited once the first iteration has started. is true, I think we'd rather disable or hide the field right?)

To really address the "gap problem", the iterations are based on a fixed duration in weeks. So no matter where a start date gets set, we could update the dates on the iterations to match the fixed number of weeks and naturally fit within the time period.

In practice, we could end up creating a lot of iterations if we allow the start date to be set far in the past with our current implementation.

1. Start date of cadence cannot be edited once the first iteration has started.

1. Start date of cadence can be edited anytime before the first iteration has started.

Makes sense to me. We will see if we missed anything.

@gweaver, @mcelicalderonG Do you want me to go ahead and pick up this issue tomorrow (or #354949 (closed))?

unless I misunderstood you are describing what we need to implement correct? (how the feature should work?)

That's what I understood, @euko

In practice, we could end up creating a lot of iterations if we allow the start date to be set far in the past with our current implementation.

Right again, @euko. I was pretty sure we were validating start_date >= Today, but we are not. Should we do that, @gweaver? Is there any use case for having the start date that is in the past? Either on create or update.

@mcelicalderonG we can see once we release this in the wild but I think there inevitable will be at some point in the future. There were lots of requests to do so with the first MVC of iterations but I think that was to solve the problem of migrating data to iterations and/or adding issues to an iteration after the iteration was closed because someone forgot during the iteration. We can solve both of these use cases separately in the future.

It'd be good to loop in a product designer. I want us to work together more closely if their capacity allows.

@badnewsblair Can we get a little help with this, either from you or Alexis? We're trying to determine how this can be handled before it goes to GA (ideally before the end of %14.10)

@donaldcook What would be the requirements/commitments from UX?

cc: @uhlexsis

@euko ^, what sort of help are you looking for from UX?

mentioned in issue #354949 (closed)

mentioned in issue gitlab-org/quality/triage-reports#7174 (closed)

added backend label