Feature #5497
open
Assigning issues to projects
0%
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
- 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
- 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.
Updated by Felix Schäfer over 14 years ago
Wouldn't the related issues (blocks and follows relationships) allow that?
Updated by Pedro Gutierrez over 14 years ago
Felix Schäfer wrote:
Wouldn't the related issues (blocks and follows relationships) allow that?
In fact, we find the duplicates relationship more helpful because it allows reflecting the state of a request.
But, regardless of the relationship used, we are always obliged to create two different issues to emulate this. One for the requested issue itself, another for the image of the request that remains in the client project.
However, I believe a single instance of the issue should be enough. The only challenge being how to reflect two views of this single instance in two projects (the client and the server)