Has anyone else found that they cannot get just a comment screen to appear on transition?

[Chris Buzon]

SOLVED - Nic's final 'test', creating a screen with only 1 field, associating it with the transition, then removing the single field after the fact seems to be a workaround for this issue.  More details found down in the post, if you're seeing this issue.
Thanks Nic!

I'm not sure why I didn't try this myself...

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

I'm a fairly experienced JIRA admin - and I've never run into this problem before. 

I've changed a workflow recently, making a transition that allowed closed bugs to be reopened. This isn't generally a complicated change - however, I've found a strange issue.

If I don't assign a screen, the transition occurs as expected (no screen)
If I add an existing screen it appears as expected (the existing screen renders)
If I create a new screen for that transition but don't add any fields, no screen appears.
If I create a new screen that has assignee as the field, no screen appears.

I've been following this article: https://confluence.atlassian.com/jirakb/how-to-add-a-comment-during-a-transition-779160682.html
- it indicates that creating a screen with no fields should render just a comment field, however, I am finding that nothing appears, as though I have not assigned any screen to that transition.

There is no option to just add the comment field.

I'm a bit unsure why I can assign an existing screen and it's fine, but newly created screens completely fail to appear. 

Anyone else able to reproduce this issue?

I've tried validators to ensure a comment is added, it did not work.

[Payne]

I know that you're using Cloud, but I'll mention that in Server we do exactly as you state - we have a screen with no fields that we call our "simple comment screen", and all it does on a transition is offer the user the ability to enter comments. 

[Nic Brough -Adaptavist-]

I get the same on Cloud

[Chris Buzon]

Interesting, I wonder what I'm doing differently (if it's me at all).  I'll continue poking around.  Thanks for the confirmation that it works for your teams.

[Nic Brough -Adaptavist-]

Some more questions though, as this one has got me curious...

Are your behaviours for 1 and 3 on your list identical?  Simply no screen appears at all?  Not even a flicker of something on 3?

In 2, you get a screen with fields, but does it also have comments?

Can your user comment on the issue from the main view before the transition?

[Chris Buzon]

Correct, in 1 and 3 there is nothing at all - no flicker, not even a delay in displaying the status change. 

When the existing screen is used you do see the comment screen, and you can comment on it - despite there not being any specific callout for a comment field on the screen (I'll call the one that works "resolve issue screen"...because that's what we call it). 

The problem with using resolve issue screen is related to something else I learned (from you actually, Nic) about how resolutions are used (or misused) commonly in workflows.  We had three resolutions that were not actually valid/good resolutions ("Not Fixed", "Known Issue", and Feature Request" -- all of which I've removed from JIRA), and I am trying to get us away from ever being in a situation where an open bug has a resolution value. By creating a new comment (only) screen I was looking to stop using the 'resolve issue screen' because it forces you to choose a resolution, instead of removing values from that field on reopen.  That same screen is used correctly on dozens of projects when we're closing bugs, so I can't just edit it directly - and copying it doesn't work either.

Users can comment before and after the transition - we don't have a post-function that reopens bugs on comment. This isn't a critical issue because of that fact - we are able to do whatever we want on either side of the transition, I just have a couple of employees who really insist that a comment occurs on transition. 

I've duplicated both the workflows and screen schemes to a test project, so I'm just in the process of going through each to see if there is some button or checkbox I messed up, because I suspect this is really a problem with me...somehow.

[Nic Brough -Adaptavist-]

Ok, there's one last test to try here.

Create a new screen, giving it one single editable field (summary would do - you're not actually going to change any data during this test). Associate that with the transition that should be popping a comment box and test the transition

If a summary + comment box pops up, then the next test is to go back to the screen and remove the summary box and test again - do we get a comment now?

If you just get the summary, we have a more "interesting" problem.

[Chris Buzon]

This worked! For some reason a 'blank' (fieldless) screen doesn't pop up (I tried that again after this test), but creating a "summary" screen, associating it with the transition, then removing the summary field from that screen seems to have done the trick.

It's a weird workaround, but I'll take it!

Thanks Nic!  

[Nic Brough -Adaptavist-]

That is really odd.  Best guess is the code fails to set something on a completely empty (new) screen, so it skips straight past it.   As soon as you've got one field on it, it won't skip, but doesn't put whatever--it-is back on when you drop it to 0 fields.  So the comment remains.

[Chris Buzon]

Yup, it's a strange issue to be sure.  I'll test this again in a few weeks and see if there are any changes.