Feature #2009
closed
Manually add related revisions
0%
Description
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. :)
Files
Related issues
Updated by Thomas Lecavelier about 16 years ago
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?
Updated by Geoffrey Sneddon about 16 years ago
Yeah, that'd be my thought for UI too.
Updated by Mischa The Evil about 16 years ago
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....
Updated by Eric Davis about 16 years ago
+1 I'd like this also and can work with you on the UI for it Mischa.
Updated by Mischa The Evil almost 16 years ago
- Category set to Issues
- Status changed from New to 7
- Assignee set to Mischa The Evil
Updated by Daniel N over 15 years ago
+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 :-)
Updated by
Updated by Jacob Moen over 15 years ago
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.
Updated by
Updated by André H. over 15 years ago
Is there anyway to get this as a feature for Redmine 0.9?
It would really be great and is a must have feature.
Updated by Thomas Lecavelier over 15 years ago
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. :)
Updated by Jacob Moen over 15 years ago
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.
Updated by Mischa The Evil over 15 years ago
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...
I've been pretty busy last months and haven't had enough time to actually code something for this. Though I have been thinking about how to work this thing out using the earlier noted db-field contents. It seems one thing is still questionable: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_issuescontaining two fields:changeset_idandissue_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.
Updated by André H. over 15 years ago
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.
Updated by Jan Losinski over 15 years ago
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.
The changes are also availsable at GitHub in my manual-changeset-relation branch.
Updated by Metin Doslu about 15 years ago
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.
Updated by Adam Piotr Żochowski about 15 years ago
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
Updated by micah anderson about 15 years ago
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? :)
Updated by micah anderson about 15 years ago
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.
Updated by Oxan - about 15 years ago
- File redmine.patch redmine.patch added
I've successful backported the patch to 0.8.4. I guess it's working for 0.8.5 and higher too.
Updated by Oxan - about 15 years ago
- File redmine.patch redmine.patch added
Excuse me, there went something wrong with the diff.
Updated by Alex Bevilacqua about 15 years ago
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!
Updated by micah anderson about 15 years ago
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.
Updated by micah anderson about 15 years ago
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)
Updated by micah anderson about 15 years ago
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.
Updated by Alex Bevilacqua about 15 years ago
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.
Updated by Jacob Moen about 15 years ago
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. :)
Updated by
Updated by micah anderson about 15 years ago
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?
Updated by Oxan - about 15 years ago
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.
Updated by Oxan - about 15 years ago
- File redmine-08x-new.patch redmine-08x-new.patch added
Well, I've found the real fix.
Replace line 81 of redmine/app/views/issues/show.rhtml with this one:
<% if !@project.repository.nil? && authorize_for('changeset_relations', 'new') && @issue.changesets.any?) %>
Attached is the new patch for a clean 0.8.x installation.
Updated by micah anderson about 15 years ago
Thanks for fixing that Oxan! It works good for me, with my 0.8 install!
Updated by Mischa The Evil almost 15 years ago
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.
Updated by Mischa The Evil almost 15 years ago
- File manage_changeset_relations-expected_error.jpg manage_changeset_relations-expected_error.jpg added
- File manually_add_remove_related_changesets-new-r3078.patch manually_add_remove_related_changesets-new-r3078.patch added
- File manual_changeset_relation.jpg manual_changeset_relation.jpg added
- File manage_changeset_relations-without_permission.jpg manage_changeset_relations-without_permission.jpg added
- File manage_changeset_relations.jpg manage_changeset_relations.jpg added
- File manage_changeset_relations-add.jpg manage_changeset_relations-add.jpg added
- File manage_changeset_relations-added_195.jpg manage_changeset_relations-added_195.jpg added
Mischa The Evil wrote:
Here are my results after a first tweaking-session on the patch provided by Jan Losinski to: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.
- rebase the patch to current Redmine trunk
- remove the view duplication of the "Associated revisions" list
- clean the UI after removal of the view-duplication
- first try to fix/improve/add english translation correctly (TODO)
What I've kept the same is the design with a dedicated changeset_relations_controller with two action-methods (new and destroy). Besides that I also haven't changed the dedicated permission-migration (setup).
Here are some screenies which will be the easiest way to explain the changes and differences:
- Reference (Jan's manual-changeset-relation.patch from note 16):
- Modified patch - without the "manage changeset relations"-permission:
- Modified patch - with the "manage changeset relations"-permission:
- Modified patch - with the "manage changeset relations"-permission, adding a new associated revision:
- Modified patch - with the "manage changeset relations"-permission, successfully added new associated revision 195:
- Modified patch - with the "manage changeset relations"-permission, failed adding a revision (500) which doesn't exist in the projects repository (with translation error):
I have attached the patch file created against source:/trunk@3078 as manually_add_remove_related_changesets-new-r3078.patch. I have also posted the patch as a gist on github to make it as easy as possible for everyone to improve this patch any further. You can find (and fork :) it here: http://gist.github.com/243721.
Please let me know how you think about it?
Updated by Mischa The Evil almost 15 years ago
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.
Updated by Alex Bevilacqua almost 15 years ago
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
Updated by Josh Galvez almost 15 years ago
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.
Updated by Rafael Diaz-Tushman over 14 years ago
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:
- edit the file app/views/issues/show.rhtml
- Delete the line: "<% if @changesets.any? %>"
- 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!
Updated by Rafael Diaz-Tushman over 14 years ago
- File show.rhtml show.rhtml added
I'm attaching my version of the file: show.rhtml
in case this is easier for you then searching for the text to delete
Cheers!
Updated by Alex Bevilacqua over 14 years ago
I wonder if we could get this into 0.9.5 ... it's a pretty useful feature ... :)
Updated by Joseph S. over 14 years ago
Another vote for this feature. Please try to get this patch in to 1.0. Thanks!
Updated by Mischa The Evil over 14 years ago
- File manually_add_remove_related_changesets-new-r3764.patch manually_add_remove_related_changesets-new-r3764.patch added
Here comes an updated version of the patch manually_add_remove_related_changesets-new-r3078.patch, which I've posted in #note-36 (which is a refactoring of the patch manual-changeset-relation.patch provided by Jan Losinski in #note-16).
Changelog:- Rebased against Redmine Trunk r3764
- Fixed issue of not being able to associate a first revision to the issue due to missing partial mentioned by Alex Bevilacqua (#note-38) and Josh Galvez (#note-39).
- This fix superseeds/incorporates the changes from Rafael Diaz-Tushman in #note-40 and #note-41
- Now, the "associated revisions" block is rendered if:
!@project.repository.nil?AND@changesets.present?ORauthorize_for('changeset_relations', 'new')
- Thus the block is rendered only if the current issues project has a linked repository and, the current issue already has associated revisions or the current users role has the permission to manually add/remove associated revisions.
- Fixed CSS-styles to handle the "always available" associated-revisions partial a bit more sophisticated
- Fixed i18n error in notice about non-existing revision while adding issue/changeset-association
- Bumped the timestamp of the DB-migration
- Improved code markup
- This patch contains a DB-migration which sets-up the permissions after initial apply of the patch
- The concept of this patch might not be what you expect from it1
- By design this patch is implemented in such way that if the issues project repository is deleted, then the manually added (or removed) issue/changeset-associations are also removed without a way to restore (including removal of commit-message associations) the associations automatically. Only the associations created via keywords in commit-messages are automatically restored when the same repository is reloaded into the Redmine project1
- I'll attach the new version of the patch, created against source:/trunk@3764 as manually_add_remove_related_changesets-new-r3764.patch.
- I have also updated the gist on github to reflect the changes. You can find (and fork :) it here: http://gist.github.com/243721.
1 As discussed on IRC:
[31-05-10 22:21:27] <thegcat> Mischa_The_Evil: the problem I see isn't with a patch but with the concept: issues have a unique ID and can related to from any revision (or at least from any repository in the project of the issue IIRC), revisions don't and are unique only in the context of a project [31-05-10 22:21:48] <thegcat> haven't read that far in to be honest [31-05-10 22:24:24] <meineerde> wouldn't it be sufficient to be able to re-read some of the repository history (as done for git iirc) [31-05-10 22:27:27] <+Mischa_The_Evil> thegcat: That's covered in the patch I have. It does not allow new relations from an issue to revisions which do not belong to the SCM of the issues project. [31-05-10 22:27:55] <thegcat> and deleting the automatically created ones would imply to save this deletion somewhere so as not to recreate them in the event the repo is deleted/added anew [31-05-10 22:29:25] <+Mischa_The_Evil> thegcat: that's not covered as so. it is possible though to easily restore the automatically created ones by re-init of the repo as a whole... [31-05-10 22:30:53] <meineerde> Mischa_The_Evil: What would happen if you migrate / change repos? e.g. switch from svn to git? [31-05-10 22:31:26] <+Mischa_The_Evil> thegcat: note that the "power" to manually manage the relations is limited to a new permission which should be given to users with care... :wink: [31-05-10 22:31:47] <thegcat> Mischa_The_Evil: mmh, I'd be "surprised" if I could reference any issue from the project tree from the revisions and only the project's own revisions from the issue [31-05-10 22:35:51] <thegcat> anyhow, I think this deserves discussion: status quo, some means to re-read SCM logs or the ability to manually create issue-commit relations? if the latter on what terms? [31-05-10 22:39:26] <+Mischa_The_Evil> thegcat: that is indeed right... :) ps: I've uploaded the updated patch for 2009 to gist: http://gist.github.com/243721 [31-05-10 22:44:57] <+Mischa_The_Evil> meineerde: good question about the scm-migration... don't know yet... devving it using svn only upto now... [31-05-10 22:45:10] <+Mischa_The_Evil> meineerde: :shame: lol [31-05-10 22:47:16] <meineerde> Mischa_The_Evil: what I actually tried to say: the changeset ids are probably not very stable. Each new import of the same repo generates new changeset ids. [31-05-10 22:48:14] <meineerde> so the manual references have to be tied to the actual repository and have to be deleted if the repo goes away. might not be what the user expects, as these could not be easily regenerated. [31-05-10 22:52:50] <+Mischa_The_Evil> meineerde: that's the same issue as thegcat mentioned I assume. That is indeed true and needs to be discussed certainly... [31-05-10 22:53:42] <meineerde> Mischa_The_Evil: you are right.
Updated by
Updated by Rafael Diaz-Tushman over 14 years ago
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!
Updated by Mischa The Evil over 14 years ago
- Assignee deleted (
Mischa The Evil)
Rafael Diaz-Tushman wrote:
Could somebody confirm that this feature is in 1.0 before I attempt to upgrade?
It is not. This issue (#2009) is not closed nor resolved (against 1.0.0 (RC)) either.
To be clear, I'm currently not actively maintaining/updating the provided patches. Therefor I'll also remove myself as the assignee of this issue.
Updated by Mischa The Evil over 14 years ago
- Status changed from 7 to Resolved
OT: Can't go to "New" from "Assigned"?? Let's see what the props from "Resolved" are...
Updated by Mischa The Evil over 14 years ago
- Status changed from Resolved to New
Mischa The Evil wrote:
OT: Can't go to "New" from "Assigned"?? Let's see what the props from "Resolved" are...
That worked! :)
Updated by Ве Fio about 14 years ago
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!
Updated by Colin Mollenhour about 14 years ago
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!
Updated by
Updated by Sebastian Roth about 14 years ago
+1
May I inquire what is the stopper to include this feature? More testers/developers needed?
Updated by Victor Sergienko almost 14 years ago
I'd be happy if "associated revisions" were auto-picked up from issue comments.
Updated by Brian Lindahl almost 14 years ago
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.
Updated by Oxan - over 13 years ago
I've forward-ported the patch from Mischa to the current 1.1.2 stable release, see attached file. I guess it applies to trunk too, but I'll only maintain the patch against offical stable releases.
For the issues as noted by Brian: it is not possible for all version control systems to change the commit message easily. In SVN you can only change the commit message when you have sysadmin privileges, and for git it isn't possible at all commits, you effectively have to create a new commit, with all merging/rebasing problems. Permissions isn't a problem, the patch just adds two permissions that you can give to and revoke from users.
Updated by Toshi MARUYAMA over 13 years ago
- Category changed from Issues to SCM
Updated by Toshi MARUYAMA over 13 years ago
Oxan - wrote:
As I described at https://www.chiliproject.org/issues/198 ,I've forward-ported the patch from Mischa to the current 1.1.2 stable release
Updated by Brian Lindahl over 13 years ago
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.
Updated by Brian Lindahl over 13 years ago
Oh, and please relate this issue to #7959.
Updated by Etienne Massip over 13 years ago
- Target version set to Candidate for next major release
Updated by Ling Li over 13 years ago
+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?
Updated by Brian Lindahl over 13 years ago
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.
Updated by pasquale [:dedalus] over 13 years ago
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)...
Updated by
Updated by Adam Klinkosz about 13 years ago
+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 :)
Updated by Terence Mill almost 13 years ago
There is a plugin now, however this hall be core functionality
Updated by Jean-Philippe Lang almost 13 years ago
- Status changed from New to Closed
- Assignee set to Jean-Philippe Lang
- Target version changed from Candidate for next major release to 1.4.0
- Resolution set to Fixed
Feature added in r8777. This requires the new permission "Manage related issues" to be given. Unlike the proposed patch, the associations can be edited from the revision view (easier to reference an issue with a unique id when having cross-project relations).
The same logic applies as when referencing an issue from a commit message (by default, only in the project, subprojects or parent projects. It can be changed to any project by enabling the "Allow issues of all the other projects to be referenced and fixed" setting, introduced with #3087).