Redmine

That's a very good idea, and I think it's a must have.

For the presentation, I'm thinking about a modifiction of the UI around the "relations" DIV, which should become something like "related issues and commits".

Any thoughts about it?

Yeah, that'd be my thought for UI too.

In essence this would be quite simple to implement since the issue-relation is simply stored in the DB-table changesets_issues containing two fields: changeset_id and issue_id.

I already tried a quick thing by modifying the respective views, though I got cought by scoping-limitations.

I'll try to come up with something as soon as I have working RDoc-documentation of Redmine....

+1 I'd like this also and can work with you on the UI for it Mischa.

+1 This would be very helpful and would improve the workflow while working with "related" revisions. Implementation similar like related tickets would be great. If the linked revisions might be integrated in the ticket "history" like #3046 suggests the ticket/revision workflow would be perfect :-)

+1

I have forgetful developers, so I would really like to have the option of adding related revisions manually. :)
Of course, one could always use SVN revision history lists and phpMyAdmin..
Plus one from me.

+1

Is there anyway to get this as a feature for Redmine 0.9?
It would really be great and is a must have feature.

André H. wrote:

Is there anyway to get this as a feature for Redmine 0.9?
It would really be great and is a must have feature.

Of course there is: help Mischa to right the patch, test it, submit it. :)

+1

If there is a patch for this, I assume it's against trunk (HEAD) - could someone link to the patch or attach it here, so we can test it? :)

I use a pre-commit hook to prevent my developers commit without referencing an issue ID, but - unfortunately - some devs just reference a catch-all issue number, like Gui Work.
It would be great to go back and manually add related commits to tickets, especially for tickets created after the commit is made.

Jacob Moen wrote:

If there is a patch for this, I assume it's against trunk (HEAD) - could someone link to the patch or attach it here, so we can test it? :)

No patches exist yet to be honest...

Mischa The Evil wrote:

In essence this would be quite simple to implement since the issue-relation is simply stored in the DB-table changesets_issues containing two fields: changeset_id and issue_id.

I already tried a quick thing by modifying the respective views, though I got cought by scoping-limitations.

• should we be able to delete related revisions also?
  • If yes: should we implement removal options for automatically added related revision too?

Does someone has any other ideas?

Note: I've assigned the issue to myself to keep myself reminded to it. I think I'm able to come up with something as soon as I get some more spare-time to actually start on this. It does not mean that I've "claimed" the issue. I don't have working code to solve this issue yet [ sic ] you can re-assign it to yourself if you are also working on something for this issue and for example already have some working code ;-)

Kind regards,

Mischa.

I think one should be able to delete related revisions. People tend to make mistakes, so they need a chance to correct them :)
I'am not sure about automatically added revisions. On the one hand it can be helpful, but on the other hand the commit-message would be inconsistent.

Geoffrey Sneddon wrote:

Currently the only way to add a related revision to a ticket is through a magic string in the commit message — it would be nice to be able to add related revisions after the commit is made manually, as sometimes magic strings are forgotten. :)

What is this a magic string in the commit message? Revision numbers are not visible at my issue pages.
Thanks.

Metin Doslu wrote:

Geoffrey Sneddon wrote:

Currently the only way to add a related revision to a ticket is through a magic string in the commit message — it would be nice to be able to add related revisions after the commit is made manually, as sometimes magic strings are forgotten. :)

What is this a magic string in the commit message? Revision numbers are not visible at my issue pages.
Thanks.

click administration -> settings -> repositories .

There you will find two entries: 'Referencing keywords' and 'Fixing keywords'. You can change them to match your country preference. Keywords are comma separated. In the commit message use space between keyword and issue number (good: "" refs #1234 "" bad: "" refs#1234 "")

Kind regards

Adam Żochowski

Jacob Moen wrote:

I use a pre-commit hook to prevent my developers commit without referencing an issue ID, but - unfortunately - some devs just reference a catch-all issue number, like Gui Work.

Nice, care to share that hook? :)

