Project

General

Profile

Actions

Feature #279

closed

issue dependencies

Added by Jason Huebel about 17 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Normal
Category:
Issues
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

First, redMine is great as it is already. Within 10 minutes of setting it up, it's become an invaluable tool.

As for my feature request, it would helpful if you could set dependencies for issues. That is, issues could be dependent
on each other. If a main issue has dependencies, then the dependencies must all be resolved, rejected or closed before
the main issue can be resolved, rejected or closed.

If that's too complicated for now, then simple dependency tracking would work too.


Related issues

Related to Redmine - Feature #2448: Graphviz of ticket dependencies (with example)New2009-01-06

Actions
Related to Redmine - Defect #1740: Actually block issues from closing when relation 'blocked by' isn't closedClosedJean-Philippe Lang2008-08-04

Actions
Actions #1

Updated by Jean-Philippe Lang about 17 years ago

Hi,
Thanks for your interest. Issue dependencies is an important
feature and it should be added in one the upcoming releases.
I'll try to provide a roadmap as soon as possible.

Best regards,
Jean-Philippe

Actions #2

Updated by Tim Rohde about 17 years ago

Dependencies are critical for any decently large project. Without
dependencies and the ability to shift the times for all downstream
work, the user is left to manually alter all the times each time
there is a change. That is not practical on anything but toy
projects.

Actions #3

Updated by Tim Rohde about 17 years ago

BTW - Did I mention that Redmine is beautiful and was incredibily
easy to setup?!

Actions #4

Updated by Jean-Philippe Lang about 17 years ago

Hi Tim,
Thanks for your last comment :-)
I know this feature is critical. A few weeks ago, I started to
code what you ask (end/start, end/end ... dependencies) with
automatic shifting.
This feature is not yet stable or even finished but it should
be added in a near future.

Regards

Actions #5

Updated by Pablo Lerina about 17 years ago

Hi Jean!

These codes are in trunk? I would like to help with this issue!

thanks.

Actions #6

Updated by Jean-Philippe Lang about 17 years ago

No, these codes haven't been committed in trunk.
There's some code in the work branch but i'm not sure it's a
good starting point.

Actions #7

Updated by Laran Evans almost 17 years ago

+1 for this one from me. I use JIRA primarily at work and we
couldn't get our job done without the ability to link issues.

Actions #8

Updated by Jean-Claude REPETTO almost 17 years ago

J'appuie cette demande. C'est une fonction indispensable pour
gérer les tâches d'un projet.Le début d'une tâche doit pouvoir
dépendre de la fin d'une ou plusieurs autres tâches.

Actions #9

Updated by Nikolay Solakov almost 17 years ago

I was just looking if there is someone asking for issue dependencies
and found that request :)
I vote for it with the two hands :)

This is very important, especialy for big enterprise projects
I am working on...

Thanks!
I'm waiting now.

Actions #10

Updated by Jean-Philippe Lang almost 17 years ago

Commit 506 adresses this feature. It's not finished yet.
If you want to have a try, just update your installation and
set the permissions for adding and removing relations. Commit
message follows. Any feedback is welcome.

Issue relations first commit (not thoroughly tested). 4 kinds
of relation are available:
  • relates to: do nothing special. Just to know that the 2 issues
    are related...
  • duplicates: will close the related issue with the same status
    when closing the issue (not implemented yet)
  • blocks: will require to close the blocking issue before closing
    the blocked issue (not implemented yet)
  • precedes (end to start relation): start date of the related
    issue depends on the due date of the preceding issue (implemented).
    A delay can be set so that the related issue can only start n
    days after the end of the preceding issue. When setting dates
    for an issue, dates of all downstream issues are set according
    to these relations.

To set a relation, the 2 issues have to belong to the same project
(may change in the future). So if an issue is moved to another
project, all its relations are removed.
Circular dependencies are checked when creating a relation.

Actions #11

Updated by Nikolay Solakov almost 17 years ago

