I'm relatively new to JIRA administration and workflow config, though I've worked in software project and process workflow for a number of years. The previous admin at my company configured all workflows and trained users that the initial assignee should never be changed, regardless of the status of the ticket or current responsible party. Instead, custom user fields are set to indicate the code reviewer, QA and internal UAT users, who work the ticket once it hits the appropriate status. The user remains the original assignee (generally, the dev) throughout the entire workflow cycle. I've spent hours reading the documentation and watching online videos, but haven't found any good argument in favor of this practice. Is there something I'm missing that would firmly support the rule that the assignee should never change, even when the current workflow step is another individual's responsibility?

Community
Q&A
Jira
Questions
Reason for not changing assignee within project workflow?

Business Project List View - Way to show custom field as a column

As per subject, there doesn't appear to be an easy way to add a custom field that is shown on the issue when clicked as a column in the list view.

The list view by default, also doesn't appear to show all issues. For example, issues that are moved to the final workflow status of completed are not shown. If I click on filter & show all done issues, then they show up.

2 answers

1 accepted

2 votes

Answer accepted

No, you're not missing anything. You've hit on the right idea, and, much as I usually avoid being so blunt, your previous admin was wrong.

The assignee field in JIRA is designed to be "the person who is currently dealing with this issue". If they delegate parts of it out, fine, use sub-tasks or associated issues. If it's a group of people, put a field on it for the group, but "Assignee" is always the answer to "who is dealing with this at the moment". It should change during the lifecycle, unless it's the case of "I raised it and I'll do all of it".

For the other fields, actually, there's nothing wrong with them, and they can actually be really useful. If you know who the code reviewer, QA and UAT users are going to be, by all means stick them on the issue and leave them. They're useful for knowing who to assign to when your bit is done. You can even put it in post functions. For example "when developer finishes and moves issue from "in dev" to "needs testing", copy the QA user into the assignee field"

It's also not a bad thing to record "initial assignee". Again, another field and a post-function to set it would save your users having to think about it, if you can't be bothered to glance at the history. Or a scripted field to pull it from the history.

But, that core assumption that the assignee should not change is totally wrong. Assignee = single person who is working on it now, and it will change as other users need to work on it.