Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-91247

Expanded swimlane is collapsed and reordered upon including additional issue based on a quick filter

      Issue Summary

      If a swimlane is expanded while viewing an active sprint board and an additional quick filter is chosen to include more issues, then the expanded swimlane gets collapsed and reordered. Another swimlane takes its place and gets expanded.
      This behaviour causes confusion to the users.

      Steps to Reproduce

      1. Create a Jira Scrum Classic project
      2. Set swimlanes to Stories in the board settings
      3. In the active sprint board view, collapse all swimlanes and select a assignee filter (Example: User1)
      4. Expand one swimlanes from the list of stories. (Example: 4th swimlane in the list)
      5. Now click on an addition assignee filter (Example: User1 and User2)

      Expected Results

      The expanded swimlane should stay expanded in the same position (4th position as per above steps).

      Actual Results

      The expanded swimlane is collapsed and reordered in the list of stories. Another story gets expanded and takes the position of the previously expanded swimlane.

      Workaround

      Currently there is no known workaround for this behavior. A workaround will be added here when available

            [JRACLOUD-91247] Expanded swimlane is collapsed and reordered upon including additional issue based on a quick filter

            Dylan added a comment -

            Hi all,

            Thank you for raising this bug and bringing it to our attention.

            Within our company roadmap and work capacity, we try to address or review each bug request but admit that not each one will be resolved.

            To continue the culture of being honest and open, we are closing this bug to focus on our upcoming roadmap for all Jira users.

            Dylan added a comment - Hi all, Thank you for raising this bug and bringing it to our attention. Within our company roadmap and work capacity, we try to address or review each bug request but admit that not each one will be resolved. To continue the culture of being honest and open, we are closing this bug to focus on our upcoming roadmap for all Jira users.

            Gomes, Alex added a comment - - edited

            After creating the support ticket that led to this bug item, I was asked to share how this affects my team.

            In our work, when we define an activity it consists of two separate stories: we call them the Implementation (I) and the Review (R) stories. This division helps us track the work for both the person implementing a change and the person reviewing that change. Because the review work is also crucial and needs to be given the proper time allocation (reviews take valuable time too). When we do this separation, we assign one team member to each and we keep the R story merely for status and time tracking: for example, if the I person has tasks A1 (In peer review) and B1 (In progress) then the R person has tasks A2 (To do) and B2 (Blocked).

            Considering this workflow, we keep all comments and attachments in the I story for centralization. During our daily activities, sometimes we want to apply the filter to see our own work and then we want to add the person we know has the matching I or R story to see the status and whether there are any changes. So we frequently add and remove filters to see the stories tied to our own, hence keeping the stories collapsed or expanded while changing filters becomes essential to maintain our focus.

            Gomes, Alex added a comment - - edited After creating the support ticket that led to this bug item, I was asked to share how this affects my team. In our work, when we define an activity it consists of two separate stories: we call them the Implementation (I) and the Review (R) stories. This division helps us track the work for both the person implementing a change and the person reviewing that change. Because the review work is also crucial and needs to be given the proper time allocation (reviews take valuable time too). When we do this separation, we assign one team member to each and we keep the R story merely for status and time tracking: for example, if the I person has tasks A1 (In peer review) and B1 (In progress) then the R person has tasks A2 (To do) and B2 (Blocked). Considering this workflow, we keep all comments and attachments in the I story for centralization. During our daily activities, sometimes we want to apply the filter to see our own work and then we want to add the person we know has the matching I or R story to see the status and whether there are any changes. So we frequently add and remove filters to see the stories tied to our own, hence keeping the stories collapsed or expanded while changing filters becomes essential to maintain our focus.

              Unassigned Unassigned
              b678926ca497 Bopanna
              Affected customers:
              0 This affects my team
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: