In Kanban board, dragging from Backlog to In Progress changes assignee - how to prevent this?

[Robert Meador]

I just started working with boards and am setting up a Kanban board based on a filter (tasks assigned to a particular user). I chose the separate Backlog view since he has about 28 tasks assigned to him. When I drag a task from the Backlog area up to In Progress, the assignee always gets changed to me. How do I disable this behavior?

I can edit and change the assignee back but I'd rather not have to.

[Robert Meador]

Ahh ok, I just discovered something. I have 50 projects using the "classic default workflow" and 86 using the "default workflow" and these are not the same thing.

The "default workflow" does not have a "Backlog" step in it. When I go to edit it, Jira says "As you are editing your workflow for the first time, Jira needs to create a copy of the read-only system workflow. This may take a while depending on the number of issues in your project."

This is a little concerning since that's 86 projects, some with hundreds of issues. Is it safe to edit this workflow? Though I suppose if I don't I can't use boards...

Sounds like you hit the nail on the head though - more than one workflow. I should probably get all our projects on the same workflow, since the boards I want to use will contain tasks from multiple projects.

Are the steps different for different issue types? Bug vs. task vs. improvement? I don't see where I would edit those.

Also can you shed some light on this (screenshots)? Two different projects, same Workflow Scheme. Both using "Jira Workflow". But different list of issue types in each? Should the issue types be the same if they're using the same Workflows?

Is there any way to just get everything in Jira to behave the same way? I don't need this level of granularity. Consistency and predictability is much more important for me.

[Hernan Halabi - Elite IT Consulting Group]

Hi @Robert Meador a couple of comments. 

You can't edit the system workflow which is why is asking for a copy. You can edit that one and later you will have to apply it to your projects. Even though the change is simple, if you aren't certain of what you are doing I would suggest you don't do it since you could be impacting several projects all together. Asking for help in the community is always an option but if you need things done faster is usually better to go with a professional at least until you are more familiar with the tool.

Based on the images attached the same workflow is applied to all the issue types, you see more of those in one image because of the project you are seeing. It only has more issue types assigned to it.

[Robert Meador]

Hernan, I would like to see about hiring you to help me improve our Jira implementation. If you are amenable to this, let me know how I might contact you.

[Hernan Halabi - Elite IT Consulting Group]

Hi @Robert Meador you can search for me at LinkedIn or leave a message at our website and I will reply through there.

[Robert Meador]

You bet. Not sure where I'd find automation rules, but here are some screenshots.

The workflow is the "classic default workflow", which we use for all projects. Unfortunately Jira creates a new workflow for every project - we can't just use the same default one for all projects. So for each project we must create, then edit to change the work flow to the default. Not relevant, just a side rant :)

[Hernan Halabi - Elite IT Consulting Group]

No worries, looks like you are checking the wrong transition. Notice that the backlog status isn't mapped to a column in the board. That means that tickets with that status won't show on it. On the other hand, you have 3 status mapped to the backlog section of the board and those are the ones you have to check.  From the image you have of the workflow, it should be the start progress transition.

There is another workflow associated to the issues listed on the board. There is a chance we are seeing the wrong workflow as well. Depends on the issue type in which this is happening

[Robert Meador]

"Notice that the backlog status isn't mapped to a column in the board. That means that tickets with that status won't show on it."

Yes, backlog doesn't appear on the board. When we went to set it up, Jira said "you have a lot of tasks in your backlog. Do you want to add a Kanban backlog (or something like that). I clicked yes and it removed them from the board and switched them to a separate page. At least I think that's what happened.

I looked at the "start progress" transition. I don't see anything suspect in the Post Actions, but I do notice in Conditions there is one condition:

• Only the assignee of the issue can execute this transition.

I am not the assignee of the issues that I am moving to In Progress. Could that be a factor? Is Jira trying to make this false condition true before it will move the task? Should I add a Post action to reassign the task back to the original assignee (is that even possible)?

Please note I am not trying to do anything fancy here. We have not significantly customized our Jira. I am not a professional project manager (well, that's only one of my many jobs). We're just looking for a PM system that does the basics and stays out of our way. Unfortunately it seems every time we want to make a change in Jira it ends up being complicated...

[Hernan Halabi - Elite IT Consulting Group]

hello @Robert Meador sorry for the delay on the response. It could be that we are checking the wrong workflow then else you wouldn't be able to move the issues. Please check if this is happening to all issue types or just a few of them. This could help us narrow the scope. If it's only a few issue types, share the workflow scheme configuration to make sure we checked the right workflow and if that was the case then we need to see other possible causes. 

Also to better understand what you are doing take a look to the following documentation.

https://support.atlassian.com/jira-software-cloud/docs/configure-columns

https://support.atlassian.com/jira-software-cloud/docs/use-your-kanban-backlog/

[Hernan Halabi - Elite IT Consulting Group]

What if you check for automation rules? Do you have any? Could you please add some screenshots of the board configuration (the status to columns mapping), the workflow and the configuration of the particular transition related to this?

Hopefully this will help the troubleshooting.

If the assignment happens before the status changes, most likely isn't an automation rule. I still think it could be the workflow but won't hurt to check it

[Robert Meador]

Per some of the above comments - I am our Jira admin (unless you mean someone at Atlassian), so I have to make whatever changes need to be made.

I looked at the Workflow and there was no step for Backlog (we have never used "Backlog" in workflows until I just started experimenting with this board). I added a step and reviewed the Post functions. There is no function that appears to change the user.

I could add a post function to "assign the user to the same user the task already is assigned to" but I'm not seeing an obvious choice for that.

Where else might this be happening?

I looked at the history and I see that the assignment change happens before the status change from Backlog to In Progress - if that helps any.

[Kasula Prithvi]

Hi @Robert Meador ,

You can alter the setting in post function of the workflow going from backlog to in progress.

[Hernan Halabi - Elite IT Consulting Group]

Hello @Robert Meador from the behavior you mention. It seems that there is a post function in the workflow that assigns the ticket to the user that does such transition. You Jira admin can change that within the workflow setting.  As @Florian states, there are other ways to achieve the same as well, maybe if you check the history tab can help to identify which one is being used if not the one I mentioned

[Florian]

Hi Robert. This is not standard behavior. It seem your administrator has set up some kind of automation. It is hard to tell how, as there are multiple ways to do it. By default Jira picks an assignee only when no assignee is set and when either the project or a component has a default assignee. Once an assignee is set Jira does not touch it.