Uploaded image for project: 'Jira Service Management Cloud'
  1. Jira Service Management Cloud
  2. JSDCLOUD-11422

Approvers lose access after approval/Remaining approvers lose access when ticket has crossed the needing approval stage

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • Approvals
    • None
    • 208
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Issue Summary

      Initially raised as - Remaining approvers lose access when the ticket is approved or rejected - when only one approval is required.

      However the behavior is observed when there are multiple approvers and an approver who has previously approved wants to go back and review the ticket again.

      So this happens in the following scenarios:

      1. When more than 1 approver is added to the ticket, but only one approval is required and ticket is approved, the remaining approvers lose access to the ticket and they see a lock screen with the error message - No access. You do not have permission to view this ticket.
      2. When the ticket has moved on from the needing approval stage, the lock screen is displayed when a user added as approver and who has previously approved the ticket,  clicks on the ticket from their email or from the portal approvals screen.

      Steps to Reproduce

      1. Add at least 2 approvers to a ticket. These are portal only customers who can view the ticket on the portal. They are not added to the ticket as request participants. They are only added as approvers.
      2. Once the ticket transitions to a state where approval is required, both the approvers see this ticket in their queue on the portal.
      3. Approver 1 approves (or rejects) the ticket. When Approver 2 clicks the link from either the email or from the Approvals list - the error screen with a lock is displayed with the error message -  No access. You do not have permission to view this ticket.
      4. Note - The ticket moves to the 'Approvals History' list in the portal for the Approver 2 as well once the Approver 1 has approved the ticket. Also the Approver 2 can also click the link to approve from the email received indicating that a ticket awaits their approval.
      5. If approver 1 who approved the ticket tries to access the ticket again, the same lock screen is displayed.

      Expected Results

      2 options:

      1) Present a better user friendly error message informing the user that the ticket has already been approved (or rejected) and hence is not available to them for approval (or)

      2) Allow the remaining approvers access to view the ticket without the permission to approve since it has already been approved or rejected. This allows them to see who has approved.

      Actual Results

      1. When Approver 2 clicks the link from either the email or from the Approvals list - the error screen with a lock is displayed with the error message -  No access. You do not have permission to view this ticket.
      2. Note - The ticket moves to the 'Approvals History' list in the portal for the Approver 2 as well once the Approver 1 has approved the ticket. Also the Approver 2 can also click the link to approve from the email received indicating that a ticket awaits their approval.
      3. If approver 1 who approved the ticket tries to access the ticket again, the same lock screen is displayed.

      Workaround:

            [JSDCLOUD-11422] Approvers lose access after approval/Remaining approvers lose access when ticket has crossed the needing approval stage

            Sha Aquino added a comment -

            Hi,

            This is a necessary function and hoping this can be resolved.

            Thanks

            Sha Aquino added a comment - Hi, This is a necessary function and hoping this can be resolved. Thanks

            So disappointing that such a useful feature does not run smoothly. Users (approvers) are irritated and the overall image of our service desks suffers.

            Dorothee Rothfuss-Bastian added a comment - So disappointing that such a useful feature does not run smoothly. Users (approvers) are irritated and the overall image of our service desks suffers.

            Charles added a comment -

            This needs to be address it is simply bad UX. Our users get confused and report this as bug frequently. We should at least get a message saying your approval is not required anymore or anything better than an error. This cause also does not help get secured environment as in case we have multiple approvers and only 1 is required, it does not let the other challenge or get back to us if they see an issue with what the other has approved. We do have cases were there is a primary approver and a backup approver. Typically the primary approver approves most request and have a better understanding of the context etc and might happen he challenges the backup approver on some approval provided when he/she returns etc. Not viewing approved request after the fact is a problem.  Adding the approvers as "participant" result in spams so it is not an acceptable workaround.

            Charles added a comment - This needs to be address it is simply bad UX. Our users get confused and report this as bug frequently. We should at least get a message saying your approval is not required anymore or anything better than an error. This cause also does not help get secured environment as in case we have multiple approvers and only 1 is required, it does not let the other challenge or get back to us if they see an issue with what the other has approved. We do have cases were there is a primary approver and a backup approver. Typically the primary approver approves most request and have a better understanding of the context etc and might happen he challenges the backup approver on some approval provided when he/she returns etc. Not viewing approved request after the fact is a problem.  Adding the approvers as "participant" result in spams so it is not an acceptable workaround.

            Kaneka Ky added a comment - - edited

            Please correct this as soon as possible. It is very confusing for our customers. We have received multiple complaints. Not sure why this functionality has never been taken into consideration when you enabled the approval/deny button through email. 

            Kaneka Ky added a comment - - edited Please correct this as soon as possible. It is very confusing for our customers. We have received multiple complaints. Not sure why this functionality has never been taken into consideration when you enabled the approval/deny button through email. 

            Hello,

            This needs to be corrected please.

            Thanks.

            Imane ASSOUD added a comment - Hello, This needs to be corrected please. Thanks.

            This bug significantly degrades the user experience.

            As a workaround, a workaround is provided to update Request participants with an automated rule.
            However, there are multiple approver fields and it is not possible to detect the creation of a new field. Therefore, it is difficult to monitor all approvers as triggers and is not a complete workaround.

            Masayuki Abe added a comment - This bug significantly degrades the user experience. As a workaround, a workaround is provided to update Request participants with an automated rule. However, there are multiple approver fields and it is not possible to detect the creation of a new field. Therefore, it is difficult to monitor all approvers as triggers and is not a complete workaround.

            We need this fixed!!

            Terrence Villaverde added a comment - We need this fixed!!

            Indeed this seems like a bug; it does not make sense for a user to lose access to a request because it has been approved by someone else.  My user base is not happy with this!

            Victor Santacruz added a comment - Indeed this seems like a bug; it does not make sense for a user to lose access to a request because it has been approved by someone else.  My user base is not happy with this!

            This is really critical bug when we use the customer approval function. I can't beleive that approver lose the ticket access if another person approved. And I totally agree that current workaround is not operational one. Request participants could be huge number if we have some steps of approval and multiple approvers for each step. Please fix this bug as soon as possible!

            片岡 紗希 added a comment - This is really critical bug when we use the customer approval function. I can't beleive that approver lose the ticket access if another person approved. And I totally agree that current workaround is not operational one. Request participants could be huge number if we have some steps of approval and multiple approvers for each step. Please fix this bug as soon as possible!

            +1 please fix this basic topic!

            Jan Heitmann added a comment - +1 please fix this basic topic!

              a620038e6229 Jehan Gonsalkorale
              d311beede795 Bhaargavi Natarajan
              Votes:
              115 Vote for this issue
              Watchers:
              92 Start watching this issue

                Created:
                Updated: