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

Allow Request Participants role / group to be added to Issue Security Schemes and Project Permissions

    • 189
    • 8
    • We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Jira Service Management Data Center. Using Jira Service Management Cloud? See the corresponding suggestion.

      Summary

      When using issue security in a Service Desk project, Request Participants are unable to view the issue at all

      Environment

      Cloud
      Server

      Steps to Reproduce

      1. Create a new Service Desk project
      2. Create a new Issue Security Scheme
      3. Create a new ticket and assign it the Issue Security level in your Issue Security Scheme
      4. Add a second user as a Request Participant on the ticket that is not part of the Issue Security Scheme
      5. That user should receive an email
      6. Click on the link in the email

      Expected Results

      The user should be able to view the ticket they are a Request Participant on

      Actual Results

      The user can only see the main portal and not the issue he/she has been added as a Request Participant on

      Notes

      In this use case, it would be helpful if there was a way to add a Request Participants group / role to the Issue Security Scheme so that when people are invited to partake in a ticket, they are able to see the ticket within the Service Desk project.

      The same issue applies to project permissions, as the field "Request Participants" can't be associated to any project permission.

            [JSDSERVER-3948] Allow Request Participants role / group to be added to Issue Security Schemes and Project Permissions

            Unbelievable. 

            Mario Fanck added a comment - Unbelievable. 

            To Sean Young's point, this is a solution when viewing the issue from the customer portal, but the same user cannot view it from the Service Desk as an semi-agent. 

            Short of adding a hidden custom field which is copied from Request Participants and/or Watchers, I don't see a way to conditionally include users on the service desk side. Open to other suggestions. 

            Ben (Bork 2: The Borkening) added a comment - To Sean Young's point, this is a solution when viewing the issue from the customer portal, but the same user cannot view it from the Service Desk as an semi-agent.  Short of adding a hidden custom field which is copied from Request Participants and/or Watchers, I don't see a way to conditionally include users on the service desk side. Open to other suggestions. 

            Sean Young added a comment - - edited

            My testing adding the Service Project Customer - Portal Access role solves the problem.  Unless I'm missing something? 

            My test user who was marked as a request participant was able to see the ticket in the portal.  My other user was not unless he was added to the ticket.

            Sean Young added a comment - - edited My testing adding the Service Project Customer - Portal Access role solves the problem.  Unless I'm missing something?  My test user who was marked as a request participant was able to see the ticket in the portal.  My other user was not unless he was added to the ticket.

            Has anyone tested adding service desk customers to an issue security security level to see if it supersedes the standard permissions of the issue?  That may be an alternative solution.

            Sean Young added a comment - Has anyone tested adding service desk customers to an issue security security level to see if it supersedes the standard permissions of the issue?  That may be an alternative solution.

            Sean Ho added a comment -

            Bump

            Sean Ho added a comment - Bump

            Bump. 

            Vincent Chen added a comment - Bump. 

            Knock Knock. This would be a rather useful function and its confusing why it isn't already?

            Theodore Lotz added a comment - Knock Knock. This would be a rather useful function and its confusing why it isn't already?

            Are you serious?

            How can this not be implemented within 6.5 years?

            What are you charging x times more money for now - for your great response times?

             

            Michael Lehofer added a comment - Are you serious? How can this not be implemented within 6.5 years? What are you charging x times more money for now - for your great response times?  

            This is really needed feature. We have used "Request participants" for a long time in our Service Management project and can't start using Issue Security in an easy way because of that. I could make another field and copy values from "Request participants" with automation but it is annoying. It seems that it could be an easy thing for Atlassian to add "Request participants" field to issue security. I wonder why it is still not considered. 

            Kerli Loopman added a comment - This is really needed feature. We have used "Request participants" for a long time in our Service Management project and can't start using Issue Security in an easy way because of that. I could make another field and copy values from "Request participants" with automation but it is annoying. It seems that it could be an easy thing for Atlassian to add "Request participants" field to issue security. I wonder why it is still not considered. 

            Manuel added a comment -

            6 years is nothing in "Atlassian years" for such easy features & functions There are many older tickets with anoying missung functions.

            Manuel added a comment - 6 years is nothing in "Atlassian years" for such easy features & functions There are many older tickets with anoying missung functions.

              Unassigned Unassigned
              mlavender mlavender (Inactive)
              Votes:
              349 Vote for this issue
              Watchers:
              165 Start watching this issue

                Created:
                Updated: