Keep issue status when processing commit messages
we just recently upgraded to Redmine 4.0.3 and face troubles updating our issues with commit messages. We are using the keyword "for" to mark commits that refer to a certain issue - but do not necessarily cause any change in its state. Therefore, so far we just left the field "Applied status" empty - with this setting, Redmine linked the commit revision to the referenced ticket, but did not change the status at all. That's exactly the bevhaviour we were looking for.
With Redmine 4.x it seems that the "Applied status" is mandatory. When looking into the log, we find the following message:
Issue #13631 could not be saved by changeset 83317: ["Status cannot be blank"]
Is there any particular reason why this behaviour was changed? And if so - is there a chance we can make the old behaviour work in our setting? Having commit messages that reference issues, but do not change their status was really handy for our development workflow.
Looking forward to your answers, Best wishes,
Too bad - I was expecting more people to have the same problem ;)
I will try to find to some spare time to look at the code to see whether we can fix this for our situation - and post the solution here, in case we find one. Any pointers are always welcome!
it's me again ;) Just in case, anyone is looking for a solution - the problem is as follows: Redmine applies the changes in app/models/changeset.rb, method fix_issue:
if rule issue.assign_attributes rule.slice(*Issue.attribute_names) end
The thing is that the rule looks as follows:
- keywords: for status_id: '0'
The '0' for the status id comes from the Redmine configuration area - if you do not select a status, it will use '0'. When assign_attributes is called with this map, the status is set to
nil - causing the problem described above. I checked the Redmine code for 3.x and could not find any changes, so I rather assume that the problem arises from changs to the
assign_attributes (from the Active Record libs). We fixed the problem by manually removing the "status_id: '0'" from the database - since we rarely change this configuration, that is a feasible way for us.