Smart Commits are great, but unfortunately Smart Commits can be dangerous in some environments. Here is why:

Fictional scenario 1: You're maintaining a product from the 90's called 'Don 3000'

• Your Jira project has the key DON3000
• The workflow has a transition called Done

Fictional scenario 2: You are inventing R2D2

• Your Jira project has the key R2D2
• The workflow has a transition called Resolve

OK, there might be better product names or project keys, but the point is, that a project key might be a prefix of a transition name - if you ignore the digits in the project key...

What happens if someone commits with a message like this one:

Add awesomeness ref #DON3000-1, #DON3000-23

According to Using Smart Commits nothing would happen, because the issue key is prefixed with '#'. Thus the developer is not referencing the issue key correctly.

But luckily Smart Commits is smart, because nowadays everyone is referring tickets with a hash symbol.

Even Atlassian uses the '#' notation in email notifications on the customer support portal:

When I open the tickets DON3000-1 and DON3000-23, I see the commit in the development panel. Great!

But wait.... What happened?!?

The ticket DON3000-1 is now done! According to the activity panel, the commit closed DON3000-1. Well, that's unexpected!

I would say the hash notation for tickets are common and should not be considered as a bug. Jira and Bitbucket accept this notation and link issues with commit messages using this notation. But the command parsing of Smart Commits is really lousy.

Looking at com.atlassian.jira.plugin.devstatus.smartcommits.DefaultCommitMessageParser you know why:

private static final String COMMAND_TEXT = "([A-Za-z][A-Za-z\\-]*)";
private static final String COMMAND_EXTRACTION_PATTERN = NON_CAPTURING_WHITESPACE + "(?=#" + COMMAND_TEXT + ")";

The parser simply stops at the first character not being a letter or the dash character. If at least the pattern would allow digits... Can't transition names have digits?

Note: I haven't tested what happens if you extend the pattern for digits like "([A-Za-z][A-Za-z0-9\\-]*)", but if you accept any code contribution I would be happy to write some tests (maybe you already have some, tests are not part of the dependency sources... but that's another topic...)

Note: This bug is related to JRASERVER-60746 which would also solve this issue, but that issue might be considered as a feature, so that the lazy programmer only has to write #c instead of #close...

Final note: We have a client suffering from this issue. So it is not just a fictional edge case scenario. It does happen already and who knows how many issues have been closed or whatever by accident.

Final final note : Affects Version is probably every 7.x version. I just tested it on my own test instance which had version 7.5.3.

Argh: I think this is a bug and would like to file it here, but your instance is broken:

1. Creating a bug ticket for project JRASERVER is unusabe as you provide no description field or other multiline textfield
2. Creating a bug ticket for project JSWSERVER fails on submission complaining that my user does not have the 'Assign Issue' permission
3. I'll try submitting it as a "Suggestion" - please consider it as a bug and let me know if you're taking care of it. Otherwise feel free to close it immediately and say something like "we don't care".