-
Suggestion
-
Resolution: Unresolved
-
None
-
21
-
6
-
NOTE: This suggestion is for Jira Service Management Data Center. Using Jira Service Management Cloud? See the corresponding suggestion.
It would be great if the request type groups were also exposed to the search filters and/or JQL. Specifically the use case here is when you want to have a singular service desk entry point but issues created from it are isolated to individual agile boards for segmented teams.
At the moment the only way to do this is to create many "duplicate" request types that map to an issue type for workflow and group for display then have the board filter against the various (sequential variations, e.g. request-name and request-name2) request type names you might need. This of course can be managed with some level of accepting duplicates on the request type and the expectation that any time those change the filter for the board will need to change.
- relates to
-
- Not Being Considered
- links to
- mentioned in
-
Page Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-3472] Expose request type groups to search filters or JQL
+1. If we capture something while creating, we should. be able to filter it.
Puzzled why this is not implemented in the last 6 years.
Is it possible at all during an issue creation to identify the request group that the user has selected?
When such an attribute is created "Portal Group" it needs to be translated into a field, this is the very basic of Jira functionality. And this is where the end-user can find the most usability.
@silas that works for "Customer Request Type" but not for the groups. I had to interact with another group's Jira ServiceDesk at work. I created a ton of issue filters and dashboards.
ALL 100% COMPLETELY USELESS
WHY?
Because they rename things, and do so without informing us. This results in all my search filters and dashboards breaking. Days of work made utterly useless. I finally gave up - why bother? And ya, talking to the other group and requesting they do things differently, NOT a realistic answer.
Definitely support this as a search option.
Presently, if I create a search filter for use in dashboards, I am commonly using AND "Customer Request Type" = REQUEST-TYPE-NAME. The problem with this is multifold:
- If you want to filter multiple request types, one must add each individually.
[MULTIPLE ENTRIES FOR EACH ISSUE FILTER]
Example: AND "Customer Request Type" = REQUEST-TYPE-1AND "Customer Request Type" = REQUEST-TYPE-2"Customer Request Type" = REQUEST-TYPE-2 - If the name of a request type is changed, every single filter for which it has been referenced must be updated as well.
[UPDATE ALL ELSE FILTERS /DASHBOARDS BREAK]
Benefits of Search by "Request Type Group"
- Requires only a single criteria to be added to an issue.
[ONE ADDITION FOR EACH ISSUE FILTER vs MULTIPLE]
Example: AND "Request Group Type" - ++Newly created "Request Types" automatically picked up upon addition to the "Request Group Type". [NO CHANGE REQUIRED]
- Changing the name of a Request Type will not cause issue filters or dashboards to break.
[NO CHANGE REQUIRED]
The above benefits would lead to a faster and more flexible implementation that requires significantly less work or alteration.
Based on the upon evaluation, one would preclude that the addition of filtering on "GROUP" should not merely functionality added to Jira, but should be adopted as a best practice for many situations.
Please consider to implement this request! The request type (or "portal") group seems not to be stored anywhere currently, so prior to add it to JQL it also needs to be stored for each ticket!
@Silas Alexander: the question was about groups. This seems still not to be possible.
You can use them in JQL statements using "Customer Request Type".
everytime i get so close to having automation done, i hit another roadblock.
+1000 why wouldn't you make this available?
I'd also add +5 for this, because we're highly missing this. We have grouped our requests in different groups for the efficiency of our customers reporting issues in the right place. But this issues comes when we wanted to create different queues for the different teams involved, now all teams are monitoring on a single queue.
I have achieved this using following workaround :
Create a Queue named as your group with JQL :
"Customer Request Type" in ("as/0ff9d3b2-e607-428c-aaca-82467696efbe","as/fdcca5a4-326a-474d-8cee-80622412f3e5","as/b70efb7f-fcb9-41da-bcda-c4fcdc49d792")
when you type you will get auto complete suggestions for your request types.
"as" is project key remaining part is request type key from the DB . If the auto suggestion is not working you can look into the db table : AO_54307E_VIEWPORTFORM filter with your View port id(portal id displayed in ur service desk url) . In this table KEY is appended with a "/" ( "as/0ff9d3b2-e607-428c-aaca-82467696efbe")
Is anyone from Atlassian looking at this?? I too want to create filters based on the Request type.
We have actions that are the same from an engineering perspective but that is not known to the users of each product, so the groups are product slices of our technology. We would like to report on which products get the most of each request type.
Hello,
I too would like to +1 this idea.
I utilise the customer front portal to craft groupings of requests which fit our reporting strategy.
Currently I have to add each of the 5+ jobs to the single JQL line when running my report which reports based on my request Group in the portal. Then, when I have to add additional refined Customer Request types, I do have to update the report queries.
Whilst not terrible, it is slightly inconvenient.
I would love this "Request Type Groups" to be added to the JQL dictionary.
Thanks Atlassian, keep up the great work, love your product.
Regards
Matthew McCracken
+1