Defect #1513
openFixing issues in commit messages can break the workflow
0%
Description
I have a redmine instances with trackers with orthogonal states (for example, task have a state "done" instead of "fixed" for bugs). In the workflow, a task can never be in "fixed" state and for that reason, can't go to any other state from "fixed" state..
On the other hand, I have the option "Referencing and fixing issues in commit messages" activated but I can only specify one "Applied status" (which I have in fixed).
The problem is, if a commit message closes a task, the task is set to be in "fixed" state, but (apart from being wrong) it can't be changed (unless I make the workflow less restrictive, which I rather not).
So, I think it would be great if one can specify a "default" closed state for a tracker, and have a option in "Applied status" that says "Default closed state" or something like that, so when a commit closes an issue, the correct state can be set.
It would be great too if one can specify how to close the issue in the commit message (something like "closes #1234 (fixed)".
Thank you.
Using Redmine 0.7.2.1557 (MySQL).
Related issues
Updated by Thomas Lecavelier over 16 years ago
- Status changed from New to Closed
Admin > Settings > Repositories > Fixing keywords > Applied status
Updated by Leandro Lucarella over 15 years ago
- Status changed from Closed to Reopened
I just checked this and I don't see any changes in this matter, so I'm reopening the bug.
Updated by Jean-Baptiste Barth over 14 years ago
On recent versions you can already specify an "applied state", and the %Done to set, with associated keywords. If you want something else, could you please speak in terms of functionality and UI, and tell us how it could be integrated cleanly in the current version (0.9.6 today). Else I'll close this issue as I don't really see the point. Thank you
Updated by Leandro Lucarella over 14 years ago
I'm using 0.9.4, but I guess there shouldn't be any changes in 0.9.6 regarding this.
I think the problem is well described in the bug description (I know there is an "applied state" and that's not what I'm asking for, neither the problem I'm reporting). If I'm wrong please let me know which part is not clear enough and I'll try to explain it better.
This is not a feature request, it a defect (even when maybe a new feature, or an extension to an existing one would be needed to fix it), so please don't close it without a solution.
Thanks.
Updated by Mischa The Evil over 14 years ago
- Priority changed from Normal to High
- Affected version (unused) changed from 0.7.2 to devel
- Affected version deleted (
0.7.2)
I can confirm this issue also. It's still happening on the current trunk as of today. See also eg. duplicate #5906.
I'll change the "Affected version" accordingly.
Updated by Mischa The Evil almost 13 years ago
This is reported (in another way) again in #4648.