+1 for me

The subtask feature is very important in a project that involve sub project and the cross project subtask is often required.
--------------------------------------------------------------------------------
+1 from me too
--------------------------------------------------------------------------------
+1 Yes very important: it allows us to make work together dev project and functionnal sub-project
This is critical.
--------------------------------------------------------------------------------
I can't find the concerned code: where should we look for it?
--------------------------------------------------------------------------------
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?
--------------------------------------------------------------------------------
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.)
--------------------------------------------------------------------------------
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?
--------------------------------------------------------------------------------
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...).
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
+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:
# Do we allow one (sub)task to have parent in other projects?
# Or do we allow one (parent) task to have children in other projects?
# 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:
# Do we allow the manager to determine which projects B could receive children subtasks from project A parent task?
# 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.
--------------------------------------------------------------------------------
+1 Allowing a parent task to at least create sub-tasks in sub-projects would be extremely valuable.
--------------------------------------------------------------------------------
+ 1 for me too
--------------------------------------------------------------------------------
+1

This is critical for us.
--------------------------------------------------------------------------------
+1
This is very important for us too!
--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
+1
This is a very important feature!
--------------------------------------------------------------------------------
Agree. This is a very important feature!
--------------------------------------------------------------------------------
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#Subtasks]] to clear this point, which is very poor actually.
--------------------------------------------------------------------------------
+1 for us too.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
+1 here! Very important for us to be able to use sub-projects effectively.
--------------------------------------------------------------------------------
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!

<pre>

# 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

</pre>
--------------------------------------------------------------------------------
oops should have mentioned where this code lives,

<pre>
app\models\issue.rb

</pre>

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!
>
> [...]

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Yippiee!

> Target version set to Candidate for next major release
--------------------------------------------------------------------------------
Yeah! Etienne, thank you! There's another feature you should take a look, cause is related: #5275
--------------------------------------------------------------------------------
+1 very important feature
--------------------------------------------------------------------------------
+1! It would be good for me too!
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
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.

--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1

This would make the subtickets feature become more useful.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
Critical for us.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
-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.

--------------------------------------------------------------------------------
+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
--------------------------------------------------------------------------------
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" :)
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
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").

--------------------------------------------------------------------------------
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").

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

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

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

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

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

--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1 this is a solid requirement for us, rather than a luxury feature requested by spoiled users :)
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
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?

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

--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1

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

--------------------------------------------------------------------------------
In our company that's also by far the most missed feature. Thanks for your great work!
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
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,
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
+1
great feture that we use a lot, but it would be perfect if we could also see the subtasks in crossprojects inside the Gantt view (currently the Gantt view only enables to see the tasks which are part of a given project. If the sub tasks are in an other project, we must go in this pariticular project to see it) seems that this functionality has also been requested here : #13141
--------------------------------------------------------------------------------

relates,Closed,5473,adding parent when cross project
relates,New,6920,Allow subtasks to be affected to a different target version
relates,New,8376,Moving issue to different project silently clears parent
duplicates,Closed,5975,Cross-project Parent Tasks
duplicates,Closed,7847,Cross-project subtasks
duplicates,Closed,6798,allow subtasks in subprojects
duplicates,Closed,9247,Allow parent task to be in parent (or other) project
duplicates,Closed,11463,Sub issues can not have parent outside a project
duplicates,Closed,11639,Inter-project issues parent-ship