Hello,
I tried it. Very good work!
Here it is something related to the implemented "precedes"
feature
(not very good in english, so explaining a lot :) ) :
1. Principle of action: When I set the precedes of
issue1 to issue2 - practicly I don't care what are the
dates(begin,due) of
issue2 - I just consider that issue2 will start after the
delay
when issue1 is closed(once set, the dates are irreversible,
we are building a tree). If I consider to take off the
relation-
well, I should edit the dates of issue2.
2. Should be done(maybe just missed): When I set the delay for
example 10 days,
the start date of issue2 is set properly. But then after
editing issue1 and
setting the delay for example 5 days, issue2 continues to
start after 10days.
3. The due_date of issue2 should be set to nothing if it's empty
or
to the proper delay (I think this is implemented).

Thanks,
Nikolay

Actions #12

Updated by Mark Elrod about 16 years ago

+1

Actions #13

Updated by gabriel scolan almost 16 years ago

To complement the feature, wouldn't it be interesting to :
- set the relation "duplicate" automatically while making a "copy" of an issue ?
- display a dependency graph of related issues ?
It is minor but could help :-)

gabriel

Actions #14

Updated by Roger Rogers almost 16 years ago

Jean-Philippe Lang wrote:

Commit 506 adresses this feature. It's not finished yet.
If you want to have a try, just update your installation and
set the permissions for adding and removing relations. Commit
message follows. Any feedback is welcome.

Is this feature still actively in development? Just curious, and would love to see the task dependency/Gantt chart features improved.

Actions #15

Updated by Mischa The Evil over 15 years ago

I noticed that my feature-request (#1740) is somehow related to this older request.

Regarding the implementation of a dependency-graph which I really think will be an great function. I have some working-experience using Flyspray which uses WebDot and Graphviz to render linkable graphs of related issues and it really helps maintaining the overview of bigger amounts of (nested) related issues.
Though I don't know if that's an option using Ruby on Rails.

Actions #16

Updated by jason axelson over 14 years ago

I am also wondering if anyone is still working on this?

Actions #17

Updated by David Leuschner over 14 years ago

Redmine seems great, but as long as this feature is missing, we'll stick to Bugzilla although we'd really like to switch to Redmine. Is this request still considered important? It's already over 2 years old.

Actions #18

Updated by Hugo Ferreira about 14 years ago

David Leuschner wrote:

Redmine seems great, but as long as this feature is missing, we'll stick to Bugzilla although we'd really like to switch to Redmine. Is this request still considered important? It's already over 2 years old.

I suspect its this issue log that is long due of an update, rather than the functionality being missing. I've just been evaluating Redmine version 0.9.0 and this works flawlessly:

Issue 1 "related to" Issue 2  --causes-->  Issue 2 "related to"    Issue 1
Issue 1 "blocks"     Issue 2  --causes-->  Issue 2 "blocked by"    Issue 1
Issue 1 "duplicates" Issue 2  --causes-->  Issue 2 "duplicated by" Issue 1
Issue 1 "precedes"   Issue 2  --causes-->  Issue 2 "follows"       Issue 1
Issue 1 "follows"    Issue 2  --causes-->  Issue 2 "precedes"      Issue 1

Furthermore, the follows/precedes relationship will also touch the start/due dates according to the delay set.

Actions #19

Updated by Felix Schäfer about 14 years ago

  • Category set to Issues

Hugo, you are right that what I'd call "lazy relationships", i.e. relationships that only link issues to one another and don't enforce anything (the exception being follows/precedes), are implemented, and afaik that's what bugzilla has to offer to. This request has a broader scope though, and calls for harder "dependencies", i.e. relationships that enforce possible or not possible states and attributes in the other tickets (i.e. B and C are parts of A, so A can't be closed unless B and C are, or B blocking A makes A uncloseable …), and in that is somewhat related to #443.

Actions #20

Updated by Mischa The Evil about 14 years ago

Felix Schäfer wrote:

