I can't move issue between swimlanes

[Nic Brough -Adaptavist- · Accepted solution]

Yes, swimlanes are for categorisation - there's no way JIRA could handle a move like:

From:  due date < -7d

To:  due date > -7d

How would it know what to do with that?  What should the due date be changed to?  There's no logical way dragging across swimlanes can actually be made to work like that.

[Stefano Spada]

My bad. I said swimlane I meant columns (workflow states) in a sprint. Even if the workflow allows to switch between a column and the other and I have schedule and move permissions I still cannot drag the story from one column to another. I'm sure it's a trivial issue due to some misconfiguration, I just wanted to check if anyone had already found a solution. The manuals are not that self explanatory.

[Nic Brough -Adaptavist-]

Ah, ok, that makes more sense! The columns are representations of status (or sets of status) from the workflow. To move from one column to another, you need a) A workflow transition between the status in the source and target columns b) The workflow transition can have conditions on it which need to be met to allow the transition. I suspect it's conditions. You mention that you have move and schedule permission, but I doubt those have been used in the conditions in your workflow (because schedule gives you "set due date" and "ranking", and move gives you the right to move issues between projects and issue types - none of those are changes of status. Although an inventive admin *might* have used them) You need to check the workflow to see what the conditions are and make sure you match them. It's quite common to see "must be in role of a developer" and/or "must be in the role of a user" Finally, you may just be missing the permission "transition issues" (actually, do that first, it's a new feature so I forgot it until near the end of my typing...)

[Eduardo Piombino]

It isn't exactly me who missed the point.

You are talking about a general, valid for all cases, swimlane switch, while I was clearly not, since such a switch, as you pointed out, is not theoretically possible. However, I it could still be very useful, while still technically possible, to consider lanes as switchable or not, depending on their conditions. Simple lane conditions such as a single field matching a single value, or an anded chain of such conditions, could safely be considered switchable. No one ever suggested covering inequity conditions like due date < -7d, or logical conditions like "priority = Low OR reporter = Peter".

Jira already has a very similar mechanism: state transition by column dragging. "Conceptually", it works exactly like the above idea. The condition for each column is State = ToDo, State = In Progress, State = In Review, etc. If you pick an issue an drag it to a column, Jira knows it has to change its state to the state defined by the target column (besides probably a ton of other checks and stuff). For swimlanes, the resulting action could easily be determined by a more generic approach, based on the target column/swimlane filter and its complexity. If the target's swimlane condition does not meet the "switchable lane" criteria stated above (simple condition or anded chain of conditions), then the drag could simply be rejected/ignored. But for all the cases where the target's condition does meet it, the action to be taken would be quite straightforward and could be extracted from the filter itself (set field to matched value of the filter, or set series of anded fields to matched values), and swimlane dragging could be theoretically implemented for such cases.

Our company, and I'd bet we are not the only ones, would greatly benefit from such a functionality, since our lanes are defined exactly in that way: 5 lanes: priority = Lowest, priority = Low, priority = Medium, priority = High and priority = Highest. Horizontal transitions are currently possible, while vertical aren't. It's sad, because we see no real technical impediments for implementing such a transition. It's pretty clear for us what field it is that we want to change when moving it up or down on the priority list.

Now, if there weren't interest in implementing it or not, or if developers would like to focus on some more pressing issues, it would be totally understandable but a total different matter.

[Nic Brough -Adaptavist-]

Whilst it wasn't directed at you, you have still missed the point. Swimlane moves are complicated to implement because the code has to understand how a swimlane is set up, and a swimlane could be anything. Column moves are not complex because "look at status, and tell me which column it is in" (rather than "well, it's Tuesday, and my socks are purple" The other part of the point was that there are vast number of other things that are far more useful than swimlane changes. So Atlassian are looking at them first.

[Eduardo Piombino]

I fail to see how swimlane moves being more complicated to implement because the code has to understand how a swimlane is set up, and that a swimlane can be anything, or that you have a backlog makes me miss any point. In any case, this is my last post here, so have a good life.

[Nic Brough -Adaptavist-]

<sigh> Think about it. Swimlane 1 = "all blue issues", Swimlane 2 = "component = Fred". What do you do when you move an issue between them? There's two options, both correct, and hence arguable about which one you should do, and you've got to code for that. Now what if swimlanes are more complex, like "colour = blue and component = fred"? It gets exponentially more complex. So, it's not simple, and that's why it has not been done.

[Eduardo Piombino]

Jira cannot possibly determine what to do for all situations, but for simple queries it can do it.
If you have a swimlane for "priority = High" and other for "priority = Low", Jira could easily consider the lane as "switchable", because the only thing that it would need to do is to set the priority to Low or High depending on the swimlane. It could even detect ANDed conditions, like "priority = Low and assignee = Peter". Its obvious that for an issue to be there it has to meet both conditions, and it's obvious for Jira what to do (set priority to Low and assignee to Peter). Different are the cases where conditions are ORed or lists of values are used, but for many, many cases, this could be achieved (very) easily.

Regards.

[Sebastian Bor]

I agree, It would be extremely useful to change priorities directly on the board by moving cards between swimlines

[Nic Brough -Adaptavist-]

And how would you code for "it's Tuesday and I had a bagel for lunch"? Eduardo completely missed the original point, and I suspect you have as well - it's simply too complicated to even start coding for moving swimlanes when a swimlane could be defined by almost any rule. I agree that it would be *useful*, but the code required provides far too little ROW - there's probably 7,000 issues in JIRA's tracker that I'd prefer to be fixed before this.

[Sebastian Bor]

It doesn't have to support every single possible combination. The same way you can't always move cards between columns. Simply if you can move the card make it possible to drag it and if not then not.

[Nic Brough -Adaptavist-]

Cue all the rest of the questions about when you can and can't do it. And the columns can/can't drag is a direct function of the workflow, a totally different proposition.

[Greg Grater]

Eduardo is spot on.   Nic, this isn't complicated.

When a card is dragged between columns, an "Action" executes to set the Status to the targeted value.   It so happens that the Action is hard coded to 'status'.  This is a huge miss by the Atlassian product owners.

Why the hard coded variable?   Why couldn't (under board configuration), the user define the variable and the value instead of just the value?  Instead of listing a set of statuses to select per column on your board, you should be able to create Target Actions that contain a set of user defined variable assignments.  For instance:

"To Do - High" Target Action might look like:

    Status = To Do

    Priority = High

"To Do - Medium" Target Action might look like:

    Status = To Do

    Priority = Low

"Bagels" Target Action might look like:

    Lunch = Bagels

Extending the "Target Actions" concept to swim lanes would work just like columns.  Each swim lane not only defines it's JQL Filter but also, a list of target actions.   In Nic's example:

A "Tuesday" Target Action might look like:

    DayOfWeek = Tuesday

IMO, JIRA has handcuffed its users.   It assumes that Boards are only good for Status changes.   In doing so, Atlassian has made the boards all but useless when comes to Card management.

Boards should be simply a spread sheet of cards.   Swim Lanes provide a grouping of rows of cards based on some user defined qualifiers (JQL).   Columns should do the same (instead of being hard coded to status.  Throw user defined Target Actions on each Column and each Swim Lane, and Atlassian would greatly improve their produc

[Nic Brough -Adaptavist-]

Er, you say "this is not complicated" and immediately describe a complicated scenario that fails and hence proves you wrong.  (And you missed the point that swimlanes can be too complex to code for - what change would you make if moving between a swimlane of "colour = red or lunch = bagel" and "colour = blue or lunch = sandwich"?  That simple use case proves Eduardo wrong)

You also totally miss the point of the Agile use of boards, which are supposed to group issues into columns based on their position in the process flow (i.e. status), and we are talking about the boards here.

If you want to do something totally different (and hence irrelevant here), that's absolutely fine.  Your usage and process works for you, and if I came to you as a consultant and looked at the way you worked, it sounds like there's a good chance I'd be saying "don't bother with tools that claim to be Agile - you're not working that way" rather than "you're using it wrong".

I'd also recommend a look at Comala's Canvas product...

[Mike W-M]

I've just spent 15 minutes wondering why, having created the default example kanban project, I can't drag between the Expedite and the Everything Else swimlanes.   (And having found out the swim-lane distinction is based solely on the priority, I'm still wondering why changing the priority doesn't cause the card to immediately move.)

'Fraid I don't know JIRA functionality very well (and I might well stop my investigation here because I can't simply throw this at some of my colleagues and say, "See, you just drag the cards around") but it seems fairly obvious that when you define a swimlane, if you optionally allow the definition of a property setting action (like "set priority to Highest") then that's all of the simple cases catered for, with no detriment to the non-simple cases.

(Hmm.  But perhaps if I simply don't use swimlanes, it'll be straightforward enough for my use...)

[Nic Brough -Adaptavist-]

That would be a way around it, but the code would have to be done "hard", it wouldn't be a case of "a tick box to configure it".  You can't code for every case, but you could do it for the standard fixed cases.   I wouldn't give the users any options at all.  If they select the pre-configured "swimlane by priority" case, then the code behind the drag-to-new-swimlane is a clear cut "change priority".  Same with assignee and several others.  You then leave the "swimlane based on JQL" alone, without the ability to drag.

[Jan Reichert]

We are using Jira since many years, but are just starting with boards. The thing I noticed in the first five minutes is that moving issues between swimlanes does not work. 

I googled it and found thousands of requests for this feature since about 2012! 

I read the arguments from Atlassian and understand them, but still I do not understand why Atlassian is so customer-unfriendly about this. 

Nic here defined a possible solution and I think this would solve 90% of the peoples issues. Most of the time I use swimlanes for Epics, Assignees or similar. Here moving between swimlanes could easily be done. 

So please Atlassian - reconsider. Think about your customers!