Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-4304

Approvers are copied over implicitly from the original issue when using the 'Create linked issue' functionality

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Low Low
    • None
    • 3.2.1
    • Approvals

      Summary

      When an issue is created in JSD 3.2.1 using the 'Create Linked Issue' function, it will not show up in the approver's Approvals list in the Customer Portal, even though it is in an Awaiting Approval status.

      Environment

      • JIRA Service Desk 3.2.1

      Steps to Reproduce

      1. Create an issue as a customer from the Customer Portal.
      2. Add an Approver to that issue - it will show up on that approver's Approvals list in the Customer Portal.
      3. Create a new issue using 'Create Linked Issue'.
      4. Verify that that issue is in the 'Awaiting Approval' status, and has the same user added in step 2 as an Approver.

      Expected Results

      The new issue will show up on that approver's Approvals list in the Customer Portal.

      Actual Results

      No new issues show up on that approver's Approvals list in the Customer Portal.

          Form Name

            [JSDSERVER-4304] Approvers are copied over implicitly from the original issue when using the 'Create linked issue' functionality

            Hi and thanks for your reply and info. I'm concerned about closing this bug without any other defect in place to track this. I know JSD-1809 and JSD-1055 exist, but they are both only enhancement requests. My issue is a bug. The way the system currently works, an issue can get stuck. This is a bug and I believe needs to be treated as such. Please advise. Thanks!

            Alan Reynolds added a comment - Hi and thanks for your reply and info. I'm concerned about closing this bug without any other defect in place to track this. I know JSD-1809 and JSD-1055 exist, but they are both only enhancement requests. My issue is a bug. The way the system currently works, an issue can get stuck. This is a bug and I believe needs to be treated as such. Please advise. Thanks!

            Nhi Nguyen (Inactive) added a comment - - edited

            Hi alan.reynolds302164151,

            Thanks for clarifying your scenario! And I'm glad that the workaround with the automation can help you out with your situation.

            I agree that the experience could be improved. I'll forward this to a PM discussion and hopefully we can sort out this problem in JSD-1809 and JSD-1055. In the meantime, I will close this bug.

            Thank you!
            JIRA Service Desk team.

            Nhi Nguyen (Inactive) added a comment - - edited Hi alan.reynolds302164151 , Thanks for clarifying your scenario! And I'm glad that the workaround with the automation can help you out with your situation. I agree that the experience could be improved. I'll forward this to a PM discussion and hopefully we can sort out this problem in JSD-1809 and JSD-1055 . In the meantime, I will close this bug. Thank you! JIRA Service Desk team.

            Alan Reynolds added a comment - - edited

            Hi,

            Thanks for your reply. I understand the issue from a technical perspective. However, it is unacceptable to have approvals implemented for JIRA Service Desk which do not work if the issue is not submitted via the Customer Portal and the issue doesn't have manual human interaction to set the Customer Request Type.

            The scenario you've outlined works fine for Service Requests which need approvals, I suppose. All Service Requests should (at least conceivably) come from the Customer Portal. These should be requests which are entered by end users or by support staff on behalf of the end user.

            Unfortunately, in an enterprise ITIL environment, Change Requests are not often exposed through the Customer Portal, as true end users are not the ones to submit Infrastructure Change Requests. These requests come most often from support staff. This can be a support staff person clicking the 'Create' button on the agent interface to submit a new Change Request or, likely more often, clicking the 'Create linked issue' option from an Incident or Problem issue which now needs to have a Change implemented in order to restore service and/or prevent future outages.

            Support staff who work in the agent interface cannot be expected to only submit Change Requests via the Customer Portal. That expectation is too limiting for true enterprise customers. Support staff need to be able to work in the easiest way possible, which includes being able to submit a Change Request (which could have approvals) from the 'Create' button and/or the 'Create linked issue' option.

            I have implemented the workaround you suggested (creating a post function or automation rule to set the Customer Request Type field) in my test environment and it does get me past this bug. However, in a production environment an admin would have to create and maintain potentially dozens of post functions/automation rules to handle each and every scenario where an issue which has approvals can be created in order to prevent issues from getting 'stuck' in the approval phase without a way to approve/reject.

            Thanks,
            Alan

            Alan Reynolds added a comment - - edited Hi, Thanks for your reply. I understand the issue from a technical perspective. However, it is unacceptable to have approvals implemented for JIRA Service Desk which do not work if the issue is not submitted via the Customer Portal and the issue doesn't have manual human interaction to set the Customer Request Type. The scenario you've outlined works fine for Service Requests which need approvals, I suppose. All Service Requests should (at least conceivably) come from the Customer Portal. These should be requests which are entered by end users or by support staff on behalf of the end user. Unfortunately, in an enterprise ITIL environment, Change Requests are not often exposed through the Customer Portal, as true end users are not the ones to submit Infrastructure Change Requests. These requests come most often from support staff. This can be a support staff person clicking the 'Create' button on the agent interface to submit a new Change Request or, likely more often, clicking the 'Create linked issue' option from an Incident or Problem issue which now needs to have a Change implemented in order to restore service and/or prevent future outages. Support staff who work in the agent interface cannot be expected to only submit Change Requests via the Customer Portal. That expectation is too limiting for true enterprise customers. Support staff need to be able to work in the easiest way possible, which includes being able to submit a Change Request (which could have approvals) from the 'Create' button and/or the 'Create linked issue' option. I have implemented the workaround you suggested (creating a post function or automation rule to set the Customer Request Type field) in my test environment and it does get me past this bug. However, in a production environment an admin would have to create and maintain potentially dozens of post functions/automation rules to handle each and every scenario where an issue which has approvals can be created in order to prevent issues from getting 'stuck' in the approval phase without a way to approve/reject. Thanks, Alan

            Nhi Nguyen (Inactive) added a comment - - edited

            Hi alan.reynolds302164151,

            The problem here is that the issue created by 'Create linked issue' dialog will not have 'Request type' value (its Service Desk request type is No match. Without SD request type value, the request can not show up in the Approvals request list in the Customer portal. (The same problem when we create an issue from JIRA, not from the customer portal, the request will not show up in the My requests page in the Customer portal because of lacking SD request type).

            Could we suggest you to manually update the Service Desk request type field of that ticket as a workaround?

            There are some suggestions which would fix this problem, please watch them: JSD-1809, JSD-1055.

            Please let us know if you have any further concerns.

            Thanks,
            JIRA Service Desk team.

            Nhi Nguyen (Inactive) added a comment - - edited Hi alan.reynolds302164151 , The problem here is that the issue created by 'Create linked issue' dialog will not have 'Request type' value (its Service Desk request type is No match . Without SD request type value, the request can not show up in the Approvals request list in the Customer portal. (The same problem when we create an issue from JIRA, not from the customer portal, the request will not show up in the My requests page in the Customer portal because of lacking SD request type). Could we suggest you to manually update the Service Desk request type field of that ticket as a workaround? There are some suggestions which would fix this problem, please watch them: JSD-1809 , JSD-1055 . Please let us know if you have any further concerns. Thanks, JIRA Service Desk team.

            This bug causes an issue to get stuck. If approvals are defined as the first step for a given workflow and that workflow is attached to the issue type being created by the 'Create linked issue', then the resulting issue is created but immediately stuck as it is awaiting approval with no way for the approver to approve. This needs to be addressed asap. We cannot use JSD 3.2 approvals until this defect has been resolved. Thanks!

            Alan Reynolds added a comment - This bug causes an issue to get stuck. If approvals are defined as the first step for a given workflow and that workflow is attached to the issue type being created by the 'Create linked issue', then the resulting issue is created but immediately stuck as it is awaiting approval with no way for the approver to approve. This needs to be addressed asap. We cannot use JSD 3.2 approvals until this defect has been resolved. Thanks!

              Unassigned Unassigned
              agallien@atlassian.com Alex Gallien
              Affected customers:
              5 This affects my team
              Watchers:
              7 Start watching this issue

                Created:
                Updated: