Feature #5487

Allow subtasks to cross projects

Added by Burt Culver over 4 years ago. Updated about 2 years ago.

Status:ClosedStart date:2010-05-09
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:Issues
Target version:2.2.0
Resolution:Fixed

Description

We use subtasks and would like to have subtasks that belong to other projects. For example, we have two projects admin and software and sometimes there are subtasks of software projects that need to be done in the admin project. A patch in #5473 seems to accomplish this.


Related issues

Related to Defect #5473: adding parent when cross project Closed 2010-05-08
Related to Feature #6920: Allow subtasks to be affected to a different target version New 2010-11-17
Related to Defect #8376: Moving issue to different project clears parent New 2011-05-15
Duplicated by Feature #5975: Cross-project Parent Tasks Closed 2010-07-27
Duplicated by Feature #7847: Cross-project subtasks Closed 2011-03-12
Duplicated by Feature #6798: allow subtasks in subprojects Closed 2010-11-02
Duplicated by Feature #9247: Allow parent task to be in parent (or other) project Closed 2011-09-14
Duplicated by Defect #11463: Sub issues can not have parent outside a project Closed
Duplicated by Feature #11639: Inter-project issues parent-ship Closed

Associated revisions

Revision 10587
Added by Jean-Philippe Lang about 2 years ago

