Can I restrict the Type dropdown in the Create Issue screen to only Issue Types, not Request Types?
The "Type" dropdown field in the Create Issue screen is now displaying Request Types and Issue Types, whereas previously it was just the Issue Types which were available for selection. Can I set this so it only displays Issues Types and not Request Types?
3 answers
Now, I've just started playing with Jira Service Desk today, but I think I have a workaround for your issue, though there are drawbacks. Read: This is not professional advice, and I am not responsible for any damage that may occur. I DO NOT recommend implementing this on a live system without testing first.
In order to remove the "Request Types" entries that precede the "Issues" entries in the "Type" drop-down of the "Create issue" window, you must remove those request types entirely from your project. Which solves your problem!
To do so, follow these steps after navigating to the project in question.
This requires Administrator privileges for the project.
(Steps with pictures below)
(1) In the project, navigate to Project Settings
(2) Navigate to Request Types in the sidebar
(3) Before a request type can be deleted it must be removed from any request groups it is currently in. Find the ill-fated request we are removing, and click on Edit groups.
(4) Uncheck all groups it is a part of and hit save.
(5) Navigate to "Hidden from portal" - the Request type will have dropped down here, but it's not really gone yet. To get rid of it, click the "x" to the right of the entry and confirm deletion.
After you've done that, they will disappear from the drop down menu when creating new issues. If you do it for all of them, you will only show your Issues in the bar.
Naturally, the drawback is that means if you actively use these request types in other parts of the project (e.x. the portal), that cannot be reconciled with this method of removal. If they are not actively used it shouldn't be an issue to remove them as far as I am aware. It's also worth noting that Request types are basically just cookie-cutter issues with some fields automatically filled out.
---------
Steps w/ pictures
(1) In the project, navigate to Project Settings
(2) Navigate to Request Types in the sidebar
(3) Before a request type can be deleted it must be removed from any request groups it is currently in. Find the ill-fated request we are removing, and click on Edit groups. I made a sample one:
(4) Uncheck all groups it is a part of and hit save.
(5) Navigate to "Hidden from portal" - the Request type will have dropped down here, but it's not really gone yet. To get rid of it, click the "x" to the right of the entry and confirm deletion.
I have detailed out the steps needed to assign only desired Issue types for your Project . I hope it solves your problem
1) Go to Project Summary & select Issue type to edit the types available in the project
2) Select "Edit Issue Types" from Actions
3) Remove the Request / Issue types which you do not want in the Project.
Hi Ajay, thanks for your reply but unfortunately it doesn't resolve the problem which is that we're now getting the option to select a Request Type in the "Type" dropdown (see image), whereas previously the team were only able to select Issue Types which is my preference.
In the hope of not confusing things, the underlying issue is that once a Request Type is selected against an issue the notifications stop using the notification scheme and treat admins and agents who are involved in the ticket as customers, which is not what I want for internal projects.
https://confluence.atlassian.com/servicedeskserver/managing-service-desk-notifications-939926348.html ... "Agents don't receive notifications on their own changes when they act as a customer on issues with a set request type. Jira Service Desk treats agents acting as a reporter, participant or approver on these issues as a customer. This occurs regardless of the notification scheme."
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.