When I do a commit like “closed #123”, it closes the issue no problem. But when I commit with “fixed and closing #123” it only marks the issue as resolved. Swapping the order of the keyword mappings in the settings or the order of the keywords in the commit message doesn’t change this behavior, it seems to be hard-coded.
From my point of view, the highest-priority keyword that is seen should apply, or there should at least be a workaround to address this case like going through the keywords in the order they are defined.
Thank you for your question. Do you have a transition map from Redmine at hand?
It may be plausible that the order “Resolved > Closed” is not set as possible within the Redmine instance. This would be a design decision for the individual Redmine instance and may explain why swapping both terms doesn’t change the final status.
Does the same outcome occur when you do a mapping from a freshly created ticket (Status: Created/Open) to something like “{In Progress} and {Resolved} #TicketNumber” / “{In Progress} and {Closed} #TicketNumber” (also each swapped)? The expected behavior would be that the first is resolved and the second is closed in both cases.
About priorities: SCM-Manager currently only supports “egalitarian” transition maps for their issue trackers (Jira and Redmine as of now).
As you can see all transitions are possible from the developer level but actually, the redmine user that I set up for the SCM-Manager Redmine plugin has even ‘Manager’ privileges so should be able to do anything. Manager has all boxes checked.
Results:
The first one works and the issue is set to resolved - also when swapping the keywords. It is set to “In Progress” only if the keyword for it is alone and the keyword for resolved is not part of the commit message.
The second one still doesn’t work - no matter the order of keywords, the issue only ends up in the “In Progress” status, never in “Closed”. So the behavior is the same as when using the resolved keyword together with the one for closed.
I should add that we are running the latest Redmine version 6.03.
Thank you for your information. We will look into this issue since it could indeed/likely be a bug within this SCM-Manager plugin and would be needed to be fixed, though it may take a while until this is done.
hey @ckeydel, Why do you want your ticket to go through two different statuses within a single update? This seems different from how ticket updates work in the user interface. For example, when I update a ticket, I can only select one status at a time.
I don’t want to go through multiple statuses but there should be a defined and logical behavior in the event that a commit log message contains more than one keyword, like “fixed nasty type related bug, closing #777”. The “highest” keyword should win, in this case the issue should be closed. Which, no matter in which order I define the keywords for the add-on I can’t make happen. In addition, not even the order in which the keywords appear in the log message seem to matter. From the outside, it looks as if there is an internal logic that actively looks for the “lowest” status in any appearing keyword and only applies that.
Currently the SCM-Manager Redmine Plugin logic follows the principle “first come, first serve” which means: first keyword wins.
We currently have no plans to change the behavior of the SCM-Manager Redmine plugin. However, if you’d like to propose modifications, you are welcome to create a pull request, and we will gladly review it. Alternatively, you can commission us to develop a pull request and implement a different logic according to your requirements.
At the moment, there are no plans to change the current behavior. The expected functionality is that a single keyword in a commit message triggers a status update in Redmine.