Adds a setting to allow subtasks to belong to other projects (#5487).

Revision 10588
Added by Jean-Philippe Lang about 2 years ago

Filling locales (#5487).

Revision 10589
Added by Jean-Philippe Lang about 2 years ago

Filling locales (#5487).

History

#1 Updated by Paolo p over 4 years ago

+1 for me

The subtask feature is very important in a project that involve sub project and the cross project subtask is often required.

#2 Updated by Nigel Jones over 4 years ago

+1 from me too

#3 Updated by Alexandre Israël over 4 years ago

+1 Yes very important: it allows us to make work together dev project and functionnal sub-project
This is critical.

#4 Updated by Alexandre Israël over 4 years ago

I can't find the concerned code: where should we look for it?

#5 Updated by Felix Schäfer over 4 years ago

  • Assignee set to Eric Davis

I'd like to hear Eric's opinion on this: What would you think in light of JPL's comment in #5473? I'm not sure how doable this is when all the other stuff concerned is taken into account, e.g. how would you represent cross-project subissues in a project's GANTT chart?

#6 Updated by Eric Davis over 4 years ago

  • Assignee changed from Eric Davis to Felix Schäfer

I think it would be fine to have subtasks cross projects. Issue and Project visibility would have to be taken into account but we are already doing a lot of that. My original patch for subtasks supported cross project subtasks and it would "hide" the issue name name if the user couldn't view the subtask.

Felix, I'm not sure how the Gantt would change though. Can you explain what you're thinking there?

(I still have that private rewrite of the Gantt chart. If I recall, it shows subtasks that are visible to the current user underneath each Project/Version/Parent Task.)

#7 Updated by Alexandre Israël over 4 years ago

Yes this was the behaviour we had with the subtasks module.
At access level, there is with no difference to take between Issues views and Gantt views. Permission should act the same way.
From my point of view Issues relations is the best comparison with subtasks permission behaviour.

I called it "critical" because I could not update anymore issues having cross project subtasks in the database: I decided to backup my DB and erase parent_id column values - because I needed to keep working on my project but it is really frustrating.

Why one decided not to allow cross project subtasks? It is just "well, we didn't think of it as interesting" or is it for design / security reasons?

#8 Updated by Felix Schäfer over 4 years ago

Alexandre Israël wrote:

Why one decided not to allow cross project subtasks? It is just "well, we didn't think of it as interesting" or is it for design / security reasons?

I think it's more a different philosophy of subtasks, i.e. "subtasks can only exist in the same project" vs "subtasks is more loose multi-project relation".

I think we could have a setting like for cross-project issue relations I think (or even just use the same setting...).

#9 Updated by Felix Schäfer over 4 years ago

  • Assignee changed from Felix Schäfer to Eric Davis

Eric Davis wrote:

Felix, I'm not sure how the Gantt would change though. Can you explain what you're thinking there?

Well, you could have holes in your issues hierarchy, which would be hard to "show" in a GANTT chart, or any other representation for that matter. It might also be hard to grasp that some attributes of a parent issue are directly dependent on the attributes of subissues, some of which you might not be able to see.

Anyway, if you think that just having "holes" because of some parts of the issue tree you can't see, it's fine with me, though having the option to turn cross-projectness on or off like for related issues would still be a good thing.

#10 Updated by Alexandre Israël over 4 years ago

+1

What Eric describe depends on how you use it: you might have pertinent use - and stupid ones which does not fit.

Project based activation should make a choice on parent side or child side:
  1. Do we allow one (sub)task to have parent in other projects?
  2. Or do we allow one (parent) task to have children in other projects?
  3. Having bi-directional choices could make inconsistent situations :-(
On the other hand, let's say we chose (parent) tasks to have children in other projects:
  1. Do we allow the manager to determine which projects B could receive children subtasks from project A parent task?
  2. Or is it going to be an open world permission?

From my point of view: 2-1 is the best couple.

What do you think?
Thanks by advance for your time spent on this issue.

#11 Updated by Spiro R about 4 years ago

+1 Allowing a parent task to at least create sub-tasks in sub-projects would be extremely valuable.

#12 Updated by Stefan Schneider about 4 years ago

+ 1 for me too

#13 Updated by Eric Davis about 4 years ago

  • Assignee deleted (Eric Davis)

#14 Updated by Fardeen GHULAM about 4 years ago

+1

This is critical for us.

#15 Updated by Grégory Janiszewski about 4 years ago

+1
This is very important for us too!

#16 Updated by Kirill Vasiliev about 4 years ago

+1 for us all here. It is very important for PM to distribute the work between different departments when each department has its own subproject.

#17 Updated by Mario Šarić almost 4 years ago

+1
This is very useful (and needed) feature for environments with several projects that are related to each other and when teams should be coordinated. Please consider putting this feature on the Redmine roadmap.

#18 Updated by Daniel Morgan almost 4 years ago

+1
This is a very important feature!

#19 Updated by Beni Chan almost 4 years ago

Agree. This is a very important feature!

#20 Updated by Etienne Massip almost 4 years ago

I'm still not sure I understand the subtasking feature implemented in redMine.

What is a subtask used for , how is subtasking used actually, what are the concepts behind this implementation, is the task hierarchy tied to a project or a version (should subtasks belong to the project/version of their parent or could they be shared among subprojects), etc. ?

There should be a great documentation effort about subtasking feature in RedmineIssues to clear this point, which is very poor actually.

#21 Updated by Juan Antonio Campano almost 4 years ago

+1 for us too.

#22 Updated by Deon Joubert almost 4 years ago

I want to add our voice to this Issue too. We just started using Redmine. While setting up I was thinking this and that feature would be nice and inevitably found those features. But this one with cross-project sub-tasks seems to be a bit glaring in its absence.

#23 Updated by Eran Carmel almost 4 years ago

Very important for us too. We have a product tree that is the main features that resides in one project and all other projects have sub features that link to it. This is blocking us from using the product as we would want to.

#24 Updated by Cyle Witruk over 3 years ago

+1 here! Very important for us to be able to use sub-projects effectively.

#25 Updated by David Chiew over 3 years ago

Hey Guys,

I just commented out the line which was creating this error - below it's marked with DC (my initials), and it seems to resolve the issue. All subtasks, can see the parent, and all parent tasks can see their subtasks correctly, even though they're in different projects.

I'm not sure the ramifications of doing this, but I'm going to run with this "hack" for the moment and it's solving this problem perfectly!


# Checks parent issue assignment
    if @parent_issue
      if @parent_issue.project_id != project_id
#DC: disabled to see whether cross project subtasks are possible
#        errors.add :parent_issue_id, :not_same_project
      elsif !new_record?
        # moving an existing issue
        if @parent_issue.root_id != root_id
          # we can always move to another tree
        elsif move_possible?(@parent_issue)
          # move accepted inside tree
        else
          errors.add :parent_issue_id, :not_a_valid_parent
        end
      end
    end
  end

#26 Updated by David Chiew over 3 years ago

oops should have mentioned where this code lives,

app\models\issue.rb

David Chiew wrote:

Hey Guys,

I just commented out the line which was creating this error - below it's marked with DC (my initials), and it seems to resolve the issue. All subtasks, can see the parent, and all parent tasks can see their subtasks correctly, even though they're in different projects.

I'm not sure the ramifications of doing this, but I'm going to run with this "hack" for the moment and it's solving this problem perfectly!

[...]

#27 Updated by Etienne Massip over 3 years ago

  • Target version set to Candidate for next major release

#28 Updated by Deon Joubert over 3 years ago

Yippiee!

Target version set to Candidate for next major release

#29 Updated by Rodrigo Carvalho over 3 years ago

Yeah! Etienne, thank you! There's another feature you should take a look, cause is related: #5275

#30 Updated by Loïc Gadras over 3 years ago

+1 very important feature

#31 Updated by Cassiano Monteiro over 3 years ago

+1! It would be good for me too!

#32 Updated by Filip Procházka over 3 years ago

Hi guys, i've made a few changes (which are not optimized at all, i could've barely made it work) to allow this kind of relation.

Changes are here: https://github.com/HosipLan/redmine/commits/working

- I've removed check for project on issues, so issue can be moved or have parent issue from every project, which accesible for current user.
- I've added field Project to "new issue" form and it magicaly allows you to choose project, to place issue to.

So when you open an isssue, you click on "add subtask", you can choose project to add child issue to, and they will maintain the relation. It works just fine for me. I could make it a pull request on github, if you would want me to.

Filip

#33 Updated by Alexandre Israël over 3 years ago

Hi Filip,

What happen if I move the subtask from one project to another?
Is the project value recorded (and need sync...) or is it just a convenient dropdown?

Thanks,

Alexandre

#34 Updated by Filip Procházka over 3 years ago

Well, as you can see in the commits, i've made it to preserve the connection to parent. You can tell from this screenshot http://i55.tinypic.com/fa0oc2.jpg, subtasks does still affect the parent even from different project.

I've also made few view changes, to made it more compact. But that's not important.

This is the same task http://i52.tinypic.com/18j5w1.jpg from the perspective of customer. I use this change to have two projects, one parent "official" for customer, and one internal, for programmers communication. When i recieve a request, i just create subtask in (internal) subproject. So it's connected and customer can't see the internal communication, the technical stuff.

When you're moving issue to another project, it holds the information about parent.

System still won't allow you to mess up your issue, when moving, it checks if conrete workflow exists and can be preserved and other security stuff.

#35 Updated by Fede Garcia over 3 years ago

+1

#36 Updated by Robert Schneider over 3 years ago

+1

This would make the subtickets feature become more useful.

#37 Updated by Anonymous over 3 years ago

+1

#38 Updated by Luc Luc over 3 years ago

+1
Critical for us.

#39 Updated by Raul Fortes over 3 years ago

+1

#40 Updated by Terence Mill over 3 years ago

-1 for that issue, except it can be turned off.

I am still not undertstanding why roles like admin or developer (software?) should have their own projects, like the examples describes.
For us a project has its own manager, budget and resource planning.
Tasks in a project that are under control of another poject manager, who can change priority and shift ressources - is unmanagble and at high risk.
The example given should be done with categories or dependencies of issues should done via "Related Issues" feature. This way e.g a feature can be blocked by a task of another project and that is already possible, isn't it?
The subtask feature was done to make it possible to do a more fine grained segmentation of an issue in means of the issue itself in the same project. Only then fields like estimation, spent time nad %done can be correctly and clearly assingned to one parent.

#41 Updated by Luc Luc over 3 years ago

+1 again (this one and multiple SCM repos per project are the only missing features which stops us from using Redmine).

I will try to explain why (by replying to Terrence).

Hi Terence, from your first phrase I can see you didn't clearly understand the true reason for this request. This has nothing to do with roles, it is about projects and how the tasks from one child project relates to its parent project. Let me give try to give you a good example (this is exactly our case, I only use generic names).

We have a project FooBar which is a complex product and has the following sub-projects: ServerSoftware, BrowserBasedSoftware and EmbeddedSoftware. Also EmbeddedSofware has the following sub-projects: BootLoader, Kernel and Apps (these were mainly needed because Redmine can't handle multiple repos per project, but in the end we found this model may work for us anyway). These sub-projects are quite distinct in their nature (from the coding point of view) but in the end they make a single big product (e.g.: version V of FooBar = version X from ServerSoftware + version Y from BrowserBasedSoftware + version Z from EmbededdedSoftware) and there is a top project manager that has to manage FooBar as a whole (also there are separate project managers for each of the 3 first level projects). Top manager is interested in tasks at the FooBar level, while other 'per-sub-project' managers are interested in tasks only at their level or below.

Two examples where sub-project sub-tasks are needed:

- A new feature is required for the whole FooBar project, this is a generic - functional based - task in FooBar project, which will spawn multiple sub-tasks in corresponding sub-projects where specific work has to be done. The new FooBar feature is finished when all its sub-tasks from the sub-projects are finished. Don't forget each project manager wants to see a nice Gantt chart with only what he is involved in.

- A client files a bug in EmbeddedSoftware project (e.g: 'Battery status not displayed incorrectly'). The client doesn't know details about how our EmbeddedSoftware is split into sub-projects (and he doesn't need to know). He doesn't know if the battery status is not correct because the Apps project code has a bug in displaying the status received from the kernel module, or maybe the kernel module itself is reporting bad data, or maybe both. So this bug may spawn two (or more) sub-tasks, e.g.: one in Kernel sub-project and one in Apps sub-project. The task (bug reported by client) from EmbeddedSoftware project is completed when its corresponding sub-tasks are completed. Don't forget on Kernel project is working one team and on the Apps project is working another team.

:)

Well, that's it, I'm sorry for such a long post, but I hope I made it clear why such a feature is very important for most of us.
And yes, I think such a feature can be turned off very easily :) by just don't using it (or maybe you're asking for an option for specifically not allowing users to make such sub-tasks / sub-projects relations, I think this can be done too).

