Setting default value to Comment field on transition screen

[Greg Hoggarth]

Does anyone know how to set the value of the comment field when a transition form loads?

I've tried various javascript hacks and groovy scripting using the behaviours add-on but just can't get this to work. It's easy to set values for other fields, but the comment field seems to be unique.

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.

Jira 6.3.

[Nic Brough -Adaptavist-]

I did it with javascript hacks, but in version 4. I removed it after we realised 99% of the comments were set to the default because the users ignore it. I'd strongly recommend not wasting your time doing this. Only make a comment if you have something useful to say, the users will just let junk drif in if you default it.

[Greg Hoggarth]

Other than Cedric offering a paid-for solution, no.

[Information Systems]

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".

[Greg Hoggarth]

Guess this isn't possible in Jira 6.3.

[Greg Hoggarth]

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.

And yes, the various javascript suggestions I have found on the internet for this appeared to be for version 4 or early version 5 and no longer work, hence my requirement for "tested and verified"

[Nic Brough -Adaptavist-]

What's wrong with a "reason for latest rejection" field?

[Greg Hoggarth]

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.

[Nic Brough -Adaptavist-]

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.

[Greg Hoggarth]

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.

[Greg Hoggarth]

Not interested enough to pay money for it :)

[CEDRIC ZABEL]

If you’re really interested in this, I’m quite good with Javascript and Jira, and I’ve done some consulting work with this. We could arrange something. It sounds like a small job. I’m only suggesting this because you’ve already indicated that you’ve already put time into this and didn’t want to pursue dead ends anymore.

[Greg Hoggarth]

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.

[Nic Brough -Adaptavist-]

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).

That also feels a bit over-engineered, but it avoids javascript (always a terrible idea in Jira), completely dodges my worries about users accepting default text, and gives you reliable and more consistent reporting. Unlike default boilerplate.

[Nic Brough -Adaptavist-]

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.

[Greg Hoggarth]

"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.

[CEDRIC ZABEL]

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.

[Greg Hoggarth]

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.

[Nic Brough -Adaptavist-]

It's from the Jira suite utilities.