Project

General

Profile

Actions

Defect #3087

closed

Revision referring to issues across all projects

Added by Zarooba Rozruba over 15 years ago. Updated almost 13 years ago.

Status:
Closed
Priority:
Normal
Category:
SCM
Target version:
Start date:
2009-03-31
Due date:
% Done:

80%

Estimated time:
Resolution:
Fixed
Affected version:

Description

Hello

Short summary

I am trying to get a commit from a sub project close/reffer to an issue on a main project.

Nothing is being insert into changesets_issues table.

Further more, if I insert into changesets_issues table myself, the url to repositories/revision/ is generated to main project (where issue exists) instead of pointing to sub project (where the revision exists).

Redmine 0.8.2

Long winded example

I have a parent project on which users can create issues.

However, developers have split this project into distinct components, each with own repository (background tasks, project website, nightly processes). For each component I have create a sub project.

Users do not care about these components.

I have made such that:
- main project has issues module enabled, but repository module disabled
- sub projects have issues module disabled, but repository module enabled

This way all user activity within redmine happends on main project.
Redmine sees repository updates from subprojects and shows them on main project screen.

However, revision to issue (changesets_issues table) is not working.

There are two projects
- Main project : url web id 'main'
http://example/projects/overview/main
- sub project (nightly task) : url web id 'sub'
http://example/projects/overview/sub

issue created ( # 20 ) on main project ( url web id 'main' )
url : http://example/issues/show/20

Developer fixes code ( revision 123 on repository id 11 with changeset_id 1234)
url : http://example/repositories/revision/sub/123

Developers commit comment is : "" commit fixes # 20 ""

When I visit revision from redmine
url : http://example/repositories/revision/sub/123
the string # 20 links properly to my issue:
url : http://example/issues/show/20

However, There is nothing inserted into changesets_issues

I have tried, to create a link by hand:

INSERT INTO changesets_issues ( changeset_id , issue_id ) 
VALUES ( 1234 , 20 ) ;

This worked, now I see ""Associated Revisions"" under my issue # 20. However, the url is :
url : http://example/repositories/revision/main/123
instead of
url : http://example/repositories/revision/sub/123

closing notes

So two problems are :
1) comment from commit does not close/refer to an issue, if commit is different project than issue
2) once there is cross project entry in changesets_issues table, the issue page generates wrong url to repository revision (ignores the possibility that commit revision on an issue is from different project)

Thank you for reading this, and thank you for looking if this is something to update.

Kind regards


Files

commit_update_parent_project.patch (2.58 KB) commit_update_parent_project.patch Patch against 2731 for issue #3087 Lincoln Stoll, 2009-05-11 02:02
100324-cross-project-revisions.patch (641 Bytes) 100324-cross-project-revisions.patch William Baum, 2010-03-24 16:12

Related issues

Related to Redmine - Defect #4163: Allow cross-project references in commitsClosed2009-11-04

Actions
Related to Redmine - Defect #3376: Moving an issue to another project copies the associations revisions instead of updating themClosedJean-Philippe Lang2009-05-17

Actions
Related to Redmine - Feature #3346: Support for cross-project revision linksClosed2009-05-12

Actions
Related to Redmine - Feature #779: Multiple SCM per projectClosedJean-Philippe Lang2008-03-04

Actions
Has duplicate Redmine - Feature #12726: Display the associated revisions with a given issue even if the project doesn't have a dedicated repositoryClosed

Actions
Actions #1

Updated by Mohan Varma over 15 years ago

+1

We are having the same issue.

Regards,
Mohan.

Actions #2

Updated by Lincoln Stoll over 15 years ago

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

Actions #3

Updated by Lincoln Stoll over 15 years ago

This is a combination of the patch in #2256 and an update to the issue page to make it link to the correct project in the associated revisions.

This should fix this issue - it allows you to commit to a subprojects repository, and update the parent project.

The patch is against rev 2731 (0.8.3)

Does anything else need to be done to make this visible and get it accepted?

Actions #4