I wanted to test this patch, but I am not running the latest code, but rather the stable version, so I tried to port this patch to 0.8.6, but in the end it failed with the following:

ActionView::TemplateError (undefined method `relations' for nil:NilClass) on line #81 of issues/show.rhtml:
78: </div>
79: <% end %>
80: 
81: <% if !@project.repository.nil? && (authorize_for('changeset_relations', 'new') || @changesets.relations.any?) %>
82: <hr />
83: <div id="changeset_list">
84: <%= render :partial => 'changeset_list', :locals => { :changesets => @changesets} %>

I guess I have to either upgrade to trunk, or wait for this.

Just patched the latest trunk (r2902), and there's only 1 error, so thought I'd post the results:

alex@lnx-vm-web01:~/redmine$ patch -p1 < manual-changeset-relation.patch
patching file app/controllers/changeset_relations_controller.rb
patching file app/helpers/changeset_relations_helper.rb
patching file app/views/changeset_relations/_form.html.erb
patching file app/views/issues/_changeset_list.rhtml
patching file app/views/issues/show.rhtml
patching file config/locales/de.yml
Hunk #1 FAILED at 833.
1 out of 1 hunk FAILED -- saving rejects to file config/locales/de.yml.rej
patching file config/locales/en.yml
Hunk #1 succeeded at 827 (offset 23 lines).
patching file db/migrate/20090821144826_add_manage_changeset_relations_permission.rb
patching file lib/redmine.rb
patching file test/functional/changeset_relations_controller_test.rb

FYI ... this works PERFECTLY. I think this is something that should make it's way into the trunk, as there are several projects I keep in redmine that i'm working on/from that I don't always have commit access to (but am watching the trunk), or come onto the project late and want to associate old revisions to current issues for reference.

Good work!

Oxan ... wrote:

Excuse me, there went something wrong with the diff.

This patch worked for me against 0.8.6 and it seems to do exactly what is needed. The only thing I noticed that might be an improvement, but should not hold this back from being accepted (especially since this may be a limitation in redmine, and not the patch itself), would be to accept the short form commit IDs. For example, with a git repository, the repository viewer represents the short form of the commit ids in the Revision column, e.g. 'c9018585', when you click on that short-form, you get the longer one in the URL: 'https://site.domain.com/code/repositories/revision/repository/c9018585d69b3682008fbad7e4b8f44c6bab5152'

Would be nice to be able to just grab that short form and put it in as an association.

An update to this issue... some users are reporting problems when clicking on issues. I am not having these issues, which is odd, but more than one person is and I see a traceback in the logs when they click on an issue and get an Internal Server Error (oddly, I do not get it myself). this is what is reported in the log:

Processing IssuesController#show (for 190.55.190.151 at 2009-10-01 09:36:04) [GET]
  Session ID: 3a903ef59b636180b874551b10c75149
  Parameters: {"action"=>"show", "id"=>"1296", "controller"=>"issues"}
Rendering template within layouts/base
Rendering issues/show.rhtml

ActionView::TemplateError (undefined method `relations' for #<Class:0x41232878>) on line #81 of issues/show.rhtml:
78: </div>
79: <% end %>
80: 
81: <% if !@project.repository.nil? && (authorize_for('changeset_relations', 'new') || @issue.changesets.relations.any?) %>
82: <hr />
83: <div id="changeset_list">
84: <%= render :partial => 'changeset_list', :locals => { :changesets => @issue.changesets} %>

    /var/lib/gems/1.8/gems/activerecord-2.1.2/lib/active_record/base.rb:1672:in `method_missing'
    /var/lib/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_collection.rb:288:in `send'
    /var/lib/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_collection.rb:288:in `method_missing'
    /var/lib/gems/1.8/gems/activerecord-2.1.2/lib/active_record/base.rb:1857:in `with_scope'
    /var/lib/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_proxy.rb:164:in `send'
    /var/lib/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_proxy.rb:164:in `with_scope'
    /var/lib/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_collection.rb:284:in `method_missing'
    app/views/issues/show.rhtml:81:in `_run_erb_47app47views47issues47show46rhtml'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_view/base.rb:342:in `send'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_view/base.rb:342:in `execute'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_view/template_handlers/compilable.rb:29:in `send'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_view/template_handlers/compilable.rb:29:in `render'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_view/template.rb:35:in `render'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_view/template.rb:22:in `render_template'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_view/base.rb:248:in `render_file'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/base.rb:1112:in `render_for_file'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/base.rb:872:in `render_with_no_layout'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/layout.rb:251:in `render_without_benchmark'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/benchmarking.rb:51:in `render'
    /var/lib/gems/1.8/gems/activesupport-2.1.2/lib/active_support/core_ext/benchmark.rb:8:in `realtime'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/benchmarking.rb:51:in `render'
    app/controllers/issues_controller.rb:108:in `show'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/mime_responds.rb:131:in `call'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/mime_responds.rb:131:in `custom'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/mime_responds.rb:160:in `call'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/mime_responds.rb:160:in `respond'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/mime_responds.rb:154:in `each'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/mime_responds.rb:154:in `respond'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/mime_responds.rb:107:in `respond_to'
    app/controllers/issues_controller.rb:107:in `show'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/base.rb:1166:in `send'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/base.rb:1166:in `perform_action_without_filters'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/filters.rb:579:in `call_filters'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/filters.rb:572:in `perform_action_without_benchmark'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue'
    /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/rescue.rb:201:in `perform_action_without_caching'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/caching/sql_cache.rb:13:in `passenger_orig_perform_action'
    /var/lib/gems/1.8/gems/activerecord-2.1.2/lib/active_record/connection_adapters/abstract/query_cache.rb:33:in `cache'
    /var/lib/gems/1.8/gems/activerecord-2.1.2/lib/active_record/query_cache.rb:8:in `cache'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/caching/sql_cache.rb:12:in `passenger_orig_perform_action'
    /usr/lib/ruby/1.8/phusion_passenger/railz/request_handler.rb:64:in `perform_action'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/base.rb:529:in `send'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/base.rb:529:in `process_without_filters'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/filters.rb:568:in `process_without_session_management_support'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/session_management.rb:130:in `process'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/base.rb:389:in `process'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/dispatcher.rb:149:in `handle_request'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/dispatcher.rb:107:in `dispatch'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/dispatcher.rb:104:in `synchronize'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/dispatcher.rb:104:in `dispatch'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/dispatcher.rb:120:in `dispatch_cgi'
    /var/lib/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/dispatcher.rb:35:in `dispatch'
    /usr/lib/ruby/1.8/phusion_passenger/railz/request_handler.rb:49:in `process_request'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_request_handler.rb:206:in `main_loop'
    /usr/lib/ruby/1.8/phusion_passenger/railz/application_spawner.rb:376:in `start_request_handler'
    /usr/lib/ruby/1.8/phusion_passenger/railz/application_spawner.rb:334:in `handle_spawn_application'
    /usr/lib/ruby/1.8/phusion_passenger/utils.rb:182:in `safe_fork'
    /usr/lib/ruby/1.8/phusion_passenger/railz/application_spawner.rb:332:in `handle_spawn_application'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:351:in `__send__'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:351:in `main_loop'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:195:in `start_synchronously'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:162:in `start'
    /usr/lib/ruby/1.8/phusion_passenger/railz/application_spawner.rb:213:in `start'
    /usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:261:in `spawn_rails_application'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add'
    /usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:255:in `spawn_rails_application'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server_collection.rb:80:in `synchronize'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server_collection.rb:79:in `synchronize'
    /usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:254:in `spawn_rails_application'
    /usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:153:in `spawn_application'
    /usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:286:in `handle_spawn_application'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:351:in `__send__'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:351:in `main_loop'
    /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:195:in `start_synchronously'
    /usr/lib/phusion_passenger/passenger-spawn-server:61

Rendering /usr/apps/redmine/public/500.html (500 Internal Server Error)

Further information about this problem... it seems like it happens only when you are not signed in. If you are logged in, everything works fine, but for those who are not logged in, you get this error.

+1 for this into redmine

I just noticed this after applying the patch. There should be a check in the code to see if the project the issue belongs to even has an SCM method associated with it. If no SCM exists, there shouldn't be an option to add related revisions.

micah anderson wrote:

Jacob Moen wrote:

I use a pre-commit hook to prevent my developers commit without referencing an issue ID, but - unfortunately - some devs just reference a catch-all issue number, like Gui Work.

Nice, care to share that hook? :)

I grabbed it from Bloomquists in the Blagosphere -> Subversion pre-commit hook for Redmine
It served us well when we were using SVN. :)

+1!

Oxan,

Do you get the traceback mentioned above on your 0.8 redmine with your patch for associating revisions when you are not logged in?

Do other people get that traceback when not logged in, using the latest trunk?

micah anderson wrote:

Oxan,

Do you get the traceback mentioned above on your 0.8 redmine with your patch for associating revisions when you are not logged in?

Do other people get that traceback when not logged in, using the latest trunk?

I get that error too. However, I don't use anonymous access, so I didn't noticed it. A quick fix is replacing that line with:
<% if !@project.repository.nil? && authorize_for('changeset_relations', 'new') && @issue.changesets.relations.any?) %>

I don't know enough about Ruby and Redmine to create a full fix.

Thanks for fixing that Oxan! It works good for me, with my 0.8 install!

Jan Losinski wrote:

I have build a patch to bring this feature to redmine. It creates a related revision list like the related isue list with the same add/remove capabilities.

I'm currently working on an enhancement of the manual-changeset-relation.patch by Jan Losinski to improve the UI-part of the patch.
I'll post my results on this issue later.

Kind regards,

Mischa.

Mischa The Evil wrote:

[...]

Please let me know how you think about it?

Any feedback already??? I'm pretty curious about the general opinion about the way I've changed the patch/core to fit the feature into the Redmine UI nicely.

Mischa The Evil wrote:

Mischa The Evil wrote:

[...]

Please let me know how you think about it?

Any feedback already??? I'm pretty curious about the general opinion about the way I've changed the patch/core to fit the feature into the Redmine UI nicely.

I just reverted my redmine trunk to wipe the old changeset patch so I could apply the one you provided (and it works perfected with patch -p0 < patchfile). The UI changes are nice, but I'm not sure how i'm supposed to associate a revision to an issue if there aren't any revisions already. In the old patch, the Associated Revisions section was always there (with an add button), but in this one, if there are no revisions, there's no way to add them (without doing it directly in a commit message).

Please correct me if I've missed something :P

Mischa,
Your patch also applies fine against r3135.
Though, I have the same concern as Alex, there is no way to add a revision when there aren't any associated to begin with.

For anyone who is interested in having this capability EVEN WHEN the issue doesn't have any associated revisions to begin with, I did this:

1. edit the file app/views/issues/show.rhtml
2. Delete the line: "<% if @changesets.any? %>"
3. and its pair: "<% end %>"

After you have applied this thread's patch and made the above changes, then your show.rhtml will look like this:

<div id="issue-changesets">
<div class="contextual">
<% if authorize_for('changeset_relations', 'new') %>
    <%= toggle_link l(:button_add), 'new-changeset-form'%>
<% end %>
</div>

<h3><%=l(:label_associated_revisions)%></h3>

<div id="issue-changesets-list">
<%= render :partial => 'changesets', :locals => { :changesets => @changesets} %>
</div>
</div>

Yes, this means the header "Associated revisions" will display no matter what, but who cares... so does the header "Watchers" and "Related Issues"!

Cheers!

I wonder if we could get this into 0.9.5 ... it's a pretty useful feature ... :)

Another vote for this feature. Please try to get this patch in to 1.0. Thanks!

+1!

I'm still using Redmine 0.9.4.devel.3764 (MySQL) just so that I can keep this patch - it's a critical feature for our Redmine installation. However, I'd like to upgrade to 1.0

Could somebody confirm that this feature is in 1.0 before I attempt to upgrade?

Cheers!

This would be an excellent feature to include. I made a commit and accidentally forgot to include the magic string. Even though I have a pre-revprop hook to change the svn:log and Redmine revision comment, changing it to the magic string didn't work of course, and neither did deleting the revision out of the database and re-fetching it. I had to manually add the reference in the database, which wasn't too pleasing.

Would be nice to be able to do it from Redmine!

I use both Unfuddle and Redmine and this is the only feature I miss in Redmine.. Someone please update the patches to the latest stable, or preferably, commit this to trunk. Cheers!

+1

+1

May I inquire what is the stopper to include this feature? More testers/developers needed?

It looks like nobody knows :-)

I'd be happy if "associated revisions" were auto-picked up from issue comments.

I'd be happy if "associated revisions" were auto-picked up from issue comments.
This sounds tricky and error-prone.. if you reload (delete/add) a repository, the associated revision is lost, unless you rescan all journals (comments) for that project. You also run into a lot of problems how you delete a revision assocations via changing the journal - if a repository is reloaded, and a revision association was removed via changing a journal, then this action of deleting a revision association is lost, and the revision association will be re-created (not what you want). You also have problems with how to handle permissions. Anyone who can add issue comments then is capable of adding revision associations.

Personally, I'd prefer a 'reload revision' command. You then edit the commit message in the repository and then click 'reload revision' and it then removes any old associations, and creates new ones. This way, the repository now contains the correct information, and a reload (delete/add) of the repository will produce the ~correct results. Journals are modified to have their text 'Applied in changeset r49' replaced with 'Applied in changeset r49 (changeset reloaded)', or something like that. To indicate the historical modification of the changeset. I suppose another possibility would be to rollback the journal, providing there aren't any subsequent journals, but this is more dangerous, IMO.

Note that any time logged, done%, or status changes from bad commit messages will have to be manually removed/backed out, but this is no worse than the patch provided above for manually adding/deleting revision associations.

Oxan - wrote:

I've forward-ported the patch from Mischa to the current 1.1.2 stable release

• There is no test in your patch.
• You should not use "changeset.revision". Please see #3724, #6681.

See #7959 for a patch to reload revision commit messages from the repository. This is likely the preferred way to add/remove related revisions, if your SCM allows for commit messages to be edited.

Oh, and please relate this issue to #7959.

+1 This feature is very useful as human beings do (and always) make mistakes.

I would like to apply the latest patch against 1.1.2, but wonder

• if the final committed version uses a different database layout, would there be a way to migrate from the current patch?
• if a repository is reloaded (either via the path in #7959, or via deleting the repository and then readding it), would the association be messed up somehow?

Ling Li wrote:

• if a repository is reloaded (either via the path in #7959, or via deleting the repository and then readding it), would the association be messed up somehow?

Yes, any manually deleted associations would be re-added back in. This is why the only robust solution, is to fix the commit message (if your SCM allows it) and then reload the revision via #7959.

It's a very good idea, I agree!

In the real world, if I want to track all my changes between the years, this functionality should be a little more extensible: for example, on the last years my devs team have being used a folder to commit (for example Projects2010), this years we use Project2011 (we using mercurial, and create new folder on new year for performance raison etc,... ).

If bug 1 has a patch committed on project2010 (rev 1 on the server) and this year we are on project2011, "associated revisions" section could be link rev1?

It's great if redmine can permit to add an associated revision statically (for example, on my server rev 1 is on mercurial at https:\\hg-2010\projectA\rev1: then I have to add the link for mercurial changset to "associated revision" section)...

+1

+1

+1
Add and delete relations. It is sometimes frustrating when I make a mistake and have to do some tricks to fix it. And I have to be fast too, before any other user refreshes the repository with new commit :)

There is a plugin now, however this hall be core functionality