Uploaded image for project: 'JBoss BPMS Platform'
  1. JBoss BPMS Platform
  2. RHBPMS-743

Moving group of elements to two swimlanes associates whole group with one swimlane

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Major Major
    • 6.2.0.GA
    • 6.2.0
    • jBPM Designer
    • None
    • All All

      +++ This bug was initially created as a clone of Bug #1283196 +++

      Description of problem:
      If you have group of elements out of swimlanes and you will try to move all of them in such a way as some of elements will be on one swimlane and rest of them on another all elements will be associate with one of them. (see attachment)

      Version-Release number of selected component (if applicable):
      6.2.CR1

      How reproducible:
      always

      Steps to Reproduce:
      1. Create Business Process with two swimlanes and some elements out of them
      2. Select all elements and move it in such a way as some of elements will be on first swimlane and rest of them on second one.

      Actual results:
      All elements will associate with one of swimlane

      Expected results:
      Elements on first swimlane will be associated with first swimlane, elements on second swimlane will be associated with second one.

      Additional info:
      All elements out of both swimlanes also will associate like there are on the swimlane.

      I guess it is related with bug 1262030

      — Additional comment from Kris Verlaenen on 2015-11-18 08:52:22 EST —

      Not sure if it would be expected that the second group of elements would end up in a different swimlane. I would expect all elements to be dropped in the same swimlane, although this might mean the swimlane might have to be expanded automatically so they visually fall into the swimlane as well.

      Joe, wdyt?

      — Additional comment from Joe Sniezek on 2015-11-18 13:42:29 EST —

      Hi Kris, I agree, when dragging a group of items into swimlanes, there should be a single destination for a single drag-drop interaction. So the current behavior is fine, it's just the visual presentation of the result which is problematic.

      I think your solution to expand the target swimlane automatically is the right approach. And it would be best if this action also shifted the position of the non-target swimlane, if possible, rather than having the two swimlanes overlap.

              rhn-support-tsurdilo Tihomir Surdilovic (Inactive)
              rhn-support-alazarot Alessandro Lazarotti
              Kirill Gaevskii Kirill Gaevskii
              Kirill Gaevskii Kirill Gaevskii
              Alessandro Lazarotti, Joe Sniezek (Inactive), Kirill Gaevskii, Kris Verlaenen, Tihomir Surdilovic (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: