Redmine

Why don't you add project2 amd project 1 below parent project and manage issue in parent. The it shall work out of the if version sharing is activated box. YOu could also add project 1 below project 2 or try to enable version sharing across als projects. Just an idea.

Terence Mill wrote:

Why don't you add project2 amd project 1 below parent project and manage issue in parent.

They both have the same parent, but issues are dispatched between projects to be managed by project teams.

The it shall work out of the if version sharing is activated box. YOu could also add project 1 below project 2 or try to enable version sharing across als projects. Just an idea.

Thanks, I'll look at version sharing if it can solve our issue (which is triggered quite often unfortunately).

Ok, assigning a shared version (across all projects) is not the solution for the test case I described.

After step 5, 6 and 7, the issue is not marked as closed.

Regards.

I found a reference not really similar #8291.

Regards.

The cross-project issue handling could be a good thing with multiple fixes, if one commit fix 2 or more issues.

Regards.

It already works cross-project. See r3357 for issue #4674, which was included first in Redmine 0.9.2.

Mischa The Evil wrote:

It already works cross-project. See r3357 for issue #4674, which was included first in Redmine 0.9.2.

It works genealogically, between a parent and a child.

But not between "brothers", nor "cousins".

Regards.

I am also experiencing problems with this issue.
We have a main project for our framework. This framework has multiple sub projects.
We have a main project with multiple sub projects.
These sub projects use a few modules from our framework,

When issues are added in the main projects sometimes they are partially fixed with modifications to the framework and closed with another fix in the project or the other way round. They basically are cross project.

Now we open a second issue in the framework linked to the first issue where the framework team (me) can handle the changes reference commits and add info for future references.

In the future we want to keep the framework accessible only to our core team... but we'd like to be able to close for example 5 or 6 issues at the same time if they have been reported in 4 sub projects for example. Each subproject being managed by a different person/team we won't necessarily want to peek into the framework or across projects (NDAs and other constraints).

The ideal would be to be able to reference issues from other projects in our commits and display this reference even if the link to this commit leads to a denied access. At least we would have a good way to follow all commits that have contributed to one issue even from other teams.