+1

+1

+1. need to show all request types

+1

Would really like to see this one implemented 

+1

I would like to have this ability in the widget. I would like more than one default request type available.

We have created a form which should show for all request types but it only works in the protal, not in the widget.

Would like to have the ability to add field hints in the search box for the widget.  Thx, -M 

Hi guys, it would be great to see some progress in this feature. Making mandatory for the useres to search is not the best option and most of the times the wording itself causes the right results not to be shown.

Thanks!

Displaying Portal Groups from /portal-settings/portal-groups to expand and select a specific request type would be ideal for our group. Basically, what has been done in portal (linked in /portal-settings) would be bets

Next best option for us would be to list all request types and search to filter down.

Thanks!

Please add a drop-down of the available request types, this would be a huge improvement.

Can only agree, more or less useless currently, unless you only have one request type in which case it is a great tool.

Looking forward to se an update to this functionality. Support center widget is very poor now

Sad to see not one update from Jira since ths issue was created.

The only positive about the current widget is that it can be used a case study to demonstrate poor UX/CX.

something something why wasn't this included from the get go something something

within the widget, it may also be useful to leverage the existing functionality offered in the customer portal where you can create portal groups for various request types. in my use case of the widget, i would like to be able to align the look/feel between the widget and the portal. so by displaying the request types organized by portal groups in the widget would be a nice feature.

Yes, totally agree. Widgets does not work properly because of this problem with request types. Such a simple thing that would be a game changer.

Echoing what's been said before 🔊 https://jira.atlassian.com/browse/JSDCLOUD-5974?focusedCommentId=1883954&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1883954

status update? is it fixed or not? can we see the full list in the widget?

According to this forum article (https://community.atlassian.com/t5/Jira-Software-questions/How-do-I-show-all-request-types-in-the-support-widget/qaq-p/721373) it seems this is already a feature for Jira Software on Cloud.  

Magical Atlassian Unicorns, is there a reason why this is open to Jira Software and not Jira Service Desk?  This is a key feature for Service Desk workflows!  I'll echo the above comments with my users do not know what to search for, I want to give them the request type options to choose from and I am choosing not to use the portal because I'm having other issues with it and I want my users to have visual continuity from my site to the request forms.

We can't use this feature until this is resolved. We need all request types.

This feature needs to be implementet to make the Widget complete!  

Really love this feature, hope it will be released soon!

Surely it's harder to make this only show certain types by searching, the first thing it should do is show all types by default and then filter based on a search? 

This has been over engineered to the point it is not useful. I a better solution for me is to create my own ? icon and link that to the help center page that DOES have all the types. 

I was excited about the service desk for the ability to quickly respond to users issues and for users to easily raise bugs, suggestions ect at the point they are created whilst still using the product. But the fact they can't access all ticket types undermines that and makes service desk as a whole less useful. This should be addressed ASAP, if you don't have time...show me the code base and I'll do it!!!

can there be an update on this feature? @Jira ? 

Very strongly agree. If I type "a" and hit return it shows all the request types, but that is a pretty lame instruction to give to an end user.

I went to all the trouble to set up the service desk, but now I am contemplating going back to Zendesk.

Same here, would love to have this as a new feature and soon hopefully  

Would make the widget more usefull, for now I find it scores low for usability

Strongly agree.  We would love to use the widget if we could customize a list of request types that show up immediately upon clicking the widget.  As it stands, we can't expect customers to guess at the possible ticket types.

As a simple example, the default Service Desk instance comes with a request type called "Product Trial Questions".  That option isn't shown unless the customer types the word "trial".  Typing "product demo" does not find that request type.

The search bar is great, but we really need to be able to choose a few request types that are always displayed on click.

Echoing what's been said before - current solution is very poor usability-wise. End customers can't be expected to know the exact name of issue type they want to open

Any updates here?

I'm shocked that this is not possible. It really makes the widget almost useless and is a really a blocking point for implementing Service Desk instead of other solution provider.

I repeat my comment from JSDCLOUD-5721, widget without this function is useless for my organization, because end-users don't know anything about available issue types.

This is essential for us. It is not necessarily appropriate for users to have to "search for" their issue, which may be very specific to them, especially as we have not yet built up our knowledge base. If there are no appropriate results, they have to choose from only the request types returned by the search, which is often not correct. 

The users don't know what kind of request they can create, the options need to be shown from the outset so they can select appropriately. At the moment, pretty much everything gets reported as a bug, and then we have to "move" it to the right request type.