Thanks,
Luc

#42 Updated by Filip Procházka over 3 years ago

Hi Luc, i'm currently wery bussy, so i will rebase my changes and create pull request only when someone entrusting will ask me for it, because it's not optimised. Ruby isn't my native language :)

Anyway, it's realy simple to make this work, just by integrating my commits https://github.com/HosipLan/redmine/commits/working. I believe that anyone with basic knowledge of programming languages & git will manage to integrate them, for testing.

I've used already existing rule, that can be turned on/off in administration for allowing to wire tasks throught projects. Now the same rule allows subtasks in different projects. So there is no "don't use it when you don't need it", there is only "when you don't need it, turn it off" :)

#43 Updated by Luc Luc over 3 years ago

Thanks Filip,

Time is my only enemy too :) but I will try to find some time to test your changes and I will give you some feedback.

#44 Updated by Radek Karban over 3 years ago

+1

#45 Updated by Artem Garashko over 3 years ago

+1

#46 Updated by Stéphane David over 3 years ago

I would also like to see this implemented. Here is a real case example:
We have two products P1 and P2, each with a dedicated team and a product manager.
We have a new customer, C, so a new project, with a project manager.
For this new project, we need to develop a new module for each product (M1 and M2).

I'd like to be able to create this as a sub project of P1 and P2. So the product maanger can see at a glance, for their product, what they have to do, including the M1 and M2.

