What is the logic for two JQL driven swimlanes with the same results?

[angellmedici]

For example, I have two swimlanes driven by JQL:

1. Assignee = userA or Implementer = userA
2. Assignee = userB or Implementer = userB

If userB is assigned a ticket where userA is the implementer, then which swimlane is the ticket supposed to be in?  And why?

[Jack Brickey]

I believe it will be in the top most swimlane. I seem to recall a similar scenario in the past. The reason is that the boards work top down in those scenarios. 

simple to test and prove. 

[angellmedici]

I guess I knew what happens, but I wanted to know why and the intent of that logic.

Is there a way to take control over which swimlane it would go into?

[Jack Brickey]

I’m confused by the point of the question at this stage. Given an issue can appear only once on a board if the filters associated with swimlanes could result in more than one possible location then the application needs to resolve the conflict. It seems to be a natural choice to work top down given.

the only way to control it is thru your filters and the order of swimlanes. 

[Nic Brough -Adaptavist-]

Why it happens is simple - if you put an issue on a board twice, it's misrepresenting the information.  If you have 5 issues, but 7 "cards" on a board, that's wrong, and confusing to your users.  You should only have one card for each issue.

The logic for it landing in the first swimlane is human too - the first swimlane is at the top of the screen, and hence the first a human reads.  The board renders a card on the first time it sees it and drops duplicates thereafter.