Patch #3195
open
issue's start date could be the latest due date of predecessors
Added by Sanghyuk Suh over 15 years ago. Updated 9 months ago.
0%
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.
Files
| successor_soonest_start.diff (521 Bytes) successor_soonest_start.diff | Sanghyuk Suh, 2009-04-17 06:54 | ||
| 0001-allow-start-date-of-a-issue-to-be-the-latest-due-dat.patch (5.48 KB) 0001-allow-start-date-of-a-issue-to-be-the-latest-due-dat.patch | Marius BĂLTEANU, 2018-05-18 22:00 | ||
| overlapping-gantt-bars@2x.png (33 KB) overlapping-gantt-bars@2x.png | Go MAEDA, 2018-05-19 05:06 | ||
| 3195-change-default-delay-date.patch (390 Bytes) 3195-change-default-delay-date.patch | hange issue relation default delay date to -1 (when type=precedes) | Yuuki NARA, 2018-05-29 16:23 | |
| autoreschedule-problem-1@2x.png (9.64 KB) autoreschedule-problem-1@2x.png | Go MAEDA, 2018-06-23 08:15 | ||
| autoreschedule-problem-2@2x.png (9.55 KB) autoreschedule-problem-2@2x.png | Go MAEDA, 2018-06-23 08:15 | ||
| UI_bit_for_setting_precedes.PNG (3.16 KB) UI_bit_for_setting_precedes.PNG | Marian Liviriniu, 2021-08-06 22:33 |
Related issues
Updated by Yohann Monnier over 15 years ago
I had the same problem. Thank you for this improvment. I hope it will be published in the main trunk.
Updated by Anonymous
Updated by Etienne Massip over 13 years ago
- Category set to Issues
- Target version set to Candidate for next minor release
Updated by Maxim Nikolaevich about 13 years ago
i disagree
I can continue work on another task in same day
Updated by Mischa The Evil about 13 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...
Updated by Go MAEDA over 9 years ago
- Has duplicate Defect #19516: Issue "preceeds" error: If B follows A, B starting date !=< ending date of A, should be Bs !< Ae added
Updated by Go MAEDA over 9 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.
Updated by David Gessel over 9 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.
Updated by Marius BĂLTEANU over 6 years ago
- File 0001-allow-start-date-of-a-issue-to-be-the-latest-due-dat.patch 0001-allow-start-date-of-a-issue-to-be-the-latest-due-dat.patch added
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.
Updated by Go MAEDA over 6 years 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.
Updated by Marius BĂLTEANU over 6 years ago
- Assignee set to Marius BĂLTEANU
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.
Updated by Marius BĂLTEANU over 6 years 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").
Updated by Yuuki NARA over 6 years 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.
Updated by Go MAEDA over 6 years 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.
Updated by Yuuki NARA over 6 years 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.
Updated by Yuuki NARA over 6 years 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
Updated by Marius BĂLTEANU over 6 years 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'.
Updated by Go MAEDA over 6 years ago
- File autoreschedule-problem-1@2x.png autoreschedule-problem-1@2x.png added
- File autoreschedule-problem-2@2x.png autoreschedule-problem-2@2x.png added
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;'.
Updated by Go MAEDA over 6 years 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.
Updated by Go MAEDA over 6 years 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.
Updated by Marius BĂLTEANU over 6 years ago
- Assignee deleted (
Marius BĂLTEANU) - 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.
Updated by Marius BĂLTEANU about 6 years ago
- Has duplicate Feature #5655: Allow related issues to be started/due on the same date. added
Updated by Marian Liviriniu over 3 years ago
I regularly have to deal with small issues (1-4 hours, lees than a day's work) and I find the UI part for linking issues with precedes/follows a bit confusing or, should I say, insufficiently detailed?
Even from when I've started using Redmine, my impression was that the Delay 0 days field is telling me: zero time delay between them. But no, there was a "real delay" of ~1 day, and the following issue appeared on the next day on the calendar. I understood that Redmine plans and links issues only based on full days as unit of measure, not time. And this clashes logically with real situation of multiple small issues per day where 1 issue is measured in hours not in days.
If no change is to be made to meaning of delay (causing migration etc.) maybe it would help to just add, I don't know, a checkbox stating "no time delay at all" / "link issues on same day" and/or tooltip on "Delay" word. Thusly treating the non-intuitive aspect of "delay -1 days" and helping to clarify that the term "delay" currently means "calendar gap measured in days".
And capability of setting it checked/unchecked as default in Project Settings.
PS: I know it's long but for me at least, "calendar gap in days" is more clear than "delay in days".
Updated by Dotan Cohen 9 months ago
I agree that this is an important change. Many tasks can take an hour or two, I'll do half a dozen in a day. The -1 day hack is a workaround, not a solution. Also, I do not see a problem with the overlapping Gantt date display - that is quite the behaviour that I would expect in fact.
However, I agree that the change will require a change in user habits, therefore should be confined to a major Redmine release, not a point release. I am anxiously awaiting this fix, off-by-one errors are horrible.