Redmine

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

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.

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

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

Hi Jean!

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

thanks.

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.

+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.

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.

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.

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.

• 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.

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

+1

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

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.

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.

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

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.

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.

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.

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.

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.