That's not a defect, that is related to the way you configure your workflow in Administration / Workflow, isn't it ?

You can define assignable workflow states even after the Done status has been set.
--------------------------------------------------------------------------------
This was my First idea. Indeed the done state priviously
Wasnt active for the trackr when redmine did set IT.Ny commit. But after
changing this the behavior remains the same.
So AT least in this rare case it is a Bug.
--------------------------------------------------------------------------------
Do you mean that the Done status has been set by commit although it wasn't allowed in the workflow, thus forbidding you to change it afterwards ?
--------------------------------------------------------------------------------
Yes. Thats the situation. This is paired with an other problem either:
One cannot set different auto-commit states for different trackers.

E.g.: Tracker "feature" shall be set to state "Ready for test" when developer commite "fixes #123"

but tracker "support" shall bis set to state "Done" e.g. because "Ready for test" doesn't make sense for this tracker (and there this tracker doesn't use the state "ready for test", but tracker "feature" does use it)

so
1. it shouldnt be allowed to redmine automatically set a ticket in a state which its tracker doesn't support.

2. it should be possible to assign different "fixes"- States for the differen trackers

I gues 2. point should be raised as a Feature ticket. I will do so if you want.

--------------------------------------------------------------------------------
1. Why don't you deactivate issue auto-update on commit (e.g. by removing the keyword list) or just change the applied state value if you don't want this state to be triggered ?

2. There is already #1232.
--------------------------------------------------------------------------------
I changed the applied state to a state which every tracker with code changes has, but it remains to stay in the not anymore support state, which was set wenn the commit arrived.

for 2. I will look at this.
--------------------------------------------------------------------------------
Regarding 2. :

#1232 is not what I mean.

I don't mean: many different key words which either set different issue states whith their procentages.
(which would be finde also)

but I mean:
if #123 belongs to tracker "Feature" then "fixes #123" means feature goes to "Ready for test"

if #123 belongs to tracker "Support" then "fixes #123" means feature goes to "Done"

assuming that Support dosn't have the state "Ready for test" but has the state "Done"

--------------------------------------------------------------------------------
Ok your suggestens fixed the problem:

first: I removed the fixes keyword
second: I select a automaticaly fixed state to a state all tracker have
third: I changed the workflow to be able to set from a (not anymore supported state) to "New" State, in order to reset the state
forth: From "New" state I now can set to "Done" or what ever is legal fpr the trackers workflow.

not the most intuitve way but at least it worked out.

should I raise a feature request issue in redmine tracker for the point 2. on my list?
--------------------------------------------------------------------------------
Yes, please open a feature request, I will close the defect.

BTW, do you commit code for issues filed in a Support tracker ?
--------------------------------------------------------------------------------
No of course not, it was just an example which came to my mind.
But we have diffenrent trackers which don't have the same workflow but all may have code changes which
are commited.

what keywords the redmine project it self uses? I noticed that a commit is attached to a issue just by mentioning its number , eg. Bla bla (#123)
How is this achieved?
--------------------------------------------------------------------------------
This is due to the special @IssueID@ keyword, RedMine commits never update issue status or progress, they just add a ref.

Saw you filled in #7590, still keeping this one open as defect because maybe there should exist a control to prevent auto-update an issue with a status which does not exists in the tracker's workflow.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------