Patch #3195

issue's start date could be the latest due date of predecessors

Added by Sanghyuk Suh over 9 years ago. Updated 6 months ago.

Status:NewStart date:2009-04-17
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-

Description

currently, the start date of a issue must be later than the latest due date of predecessors.
it means i cannot continue working in the same day.

i have made a patch for fix it.

successor_soonest_start.diff Magnifier (521 Bytes) Sanghyuk Suh, 2009-04-17 06:54

0001-allow-start-date-of-a-issue-to-be-the-latest-due-dat.patch Magnifier (5.48 KB) Marius BALTEANU, 2018-05-18 22:00

overlapping-gantt-bars@2x.png (33 KB) Go MAEDA, 2018-05-19 05:06

3195-change-default-delay-date.patch Magnifier - hange issue relation default delay date to -1 (when type=precedes) (390 Bytes) Yuuki NARA, 2018-05-29 16:23

autoreschedule-problem-1@2x.png (9.64 KB) Go MAEDA, 2018-06-23 08:15

autoreschedule-problem-2@2x.png (9.55 KB) Go MAEDA, 2018-06-23 08:15


Related issues

Duplicated by Redmine - Defect #19516: Issue "preceeds" error: If B follows A, B starting date !... Closed
Duplicated by Redmine - Feature #5655: Allow related issues to be started/due on the same date. Closed 2010-06-08

History

#1 Updated by Yohann Monnier over 9 years ago

I had the same problem. Thank you for this improvment. I hope it will be published in the main trunk.

#2 Updated by Anonymous over 9 years ago

+1

#3 Updated by Etienne Massip over 7 years ago

  • Category set to Issues
  • Target version set to Candidate for next minor release

#4 Updated by Maxim Nikolaevich about 7 years ago

i disagree
I can continue work on another task in same day

#5 Updated by Mischa The Evil about 7 years ago

Maxim Nikolaevich wrote:

i disagree

I can continue work on another task in same day

Looking at your second sentence, you agree (instead of disagree) with a change as proposed in this issue...

#6 Updated by Go MAEDA over 3 years ago

  • Duplicated by Defect #19516: Issue "preceeds" error: If B follows A, B starting date !=< ending date of A, should be Bs !< Ae added

#7 Updated by Go MAEDA over 3 years ago

+1
I think this should be changed.
When I have finished the preceding task, I will start following tasks in the same day.

#8 Updated by David Gessel over 3 years ago

I apologize, I didn't find this 6 year old Issue and filed #19516. Thanks to Go MAEDA for catching it.

If B's start (Bs) follows A's end (Ae), Bs !=< Ae does not reflect typical reality, it should be Bs !< Ae.

It is perfectly logical and reasonable to plan to start issue B the same day issue A is resolved. There's no reason to enforce in planning an "A's done! Everybody go home early!" rule. It should be entirely practical to plan to resolve 100 sequential issues on a single day, though perhaps a bit optimistic even just for the overhead of closing them out.

#9 Updated by Marius BALTEANU 7 months ago

I think we should allow the start date of an issue to be in the same day with the latest due date of predecessors.

I've updated the patch made by Sanghyuk Suh to apply cleanly on the current trunk and also to fix the failing tests.

#10 Updated by Go MAEDA 7 months ago

I think the change logically breaks gantt. If you set the start date to the same date as the due date of the preceding issue, each gantt bar overlaps. It looks that a person starts working on the following issue before finishing the preceding issue. With the patch, gantt bars of preceding and following issue overlap by default.

#11 Updated by Marius BALTEANU 7 months ago

  • Assignee set to Marius BALTEANU

Go MAEDA wrote:

I think the change logically breaks gantt. If you set the start date to the same date as the due date of the preceding issue, each gantt bar overlaps. It looks that a person starts working on the following issue before finishing the preceding issue. With the patch, gantt bars of preceding and following issue overlap by default.

I see your point of view and I'll think how we can fix this visual issue because I find it more annoying to force the start date of the following issue at least next day of the due date.

#12 Updated by Marius BALTEANU 7 months ago

What about in addition to this change we set the default delay for "Precedes/Follows" relations to 1 day?

In this way:
- gantt bars of preceding and following issue will not overlap by default (the current behaviour).
- users will have the possibility to set the start date of the following issue in the same day with the due date of the preceding issue. I don't see a real issue to have the gantt bars overlaping in this case and if there will be complains, we can treat somehow visually (for example: by ending the due date bar somewhere in the "middle of the day").

#13 Updated by Yuuki NARA 7 months ago

+1

If issues relations (type=Precedes) set,
it is not possible to set short time work (for example approval / shipment work) as issue to be performed on the same day .

This makes it difficult to correctly set work dependencies on Redmine.