Hugo, you are right that what I'd call "lazy relationships", i.e. relationships that only link issues to one another and don't enforce anything (the exception being follows/precedes), are implemented, and afaik that's what bugzilla has to offer to. This request has a broader scope though, and calls for harder "dependencies", i.e. relationships that enforce possible or not possible states and attributes in the other tickets (i.e. B and C are parts of A, so A can't be closed unless B and C are, or B blocking A makes A uncloseable …), and in that is somewhat related to #443.

Felix, please note r2800 which resolved issue #1740. This enhancement is included in Redmine 0.9.0 and makes it possible to actually prevent issues from being set into statuses which are configured as being considered as closed when a 'blocked by' relation is active for an issue which doesn't have a status which isn't closed (yet). This will cover your examples as far as I can see... ;)

Regarding "This request has a broader scope though, and calls for harder "dependencies", i.e. (...)": I do not agree. Due to the fact that this issue has been opened almost 3 years ago the conclusion should be that it's scope was based on the Redmine functional-state 3 years ago (which didn't include the feature of actually blocking issues from being set to a closed status when a 'blocked by' relation exists).
With the implementation of #1740 and the opening of #2448 for the additional, related "(Graphviz) dependency graph of related issues"-feature which came up in the comments, this issue is resolved. Therefor I'll close it.
When more advanced feature-requests come-up I presume it's better to open new issues for it instead of keeping this issue open any longer becoming more cluttered over time...

edit by Mischa The Evil on 2010-01-21 00:29

 
Kind regards,

Mischa.

Actions #21

Updated by Mischa The Evil about 14 years ago

  • Status changed from New to Closed
  • Resolution set to Fixed

As proposed in my previous comment on this issue.

Actions #22

Updated by Mischa The Evil about 14 years ago

Hugo Ferreira wrote:

David Leuschner wrote:

Redmine seems great, but as long as this feature is missing, (...)

I suspect its this issue log that is long due of an update, rather than the functionality being missing. I've just been evaluating Redmine version 0.9.0 and this works flawlessly:

[...]

Furthermore, the follows/precedes relationship will also touch the start/due dates according to the delay set.

Thanks for this info. I'll try to "port" this 'documentation' clearly to the Redmine Guide.

Actions #23

Updated by Felix Schäfer about 14 years ago

Mischa The Evil wrote:

Felix, please note r2800 which resolved issue #1740. This enhancement is included in Redmine 0.9.0 and makes it possible to actually prevent issues from being set into statuses which are configured as being considered as closed when a 'blocked by' relation is active for an issue which doesn't have a status which isn't closed (yet). This will cover your examples as far as I can see... ;)

Oh, there you go, I try to keep up-to-date on the revisions, but that one seems to have crept under my radar :-) Anyway, I knew about the end-date/start-date tie-up feature of the follows relationship, but not the close-blocking effect of the blocks relationship.

Long story short: the whole request is still not addressed, but I agree with you it's better to keep the more specific tickets open than this one.

Actions #24

Updated by Howard Mall over 13 years ago

  • Status changed from Closed to Reopened
  • Assignee set to Jean-Philippe Lang

Perhaps it is user error, but in the latest stable release (0.9.5) 'precedes' and 'follows' relationships no longer effect 'Start' and 'Due date's for issues. For example if I change the 'Due date' for 'Task 1.1' which 'precedes' 'Task 1.2', the 'Start' for Task 1.2 should shift accordingly. It no longer does this.

I checked it against the latest git clone this morning and this functional logic does not appear to work either.

I checked out the 0.9.0 release and those dependencies work as advertised.

Perhaps this is related to the sub-issue logic?

Redmine is proving very useful and we are eagerly awaiting the 1.0.0 release candidate on July 3, 2010. I'm hoping this defect can be resolved before that release, because it is a really superb feature in 0.9.0.

Actions #25

Updated by Felix Schäfer over 13 years ago

  • Status changed from Reopened to Closed

I can confirm this on r3813, but that needs to get in a new ticket. Howard, could you please open a new bug describing the regression? Thanks.

Actions

Also available in: Atom PDF