Redmine

+1

We are having the same issue.

Regards,
Mohan.

Isn't this the same as issue #2255 , and possibly implemented by the patch in #2256?

Note - you will need to have the repository module enabled in the master project (even if it doesn't have a repository) to get the associated revisions details in the issue

The patch to the file app/views/issues/_changesets.rhtml should be accepted no matter what, after all, the db schema allows for linking repository changesets across projects.

I am testing the changes to app/models/changeset.rb .

This sounds amazingly promising. I will keep you up to date.

Zarooba Rozruba wrote:

Jean-Philippe Lang committed part of the fix through ticket #3376

I've applied the attached patch and amended line no.83 in changeset.rb so that any revisions that contain issue IDs for sibling projects are also properly linked in those projects. This has been working great for us for a while now. The recent commit above also fixes the case where tickets are moved between projects and ensure the revision association is always correct.

project_list = [repository.project.self_and_siblings] + repository.project.ancestors

The use case for us was simple, we have a master project with 10 sub projects and some issues are fixed that affect say 3 projects in one go so are committed together in one revision. In this case it would be useful to retain the revision association for all issues across these projects (they all have have the same root repository path anyway)

To get this patch committed into trunk, would it be sensible to add some config options per project under the repository module that can define the expected behaviour of this? i.e. Revisions committed against this project that reference tickets in [self],[self + siblings], [self + all ancestors, self and parent] are allowed?

As a setup note, for any parent/ancestor projects, make sure you have enable the repository module to allow revision linking to work correctly across projects (you do not have to configure it)

This is awesome, but I took it further with a simple change..

The ability to associate issues from ancestor projects is a start, but I found it still way too limiting. We have different repositories by the type of stuff (database objects vs. visual studio projects, requirements documents, etc.) Issues need to be associated with all of those.. So why limit it at all?

    #project_list = [repository.project] + repository.project.ancestors
    project_list = Project.find(:all)

This allows any change in any repository to be associated with any issue. If the user doesn't have access to the other repository, they get an error message.. perfect. Furthermore, you can create dummy projects just to hold repositories and now you can have as many repositories as you want..

I have this running in redmine 0.8.4 as well as a recent trunk, and it's working great!

My experience with ruby is extremely limited, so if there's a better syntax or something, please let me know.

--Bill

+1

It is real need.

+1

+1

make it +1 from me too..

forgot to mention an important thing if it can be considered, our requirement is not strictly a parent-child requirement, so we have kept project all at top level. But would still like to have a cross project issue-revision relation.

I need this too. We have different subprojects created for different modules and there is a user acceptance testing subproject. The commits in the module-specific subproject is not linked to an issue in user acceptance testing subproject. I usually hold myself back from applying patches. Hope to get this issue resolved in the trunk sometime soon.

+1 here. It could be controlled by the existing admin setting to allow cross project issue linkage. If you need that, chances are more than well that you'd require this patch here as well. Would be great to see such a change in the trunk.

+1 to William Baum's comment 17. Would be good if issues were related to any project in redmine, not just parent/child projects.

Felix Schäfer wrote:

As far as I can tell, something similar (or that exactly) exists in currrent trunk, probably 0.9-stable too, closing this issue.

I tested in 1.2.0, using commit messages, you can indeed create references to issues in ancestor or descendant project. However the ancestor or descendant project must have repository configured.
I don't see the reason for it to be this way.

In my organization, we have a project with a repository for the product development and sub-projects for customers implementations (With Gantt for deployment planning and specific issues). We are not able yet to link revisions to customers issues.

+1

+1 please!

My apologies, I intended to update this months ago..

In app/models/changeset.rb you'll find:

  def find_referenced_issue_by_id(id)
    return nil if id.blank?
    issue = Issue.find_by_id(id.to_i, :include => :project)
    if issue
      unless issue.project &&
                (project == issue.project || project.is_ancestor_of?(issue.project) ||
                 project.is_descendant_of?(issue.project))
        issue = nil
      end
    end
    issue
  end

It's that unless business that's preventing the links unless the projects are related.

Just comment out that whole if block or the change the unless to:

unless project == project

This will enable changesets in any repository to reference issues in any project.

+1, should be in trunk, commits from other projects may influence related projects.