Project

General

Profile

Actions

Feature #5497

open

Assigning issues to projects

Added by Pedro Gutierrez over 14 years ago. Updated over 14 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Roadmap
Target version:
-
Start date:
2010-05-11
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

We started to use Redmine in January, have 15 projects inside and planning to have around 70 by the end of the summer. Our impression is that Redmine is great or ... even more.

We believe it might be of interest to allow a project to assign issues to another project. In the end, if most of the activity of our organisation is starting to be handled by Redmine, we need a clear interface for projects to interact.

In other words, we have "client" projects within our organisation than can request work to be "served" by other projects. At the moment we do this simply by creating issues directly in the server project. However, this prevents the client project from tracking the request easily in its own roadmap.

Typical examples of this situation. When project A is building a piece of software that runs on top of another software that is responsibility of, let's say project B:
  • It is frecuent that project A finds bugs that project B has to fix and that affect the progress of project A.
  • It is common that project A needs certain feature to be developed in project B and this affect the progress of project A. Because it is a prerequesite for certain project A's feature
If it were possible to assign issues from client project A to server project B:
  • It wouldn't be necessary that project A created an "image" issue to reflect the progress of these issues in the roadmap and Gantt chart.
  • It wouldn't be necessary for project A to permanently have to update image issues' progress to sync with the progress of issues assigned to project B
  • Server projects could filter their incoming issues by client project
I imagine that this feature affects the database model significantly but I also belive that the resulting model is much more powerful:
  • Now, an issue is created by a person and assigned to a person in the context of a project
  • If the feature is implemented, an issue is created by a person from project A and assigned to a person from project B

Regarding the roadmap and the Gantt chart, in this new situation both should reflect not issues assigned to them (as it is now) but issues originated by them (either assigned to themshelves or to other projects).

WRT the current possibility of moving issues from one project to the other. It doesn't cover the situation I'm painting here. Because it is only for issues that are in project A, but A realises these are not its responsability any more and so, should be moved somewhere else, and shouldn't appear, from that moment on, neither in the roadmap nor in the Gantt of project A.

Sorry for the long text. And thanks for the great product you all are creating.

Actions

Also available in: Atom PDF