Using '*' as keyword for repository referencing keywords doesn't work
We've set up Redmine-0.7.1 on a Windows XP machine running under mongrel using an http link to our subversion repository. We set the 'referencing keywords' to just contain '*' as indicated in the FAQ here http://www.redmine.org/wiki/redmine/RedmineSettings#32
When we browse the repository, out commit messages that start with a bug number (e.g. #9999) do get hyperlinked to that bug, but the tickets aren't specifically mentioned as referenced. Also, when we browse to that ticket, it has a comment such as 'committed in r8765' and the r8765 also correctly gets hyperlinked, but the ticket doesn't display #9999 as an associated revision.
I see this is working for the official Redmine site. Have posted this in the help forum but haven't been able to resolve it. See http://www.redmine.org/boards/2/topics/show/875
Running: * redmine-0.7.1 * svn-1.4.6 (over http) * ruby-1.8.6 * rails-2.0.2 * sqlite3-3.5.8 * mongrel-1.1.4
All other parts of redmine appear to be working correctly for us.
#1 Updated by Pierre Paysant-Le Roux over 9 years ago
The regexp used to detect issue ids in comments with "*" as keyword is (changeset.rb line 78):
In a range definition,
^ matches the
^ character and not the beginning of the line. Using
may solve the problem.
A character class matches any single character between the brackets. The characters
|, (, ), [, ^, $, *,and
?, which have special meanings elsewhere in patterns, lose their special significance between brackets.
#2 Updated by Pierre Paysant-Le Roux over 9 years ago
Here is a unit test that goes in changeset_test.rb.
def test_ref_keywords_any_line_start Setting.commit_ref_keywords = '*' c = Changeset.new(:repository => Project.find(1).repository, :committed_on => Time.now, :comments => '#1 is the reason of this commit') c.scan_comment_for_issue_ids assert_equal , c.issue_ids.sort end
#3 Updated by Anonymous over 9 years ago
Thanks Pierre, the new regex worked. I did have to delete the repository from the project and re-add it to get it to re-associate the revisions, so perhaps a 're-sync revisions' on the repository settings tab would be good (this would also work then if commit comments get altered which they can with subversion). I'll post a separate ticket about this.
#10 Updated by Anonymous over 9 years ago
- Status changed from Closed to Reopened
This still doesn't work fully. We've got a few cases where we're entering commit comments such as
#6,#7 small change to fix to issues
Using changeset.rb from 0.7.1, and also with the fix applied, will still only associate #7 with the commit. It appears to be to do with the ',' after the bug number causing an issue. We've got other commit comments like this:
Fixed #8, removed a bug in the locking code
And this won't be associated with an issue, but if I edit the log message, remove the ',' so the message reads
Fixed #8 removed a bug in the locking code, then delete and re-add the repository so the history is re-fetched, then the association with issue 8 works correctly.
FWIW, whatever passes the revision history to display the hyperlinks for the bugs on the repository browser picks all these tickets out correctly. Should they not just use the same regex?
It would be good to get this fixed before 0.7.2 as we have to keep deleting and re-adding our repositories to our projects to re-sync the history as theirs no 're-sync' option.
#13 Updated by Anonymous over 9 years ago
Hi Lane, Piere, do you both have referencing keywords set to *? We also have 'fixes' keywords set to '' and every commit we've got on like this, the issue preceding the ',' isn't associated.
Pierre, have you tried a commit such as
#1,#2 foo bar to see if both 1 and 2 are associated?
#15 Updated by Anonymous over 9 years ago
Hi Pierre, can you try with 0.7.1 then? I've applied the above regex fix to our installation and that fixed the issue where the bug number was at the start of the commit, but not the ',' case. Perhaps something else has been changed on the stable branch that has affected this also?
I'll try and get hold of the stable branch at some point and give it a go too.
#16 Updated by Anonymous over 9 years ago
OK, I've just done a checkout of 0.7-stable and a commit of
#1,#2,#3 Created trunk, branches and tags
associated the revision correctly.
On our production installation, I've edited changeset.rb as you described above, and this did fix the start of line issue, but commas after issue numbers don't work so I wonder if something else went in to 0.7-stable post 0.7.1 that touched this issue.
Anyway, seems to be working on 0.7-stable so looks like this report can be closed again.