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.
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.
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...)
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.
I agree, It would be extremely useful to change priorities directly on the board by moving cards between swimlines
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.
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.
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.
It looks like you're new here. Sign in or register to get started.