Updated by Lincoln Stoll over 15 years ago

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

Actions #5

Updated by Zarooba Rozruba over 15 years ago

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.

Actions #6

Updated by Zarooba Rozruba over 15 years ago

  • % Done changed from 0 to 30

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

Actions #7

Updated by Bob Roberts over 15 years ago

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)

Actions #8

Updated by William Baum over 15 years ago

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

Actions #9

Updated by Roman Musin over 15 years ago

+1

It is real need.

Actions #10

Updated by Thomas Pihl about 15 years ago

+1

Actions #11

Updated by Markus Meier about 15 years ago

+1

Actions #12

Updated by Lalit Roul almost 15 years ago

make it +1 from me too..

Actions #13

Updated by Lalit Roul almost 15 years ago

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.

Actions #14

Updated by Geordee Naliyath over 14 years ago

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.

Actions #15

Updated by William Baum over 14 years ago

I too would like to see this in the trunk, perhaps controlled by an "Allow cross-project revisions" admin setting.

In recent versions, this has become even easier to achieve, as the trunk allows revisions to refer to different projects in the same tree. It does this be checking all of the referenced issues in the revision to see if they refer to the current project or its ancestors or descendants in app/models/changeset.rb:

  # Finds issues that can be referenced by the commit message
  # i.e. issues that belong to the repository project, a subproject or a parent project
  def find_referenced_issues_by_id(ids)
    return [] if ids.compact.empty?
    Issue.find_all_by_id(ids, :include => :project).select {|issue|
      project == issue.project || project.is_ancestor_of?(issue.project) || project.is_descendant_of?(issue.project)
    }
  end

To get cross-project revisions, we just need to skip those checks:

  # Finds issues that can be referenced by the commit message
  # i.e. issues that belong to the repository project, a subproject or a parent project
  def find_referenced_issues_by_id(ids)
    return [] if ids.compact.empty?
    Issue.find_all_by_id(ids, :include => :project).select {|issue|
      project == project
      ###project == issue.project || project.is_ancestor_of?(issue.project) || project.is_descendant_of?(issue.project)
    }
  end

I'm attaching an svn formatted patch against r3606, which is still current, as changset.rb is currently at r3473. While patches are cumbersome to maintain, this one's really a one-liner in one file.

Actions #16

Updated by Felix Schäfer over 14 years ago

  • Status changed from Resolved to Closed

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

Actions #17

Updated by William Baum over 14 years ago

  • Status changed from Closed to Reopened

This is still valid, as the trunk allows revisions only to issues in related projects (parents, children). This change allows revisions in any repository to be associated with an issue in any project.

This is an essential part of the way we use Redmine in our organization, and I personally see no benefit in preventing revisions from being associated with issues, but perhaps this should be controlled by a permission setting?

Actions #18

Updated by John Bart about 14 years ago

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

Actions #19

Updated by Bob Bottle almost 14 years ago

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

Actions #20

Updated by Toshi MARUYAMA almost 14 years ago

  • Category changed from Issues to SCM
Actions #21

Updated by Martin Denizet (redmine.org team member) over 13 years ago

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.

Actions #22

Updated by Artur Wasilewski over 13 years ago

+1

Actions #23

Updated by David Chiew over 13 years ago

+1 please!

Actions #24

Updated by William Baum about 13 years ago

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.

Actions #25

Updated by William Roush almost 13 years ago

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

Actions #26

Updated by Jean-Philippe Lang almost 13 years ago

  • Subject changed from Revision referring to issues across projects to Revision referring to issues across all projects
  • Status changed from Reopened to Closed
  • Assignee set to Jean-Philippe Lang
  • Target version set to 1.4.0
  • Resolution set to Fixed
This is now fixed:
  • related changesets are displayed on the issue even if the repository module is disabled on the issue's project (r8749)
  • a new setting is added in r8750 to allow issues from any project to be referenced/fixed (by default, only issues of parent and subprojects can be referenced/fixed)
Actions

Also available in: Atom PDF