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

Prevent issues from being created through JIRA Channel using Create Issue function

    • 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 Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.

      As an administrator I want to force ALL users to use the customer portal instead of "Create Issue" in the JIRA interface. This includes agents, customers who are JIRA users, and customers who are not JIRA users.

      • Currently, users are able to create issues in the Service Desk project using this "Create Issue" button. This allows them to bypass the Customer Portal and the request types that I have defined. Issues created like this do not use the form I created and do not show in the portal.

      Currently JIRA Service Desk requires the Create Issue permission for two project roles, Service Desk Team and Administrators. Having this permission allows agents to create issues through the JIRA channel using the Create Issue function in JIRA.

      • If these permissions are not present an error will appear like discussed here
      • Removing these permissions does not prevent agents from creating issues in the portal or through the email channel.

      As an admin, I may need to give some users Create Issue permission but do not want these users to be able to create issues in the Service Desk project using the Create Issue function in JIRA. I need to be able to give some users this permission so that issues can be created using, for example:

      • API
      • Issue collectors
      • Regular JIRA mail handlers
      • Add-ons

          Form Name

            [JSDSERVER-1736] Prevent issues from being created through JIRA Channel using Create Issue function

            When adjusting the permissions settings from the default to remove roles / groups / users from the standard Create Issue permission, these warnings will be presented to all administrators and require dismissing once. 

            This method also means you have to, as a minimum, have 1 request type per issue type in the JSD project, visible to the customer portal. 

            As default, without further customization available from marketplace Apps, all customers would then see all request types. 

            This can be problematic when creating an ITIL Service Desk, as you would not normally expose Problems or Changes directly to the customer.

            We have created a plugin with this specific use case in mind - check it out: https://marketplace.atlassian.com/apps/1220259/pro-create-for-jira-service-desk?hosting=server&tab=overview

            Richard Crampton added a comment - When adjusting the permissions settings from the default to remove roles / groups / users from the standard Create Issue permission, these warnings will be presented to all administrators and require dismissing once.  This method also means you have to, as a minimum, have 1 request type per issue type in the JSD project, visible to the customer portal.  As default, without further customization available from marketplace Apps, all customers would then see all request types.  This can be problematic when creating an ITIL Service Desk, as you would not normally expose Problems or Changes directly to the customer. We have created a plugin with this specific use case in mind - check it out:  https://marketplace.atlassian.com/apps/1220259/pro-create-for-jira-service-desk?hosting=server&tab=overview

            Yes, since JSD 2.5.2 it is now possible to dismiss the permission scheme warnings (JSD-1969) that you would currently see from adjusting the default scheme.

            Matthew McMahon (Inactive) added a comment - Yes, since JSD 2.5.2 it is now possible to dismiss the permission scheme warnings ( JSD-1969 ) that you would currently see from adjusting the default scheme.

            Per channel permission configuration

            Per-channel permission configuration in JIRA isn't supported. Web application / REST api access for example isn't really different from each other actually as the former often uses the latter to do the work. The only exception to this rule is the Service Desk portal (thanks to the "Customer portal access" security type). This security type allows us having different permission configuration for users when they enter through the portal. The different permissions however strictly only apply to users in the "Service Desk customers" group.

            If you do have the need for per-channel permissions, then I would recommend creating separate user accounts with each having permissions according to their use case.

            JIRA issue creation vs Customer portal issue creation

            As the description mentions, you can adapt the default permission configuration to not give "Create Issue" permission to the "Administrators" and "Service Desk Team" roles. As long as you add the users in these roles to the "Service Desk Customers" role, they can still create issues in the portal (they can NOT if you don't do this!). I believe we now even support dismissing the warnings caused by deviating from the default configuration so you won't get constantly reminded of the change.

            However, I would recommend creating separate roles for users that don't fit into the default roles setup. i.e. instead of adapting the Administrators and Team role permission assignments, it would be better to create a "Restricted Team" role and assign that role to permissions you want restricted users to have in JIRA, keeping the "Service Desk Team" and "Administrators" role for those users with full access.

            Michael Ruflin (Inactive) added a comment - Per channel permission configuration Per-channel permission configuration in JIRA isn't supported. Web application / REST api access for example isn't really different from each other actually as the former often uses the latter to do the work. The only exception to this rule is the Service Desk portal (thanks to the "Customer portal access" security type). This security type allows us having different permission configuration for users when they enter through the portal. The different permissions however strictly only apply to users in the "Service Desk customers" group. If you do have the need for per-channel permissions, then I would recommend creating separate user accounts with each having permissions according to their use case. JIRA issue creation vs Customer portal issue creation As the description mentions, you can adapt the default permission configuration to not give "Create Issue" permission to the "Administrators" and "Service Desk Team" roles. As long as you add the users in these roles to the "Service Desk Customers" role, they can still create issues in the portal (they can NOT if you don't do this!). I believe we now even support dismissing the warnings caused by deviating from the default configuration so you won't get constantly reminded of the change. However, I would recommend creating separate roles for users that don't fit into the default roles setup. i.e. instead of adapting the Administrators and Team role permission assignments, it would be better to create a "Restricted Team" role and assign that role to permissions you want restricted users to have in JIRA, keeping the "Service Desk Team" and "Administrators" role for those users with full access.

            It would be beneficial to be able to keep the ability for users to create issues using the "Create Issue" function inside JIRA, but only on some projects. That way all Service Desks aren't forced into this portal, but only the ones we want.

            Kurt Newcomb added a comment - It would be beneficial to be able to keep the ability for users to create issues using the "Create Issue" function inside JIRA, but only on some projects. That way all Service Desks aren't forced into this portal, but only the ones we want.

              Unassigned Unassigned
              tevans Tim Evans (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: