Does anyone know how to set the value of the comment field when a transition form loads?
Is there a tested and verified working method to do this? I'm not interested in people suggesting to 'try' things if they haven't actually proven themselves that they work; I've spent at least 10 hours on this with many dead-ends already - if it were straightforward I would have gotten it by now.
I have a distinct use-case for this. We moved from ClearQuest, which had a notes log, and at the top of each note it would record what status the note was left in.
Our workflow is such that there are some transitions where we require the user to enter a reason for their action; eg if a tester rejects a developer's fix, they must explain what went wrong in the testing. At the moment, the transition that appears contains only the Comment box and it is Required to fill it in for this transition, which is fine. But when you look at the log of comments, there is absolutely nothing that differentiates this 'rejection' comment from any other comment that may have been left on the issue. So if managers (such as myself) come to look at the issue and want to quickly see why the fix was rejected, we have to hunt through the comments or look at the detailed history to try and work out what the problem was.
If we had a default template that said "Issue was rejected:" at the top of the comment, it would make this easier to find. This is much more of a "very nice to have" than a mandatory requirement - we've been using Jira for over 6 months without this functionality, but I would like to add it if possible.
Other transitions where we have mandatory comments (where the screen contains only the comment field and nothing else) include re-opening an issue and when a developer sends an issue back to a tester for more information.
It's not just 1 transition that forces a comment to be left, there are multiple. It doesn't make sense to have 4-5 discrete fields to trace each action. It would be more sensible just to have 1 field.
If you're going to have 1 field, it makes more sense just to use the standard Comment field, and not a special new one.
You've still got the very human point that if you fill in a default, your users are simply not going to bother. In which case, the data is redundent - you know what they're going to enter because they're using transition X.
Your use-case does make sense, but I think you're over-engineering it, and a single filed with "latest" is still a better option. When I implemented defaulted comments in an old system, I said exactly the same thing, but the managers insisted. We agreed to revise it in a months time. Result was a 99.98% incidence of utterly pointless defaulted comments.
We moved from a system that required notes to be left. We never had a problem with people not leaving proper notes. So this "human factor" is not a problem in my company.
The workflow we have in place already requires people to leave comments. The single difference here is that we want to put a piece of boilerplate at the top of the comment to make it easy to find the comment in the log amongst all other comments that may have been left for any general reason.
I have access to a workflow validator which forces the field to be 'changed' during the transition, so the presence of this default text won't change the fact that the user will be required to enter an actual comment.
You're not understanding the use case.
The boilerplate is not for the users, it's for the managers who later want to look through the history and quickly see the comment that was left when a certain action occurred.
The current comments look like this:
Nick: Didn't pass test xyz Trudy: Could you please run tests abc and tell me the results? Nick: Didn't pass test b Nick: All tests passed
We want the comments to look like this:
Nick: ===Nick Rejected the fix, status is now In Progress=== Didn't pass test xyz Trudy: ===Trudy asked for More Info, status is now in Analysing=== Could you please run tests abc and tell me the results? Nick: ===Nick Rejected the fix, status is now In Progress=== Didn't pass test b Nick: ===Nick validated the fix, issue is now Closed=== All tests passed
Note, this isn't the actual text I'm intending to use, it's just to give a basic idea about what we're going for.
In the first case, it's not obvious that transitions have occured. In the second case, it is very obvious.
That's all we want. Yes, it is possible to look at the Transitions/History tab to see what changed, but that either presents far less, or far more, information than we want: what was the transition, what was the comment at that transition.
Mmm, I'm still thinking that if you have users who are really well behaved and always remember to edit the comment before posting it, then you've got users who don't need prompting or boilerplate.
I really do understand your point about "we need to find comments related to a transition". It's a bit clunky, but it does make sense. I just don't think ramming arbitrary, editable, error-prone text that your users can easily distort into the comment is the right answer.
I am sure I don't have enough information for a decent approach at a technical fix here, but part of my (limited) imagination here is yelling "derive a field". Any issue has a record of the transition, and a record of the (non-defaulted) transitional comment. It would not be hard to create a derived field that can look at the transtion history and comment, and automatically throw up structured search terms (instead of hoping your users don't blat the boilerplate).
I'm afraid you have not understood what I've said.
Your example even proves what I'm saying - it's not usefully searchable, it's arbitrary, and it's as clear as mud to most users.
If the boilerplate information is for the managers, then the worst possible thing you can do is put it something the users can edit. You absolutely need to be using information that is worked out independently of what a user says.
By all means, tie comments to the change and search criteria, that's a really useful thing to do. But trying to put it in comments is absolutely the wrong way to approach it.
"Your example even proves what I'm saying - it's not usefully searchable, it's arbitrary, and it's as clear as mud to most users."
It doesn't have to be searchable, it is only ever viewed on an issue by issue basis. We have a release coming out in 2 days time, we want to look at the specific issue and quickly appraise what has been going on in the history. The additional status information in the comments makes it easier to make this appraisal - we can easily see it was bouncing between Nick and Trudy based on the status change that is captured.
It's not arbitrary, it's recording the action and status that the issue is moved to and the message that was left during that transition. There's nothing "arbitrary" about that.
It's entirely clear exactly what is happening here, not least because our old system did exactly what I am proposing, everyone is used to it and no one has problems with it.
"If the boilerplate information is for the managers, then the worst possible thing you can do is put it something the users can edit. You absolutely need to be using information that is worked out independently of what a user says."
I agree I would rather have this in the headline, like our old tool did, so instead of:
Nick added a comment - 6 days ago
Didn't pass test xyz
we would have
Nick added a comment (action: Rejected) - 6 days ago
Didn't pass test xyz
However changing this would be a much more invasive change to Jira, especially when we only care about this information for some of our workflows, not all of them.
So the quickest approach seems to be to add boilerplate text to the comment.
Whether you understand or agree with our workflow is frankly pretty irrelevant.
Greg, I understand if you’re not interested enough to pay money for this. That’s cool.
For what it’s worth, I like what you’re trying to do, and I’d probably try to do it the way you were. My users are lazy, but not malicious.
That said, does looking in the “All” tab under the “Activity” section work for you? That will interleave the transitions with the comments. It’s not perfect, though. It’s going to present every change, which could be much more information to look through than you wanted. Also, it actually shows the comment associated with a transition before the transition, which I think is backwards.
Just a thought.
Just had a look at the output for "all" and it's way too noisy for this purpose. The all tab just has all the content from the Comments, History, Activity and Transitions tab - I think the Transitions tab is from an add-on we have and not part of core Jira.
Have you found any solution since posting this? I just started looking for the same capability. In my use case we are doing asset tracking with JIRA. When a user does the "Accept Item" transition to accept posesion of an item i would like that to trigger a boiler plate comment something along the lines of "I accept responsible for this asset".
Hi Atlassian community, My name is Max and I work on the product integration team at Atlassian. I am pleased to announce the early access program for the Jira Cloud add-in for Outlook. This add-in...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events