Uploaded image for project: 'FishEye'
  1. FishEye
  2. FE-5751

No open reviews condition incorrectly checks Crucible's "Objectives" field for issue key

XMLWordPrintable

      Steps to repro:

      1. Setup JIRA and FeCru and applink the two of them
      2. Create an issue, and a review.
      3. Put a No open reviews condition in the workflow.
      4. Put the issue key in the objectives portion of the review.

      Expected

      You can transition the issue since this field in Crucible has nothing to do with the Development Panel and since the Crucible data isn't reflected in JIRA it should not have an effect on the workflow.

      Actual

      The transition is not available.

            [FE-5751] No open reviews condition incorrectly checks Crucible's "Objectives" field for issue key

            dkozinets added a comment -

            It will be delivered in Jira 9.13

            dkozinets added a comment - It will be delivered in Jira 9.13

            StMELF-Infrastruktur added a comment -

            Hi Marek,

            the same issue in our Atlassian product stack. The issue is present in the Linked issue field, but I can transition the state of the Jira issue. The open review seems to be ignored.

            StMELF-Infrastruktur added a comment - Hi Marek, the same issue in our Atlassian product stack. The issue is present in the Linked issue field, but I can transition the state of the Jira issue. The open review seems to be ignored.

            Marek Parfianowicz added a comment - - edited

            Hi Darly,

            Did you linked a review with the issue (Review page > Edit Details > Linked issue)?
            Or is the issue key just mentioned in the 'Objectives' field?

            I believe the latter works fine, so I disagree that this is a blocker.

            Also, can you confirm that you have both Fisheye+Crucible license? I'm asking, because there's a bug/improvement request related with the way how Fisheye&Crucible REST API deals with Jira's dev panel (see CRUC-8196) and also when there are no repositories defined (see CRUC-8195).

            Marek Parfianowicz added a comment - - edited Hi Darly, Did you linked a review with the issue (Review page > Edit Details > Linked issue)? Or is the issue key just mentioned in the 'Objectives' field? I believe the latter works fine, so I disagree that this is a blocker. Also, can you confirm that you have both Fisheye+Crucible license? I'm asking, because there's a bug/improvement request related with the way how Fisheye&Crucible REST API deals with Jira's dev panel (see CRUC-8196 ) and also when there are no repositories defined (see CRUC-8195 ).

            Darly Senecal-Baptiste added a comment -

            Hi,

            It's been almost 2 years since the last update of this bug and I believe this bug priority must be a BLOCKER. Here's why:

            1. We are enforcing code work and code review and no JIRA ticket with code changes must continue for closing when the related code review is closed for that change.
            2. What I am reading from the support team and from this ticket is that Fisheye/Crucible workflow conditions are skipped when JIRA users with Fisheye account are not logged in Fisheye. What about those JIRA users who don't have Fisheye account? Are code enforcement not valid for them? Or they are able to break such enforcement regardless of the transition conditions explicitly mentioned.
            3. My current Application Link Type is OAuth with impersonation

            Please, fix this as soon as possible. Otherwise,non-Fisheye JIRA users will discover this hole and exploit it and me as an Atlassian Admin, won't be able to mitigate.

            Darly Senecal-Baptiste added a comment - Hi, It's been almost 2 years since the last update of this bug and I believe this bug priority must be a BLOCKER . Here's why: We are enforcing code work and code review and no JIRA ticket with code changes must continue for closing when the related code review is closed for that change. What I am reading from the support team and from this ticket is that Fisheye/Crucible workflow conditions are skipped when JIRA users with Fisheye account are not logged in Fisheye. What about those JIRA users who don't have Fisheye account? Are code enforcement not valid for them? Or they are able to break such enforcement regardless of the transition conditions explicitly mentioned. My current Application Link Type is OAuth with impersonation Please, fix this as soon as possible. Otherwise,non-Fisheye JIRA users will discover this hole and exploit it and me as an Atlassian Admin, won't be able to mitigate.

            Lukasz Pater added a comment -

            Seems to use the search-v1 API, and pass the issueKey as the term. The query there seems to include the objective in the search, at a glance. Potentially something gets broken along the way - needs verification.

            Lukasz Pater added a comment - Seems to use the search-v1 API, and pass the issueKey as the term. The query there seems to include the objective in the search, at a glance. Potentially something gets broken along the way - needs verification.

              dkozinets@atlassian.com dkozinets
              ohernandez@atlassian.com Oswaldo Hernandez (Inactive)
              Affected customers:
              5 This affects my team
              Watchers:
              10 Start watching this issue

                Created:
                Updated:
                Resolved:

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - Not Specified
                  Not Specified
                  Logged:
                  Time Spent - 2h 44m
                  2h 44m