Then, I'd lilke to be able to create a logical link between M1 and M2 and project C. So that the project manager of C can see, at a glance, what is related to his project (including M1 and M2).

How to configure:
- In a project settings, add an option "link to", where you can add new projects. (hre : go to C, add M1 and M2 as "virtual subproject"

How to use :
- When going to P1 project, you can see M1 as sub project (normal, M1 is a real subproject)
- When goign to C project, you can also see M1 (as as "virtual subproject").

#47 Updated by Pedro Gutierrez over 3 years ago

Stéphane, I like what you propose: i.e. that a project can view other projects as if they were its subprojects (if I understood correctly)

In fact, I'd like the same for issues. I'd like a configuration where issues apart from belonging to one project could be viewed from other projects.

Because as you state in your example, projects in some organisations are tightly interrelated in a network fashion. While, at the moment, Redmine only allows a hierarchical tree-like interrelation.

Stéphane David wrote:

I would also like to see this implemented. Here is a real case example:
We have two products P1 and P2, each with a dedicated team and a product manager.
We have a new customer, C, so a new project, with a project manager.
For this new project, we need to develop a new module for each product (M1 and M2).

I'd like to be able to create this as a sub project of P1 and P2. So the product maanger can see at a glance, for their product, what they have to do, including the M1 and M2.

Then, I'd lilke to be able to create a logical link between M1 and M2 and project C. So that the project manager of C can see, at a glance, what is related to his project (including M1 and M2).

How to configure:
- In a project settings, add an option "link to", where you can add new projects. (hre : go to C, add M1 and M2 as "virtual subproject"

How to use :
- When going to P1 project, you can see M1 as sub project (normal, M1 is a real subproject)
- When goign to C project, you can also see M1 (as as "virtual subproject").

#48 Updated by Stéphane David over 3 years ago

Yes, you understand correctly, I'd like a project to view other projects as if they were subprojects.
About your issue suggestion. If the issue belongs to a project which is linked to another as I propose, could it be sufficient? If issue belongs to project B, project B is linked to project A, then when you go to project A, you see B as subproject, and therefore see the issues of B?

Pedro Gutierrez wrote:

Stéphane, I like what you propose: i.e. that a project can view other projects as if they were its subprojects (if I understood correctly)

In fact, I'd like the same for issues. I'd like a configuration where issues apart from belonging to one project could be viewed from other projects.

#49 Updated by Pedro Gutierrez over 3 years ago

Linking isues among them with the current set of dependencies is not enough for us.

We'd need a way to implement a request between 2 projects (we have lots of these) so that:
  • Project A can request something to project B
  • The request is one single issue that:
    • is part of project A who has submitted it
    • is part of project B who is working on it
  • Project B works on the request and updates the progress periodically
  • Project A can watch its portfolio of requests to other projects and see their progress
  • Project B closes the request
  • Project A is notified that the request has been closed

But probably this is completely out of scope of this issue ¿or not? In the end this are issues that cross projects

#50 Updated by Ruedi Silvestri over 3 years ago

+1 also in our environment it is essential to have such capability.

There is multiple projects affecting multiple platforms. The preffered way is to assign to each such platform a dedicated subproject. Reson here is that on the different platforms we different vendors involved having access to Redmine, while we don't want to disclose issues to vendors which are not in their context.

#51 Updated by Oskar Nordquist about 3 years ago

+1

#52 Updated by Sergey Petrov about 3 years ago

+1

#53 Updated by Patrick Dubois about 3 years ago

+1. That would help us a lot. Currently the next best thing is to link all subtasks as "related" issues but it's not as nice.

#54 Updated by Mischa The Evil about 3 years ago

I came around a patched solution for this issue in the Finnlabs ChiliProject repos. The patch (commit) is authored by Felix Schäfer and currently looks compatible with Redmine trunk: https://github.com/finnlabs/chiliproject/commit/a7a79cd099bca59d53796f9b7734413c8034ad2b

I've tested this change quickly and found that it works with Redmine besides two caveats I noticed:
  • Sorting by parent task won't show the (cross-project) subtask indention on the issue-lists.
  • (Cross-project) subtasks won't have the subtasks' project prepended in the repective views (like currently done for e.g. issue-relations).

#55 Updated by Felix Schäfer about 3 years ago

Mischa The Evil wrote:

I came around a patched solution for this issue in the Finnlabs ChiliProject repos. The patch (commit) is authored by Felix Schäfer and currently looks compatible with Redmine trunk: https://github.com/finnlabs/chiliproject/commit/a7a79cd099bca59d53796f9b7734413c8034ad2b

I've tested this change quickly and found that it works with Redmine besides two caveats I noticed:
  • Sorting by parent task won't show the (cross-project) subtask indention on the issue-lists.

Yes, and there's no easy fix for that, fixing that would either mean reworking the DB query to include more stuff and not showing parts of the query or doing additional queries for some/all elements potentially resulting in many more queries.

  • (Cross-project) subtasks won't have the subtasks' project prepended in the repective views (like currently done for e.g. issue-relations).

Nope.

More caveats: if you input ID of a ticket you don't have the permission to see in the parent issue field, it will silently be ignored.

In other words: it works, but is a hot fix rather than a proper solution (one of the reasons why it hasn't been proposed either here or on chiliproject).

#56 Updated by Mischa The Evil about 3 years ago

Felix,

At first: thanks for replying here so fast after my post...

Felix Schäfer wrote:

More caveats: if you input ID of a ticket you don't have the permission to see in the parent issue field, it will silently be ignored.

Thanks for mentioning this third one. I hadn't figured that one out yet (also due to the i18n-changes that are included in the commit).

Felix Schäfer wrote:

In other words: it works, but is a hot fix rather than a proper solution (one of the reasons why it hasn't been proposed either here or on chiliproject).

I got it, thanks for clarifying it. Though mentioning the hotfix on this issue might be interesting for the other watchers of this issue who might be in huge need for this feature and who would accept the mentioned issues of the patch in their environment. Plus, it might even trigger another developer to fix the outstanding caveats working towards an acceptable patch, which might even will make its way into the core one day.

Disclaimer: This feature itself is not something I'd want to have integrated myself. Personally, I think that within the scope of the current subtasking implementation it is best not to complicate the feature even more. Instead the focus should be more on finishing the subtasking feature itself. If I remember it correctly Eric has plans for such within ChiliProject (though can't find any issue for such at the moment).

#57 Updated by Lucy Yevseyeva almost 3 years ago

+1

#58 Updated by Sim Zacks almost 3 years ago

+1
My use case:
I define each form in my application as a subproject.
Some features touch multiple forms, so an issue might be defined as build a new form for feature X and a subtask is add functionality to a different form to support the new stuff.

#59 Updated by Gokay Gok almost 3 years ago

+1

#60 Updated by Ariel Falduto almost 3 years ago

+1

#61 Updated by Engin AYDOĞAN almost 3 years ago

+1 this is a solid requirement for us, rather than a luxury feature requested by spoiled users :)

#62 Updated by Stéphane Thomas over 2 years ago

+1

#63 Updated by Andreas Grassl over 2 years ago

+1

#64 Updated by Thomas Kolbabek over 2 years ago

+1

#65 Updated by Maher Gamal over 2 years ago

+1

#66 Updated by Ladislav Nesnera over 2 years ago

+1

#67 Updated by Matt H over 2 years ago

Mischa The Evil wrote:

Instead the focus should be more on finishing the subtasking feature itself.

What needs to be finished in the subtasking feature, and could this be added to that work?

#68 Updated by VD DV over 2 years ago

+++1
This feature should open whole new bunch of possible uses of redmine in complex projects (projects that involves interaction with other independent projects). Looking forward for this feature.

#69 Updated by Michael Tuschik over 2 years ago

+1

#70 Updated by Jean Spector over 2 years ago

+1

#72 Updated by K. Scott Tripp over 2 years ago

+1

This would be hugely beneficial, especially when requirements of one project drive the time line of another project.

#73 Updated by Edcleyson Santana over 2 years ago

+1

#74 Updated by Jean-Philippe Lang over 2 years ago

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

#75 Updated by Dietmar H over 2 years ago

In our company that's also by far the most missed feature. Thanks for your great work!

#76 Updated by Andrey V about 2 years ago

We have one Problem with using subtask.

When we create a subtask,
it changes the date of the parent task (Due date),
even if the date of subtask is less than the deadline parent task.

More correctly, change the date of the parent task only if the date subtask is more.

Please consider, correct this behavior.

#77 Updated by Ling Chang about 2 years ago

+1

#78 Updated by Eric Voisard about 2 years ago

Would be nice but please, kill two birds with one stone: fix defect #5490 "subtask priority/start date/due date" at the same time.

Thanks for your work,

#79 Updated by Jean-Philippe Lang about 2 years ago

  • Status changed from New to Closed
  • Assignee set to Jean-Philippe Lang
  • Resolution set to Fixed

Implemented with a configurable scope: subtasks can be allowed in any projects, inside the project tree (all projects under a root project) or in subprojects only. And it can be turned off for those who don't want subtasks in a different project.

Also available in: Atom PDF