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.
If this was “expected functionality” it would be documented, but it isn’t. I certainly didn’t expect it either. More likely you mean expected use. Having undocumented and essentially unpredictable behaviour this way is a defect as your colleague originally conceded:
I don’t at all mind being told that a bug is not important enough to be fixed with the limited resources available. After all, you provide this great software to the community for free.
Just try to be upfront about it, please.
I did recreate your scenario with the “closing and fixed / fixed and closing” keywords another time and could reproduce your describe the behavior that the ticket couldn’t be closed and was set as “fixed” in both cases.
However, when I just entered “closing #123”, it did close the ticket as expected, and “fixed #123” set it to “Resolved”. If this had been the same case as with two keywords, this would have been a somewhat crucial bug for investigation.
We discussed this topic in our team and concluded that noting two keywords at once would count as a feature request rather than a bug because the expectation is that just one keyword (for one transition, also for transitively implied ones like Resolved > Closed) is the expected use. It has been assumed that it may make sense in a few cases (e.g. wanting to have both ‘fixed’ explicitly mentioned in a Redmine comment before closing it). In which use case do you require two keywords to be set at once? (Edit: Missed the previous answer before. In this case, if it’s incompatible to your workflow, I’d either try to adapt the mapping in the Settings section [excluding “fixed” as a work] so that it can be safely used or use another word.)
Regarding the documentation, this is a point and we will add it there with the next plugin release. To be precise, though, I did not say that it was (definitely) a bug but that it was likely under the assumption it would violate the expected behavior, which (because during recreation it only occurred with two keywords we haven’t been regarding as part of the scope) was eventually not the case.
Nonetheless, thank you for your feedback and that you regard the SCM-Manager as a great software to use!