By setting delay to -1 in relations section type=Precedes , it is possible to set same day.
But it is not intuitive, it seems not widely known.

As a display method of the Gantt chart, I think there is a method of drawing lines diagonally.

#14 Updated by Go MAEDA 7 months ago

Marius BALTEANU wrote:

What about in addition to this change we set the default delay for "Precedes/Follows" relations to 1 day?

It is a solution to the problem.

But another my concern about the change is that it will change the meaning of "delay" and behavior of auto rescheduling. I think it is breaking change.

In the current implementation, setting "delay 0 days" updates the start date of the following issue to the day after the due date of the preceding issue. However, after applying the patch, setting "delay 0 days" updates the start date of the following issue to the same date of the due date of the preceding issue. It may confuse the existing user and break the existing gantt.

In the current versions of Redmine, you can start the following issue on the same date of the due date of the preceding issue if you set the "delay" to -1. I think the patch can keep compatibility with the current versions if the patch makes use of the behavior.

#15 Updated by Yuuki NARA 7 months ago

Go MAEDA wrote:

But another my concern about the change is that it will change the meaning of "delay" and behavior of auto rescheduling. I think it is breaking change.

I understand that there is data compatibility problem.

Set default delay value to -1 can keep compatibility with the current versions userdata.

What do you think?

The default behavior will change ,but I think that it is a natural direction.

#16 Updated by Yuuki NARA 7 months ago

I made tiny patch for #note-15
Change issue relation default delay date to -1 (when type=precedes)

app/models/issue_relation.rb
def handle_issue_order

#17 Updated by Marius BALTEANU 6 months ago

My bad, I made a mistake and I wasn't aware that it is possible to set negative values in the delay field.

Still, I consider not so transparent for users that hardcoded "+ 1". For me, filling 0 in the delay field and receiving the start date of the following issue next day after due day is confusing. Also, still confusing is to set -1 and to obtain start date = due date.

Go Maeda, just to be sure that I understand correctly, if we remove that hardcoded "+1 " and we set "1" as default value for the delay field, you're worried that we'll break the existing data, right? In this case, maybe we can migrate the existing data and set 1 where delay is 0.

At the end, we will have the following changes:
1. Remove hardcoded "+1"
2. Set 1 as default value for delay field
3. Migrate existing data and set delay = 1 where delay = 0

As well, I can live with the current behaviour but then we should remove this ticket from "Candidate to next minor release'.

#18 Updated by Go MAEDA 6 months ago

Marius BALTEANU wrote:

Go Maeda, just to be sure that I understand correctly, if we remove that hardcoded "+1 " and we set "1" as default value for the delay field, you're worried that we'll break the existing data, right?

Yes, exactly. The patch will break a schedule of existing projects. The following screenshots illustrate my concerns:

1. There are two issues, "foo" and "bar". "bar" follows "foo" with 0 days of delay.

2. Apply 0001-allow-start-date-of-a-issue-to-be-the-latest-due-dat.patch and delay the due date of issue "foo" one day. The rescheduled start day of issue "bar" should be June 7th, but actually it will be June 6th.

In this case, maybe we can migrate the existing data and set 1 where delay is 0.

At the end, we will have the following changes:
1. Remove hardcoded "+1"
2. Set 1 as default value for delay field
3. Migrate existing data and set delay = 1 where delay = 0

It is an acceptable solution. I think step 3 should be 'update issue_relations set delay = delay + 1 where delay is not null;'.

#19 Updated by Go MAEDA 6 months ago

Marius BALTEANU wrote:

For me, filling 0 in the delay field and receiving the start date of the following issue next day after due day is confusing. Also, still confusing is to set -1 and to obtain start date = due date.

I can understand what you wrote. Setting -1 is quite confusing. However, I am still in favor of the current behavior. Please see the following screenshot. Do you think the delay is zero? In Redmine 3.4, the delay of the following issue ("bar") is -1. I think -1 is appropriate rather than 0 because each gantt bars overlap.

#20 Updated by Go MAEDA 6 months ago

  • Target version changed from Candidate for next minor release to Candidate for next major release

Marius BALTEANU wrote:

As well, I can live with the current behaviour but then we should remove this ticket from "Candidate to next minor release'.

Yes, the change is too big for minor releases.

#21 Updated by Marius BALTEANU 6 months ago

  • Assignee deleted (Marius BALTEANU)
  • Target version deleted (Candidate for next major release)

Lets leave it as it is for now. I've removed it from Candidate for next major release until we get more feedback from the community and we agree to a solution.

#22 Updated by Marius BALTEANU 29 days ago

  • Duplicated by Feature #5655: Allow related issues to be started/due on the same date. added

Also available in: Atom PDF