-
Suggestion
-
Resolution: Unresolved
-
None
-
21
-
16
-
NOTE: This suggestion is for JIRA Portfolio Server. Using JIRA Portfolio Cloud? See the corresponding suggestion.
Problem
Currently when JQL searching with the "Team" field, it only recognizes the team ID values. When using the actual Team names, no results are returned.
Steps to Reproduce
- Create a shared team in JPO (i.e. red)
- Create a plan with issues and assign issues to the "red" team
- Commit the changes
- Now do an issue navigator search for:
team = red
-
- note that no results are returned
- Now do an issue navigator search for the ID, let's say the ID is "1":
team = 1
-
- note that results show the issues assigned to the team
Extra Checks:
Database confirms that the "red" team ID is 1:
jira724=# select * from "AO_82B313_TEAM";
AVATAR_URL | ID | SHAREABLE | TITLE
--------------------------------------------------+----+-----------+----------------
| 1 | t | red
| 2 | t | blue
/secure/projectavatar?size=medium&avatarId=10324 | 3 | f | SSP board Team
(3 rows)
Expected Behaviour
JQL searches recognize both the team ID and team name as search parameters.
Actual Behaviour
JQL search only recognizes the team ID as a parameter
Workarounds
Workaround 1
- Get the list of Team IDs directly via the Database, using the SQL query below:
select * from "AO_82B313_TEAM";
- Rewrite the JQL query to search the teams using their IDs from the DB instead of their names. For example (assuming that the Team has the ID 3):
Team = 3
Workaround 2
- Get the list of Team IDs by sending a GET call to the Jira's REST API End Point below:
<JIRA_BASE_URL>/rest/teams-api/1.0/team
- Rewrite the JQL query to search the teams using their IDs from the REST API response instead of their names. For example (assuming that the Team has the ID 3):
Team = 3
Workaround 3 - Only works with "Shared Teams" (Does not work with "Private Teams)
- Go to the Issue Search page
- Type the name of the Teams field followed by the "=" sign
- Start typing the name of the Team you want to filter issues with. You will get a dropdown similar to what you see in the screenshot below:
- Select the team you are interested in from the dropdown, and you'll see that the JQL query will be automatically populated with the Team ID, as illustrated below:
[JSWSERVER-24990] JQL Search for Team does not Recognize Team Names
when using the shared team, you need to be able to query using JQL, what issues are assigned to that team, especially if you need to be able to bulk edit it to apply a different team if work has moved.
I also agree on the uniqueness as it is very confusing when there are multiple shared teams with the same name, if this is going to be allowed, then we need to be able to see the ID associated with it, so teams can choose the proper team
this would be very useful and just seems like a logical thing to implement 
"When performing a JQL search, shared teams will be suggested when entering their name. Selecting a suggestion will then insert that team's ID into the JQL. We do not match directly against a team's name because it can be changed or be non-unique. A similar behaviour applies to sprints (i.e. Sprint names are suggested and then replaced by an ID).
Regards,
Shafqat Bhuiyan | Portfolio for JIRA Development"
Shafqat - I would argue that shared team names MUST be unique. It can cause a lot of confusion if there are duplicate team names. Further, if a team name needs to be edited, there is no way to determine (upon hover over or anything else) what ID is associated to a team name in the list.
A similar behavior does apply to Sprints where you can type the name, select the suggestion, and system returns the ID. However, Sprints will still allow user to search by the sprint name by typing the sprint name in quotes. Sprint = "Sprint 10". In fact, the best thing about that query is that it returns everything that contains the quoted value.
Not sure if a separate issue is used to track the issue where the TEAM field doesn't even show all values in JQL query. That also need to be fixed.
I'm not sure why a basic functionality is "Gathering interest". Shouldn't this be in the long/short-term backlog instead?
One of the main selling points as I remember from Jira courses is to let the customer work with it and let the tool do the talking. With Portfolio, I feel that every single feature has a bug of some sort that keeps on annoying both the users and us as admins.
Even if this issue in particular is not a bug per se - because Team names can be duplicate so this would be "sort of" expected - it certainly feels like a bug. I for one don't see many real life scenarios where you would want duplicate Team names on a single Jira instance. If I am wrong, then so be it, but every single team I talk to is wondering why Portfolio lets you create duplicate Teams as that only gets confusing, and brings close to no benefit.
I realize that now it's a bit too late to change core functionality, but I find the whole team:id mapping becoming tedious in every Portfolio-related discussion and think that it should be reviewed.
Hi blaisbr,
Thank you for reporting this issue. I have created a new bug ticket for it here: https://jira.atlassian.com/browse/JPOSERVER-2009
I suggest voting and watching this issue so that you are notified when it gets fixed.
Thanks,
Shafqat
Hello Shafquat,
additional information around this issue: if you have a JIRA filter in a Confluence page with the Team as a column, you will see only the ID instead of the team name - it is a Bug, should I create a Bug ticket for you guys?
Dear all,
I would like to inform you that this issue in the project JPOSERVER is being migrated to the new project JSWSERVER. Your votes and comments will remain unchanged.
Our team at Atlassian will continue to monitor this issue for further updates, so please feel free to share your thoughts or feedback in the comments.
Sincerely,
Aakrity Tibrewal
Jira DC