JIRA filter based on Role

[Jozef Vandenmooter]

Hi,

We need to be able to report on issues based on role. I must be missing something obvious here because I can't seem to find a way to do that.

What is the JQL for instance that returns all the Defects that are assigned to users in the Developers role?

Thanks,

Jozef 

[Randy · Accepted solution]

You cannot do this with JQL.

A workaround, if your role doesn't contain a ton of users is to generate a list of users from the role and include them explicitly in your query:

e.g.

assignee in (joe, jane, bob, betty, john, jill)

[Jozef Vandenmooter]

Thanks, Yes: we have tons of users in each role...

[Jeremy Carlson]

This can be done by using the projectsWhereUserHasRole() JQL function.

You'd have something like:

project in projectsWhereUserHasRole(Developers) and type = "Defect"

[Karmandroid Singularity]

I use this syntax to filter issue based on roles in the project:

assignee in membersOfProjectRole("<project_name>", "<role_name>")

[Jozef Vandenmooter]

@Karmandroid Singularity It appears you have the cPrime plugin?

[Karmandroid Singularity]

@Jozef Vandenmooter I am not really sure what plugin are installed on the JIRA, since I am not the Administrator :). But when I browser what are possible, that query works for me

[Chrisjir Parkin]

Here's another thought - not sure if it's what you want, but trying to help.

Set the conditions of a project workflow transition to filter issues based on Roles.  The person in a specific role is the only one who can see the transition.  Use a workflow post function to apply a specific label or set a custom field value.  Now, the issue is tagged by the Role of the person who transitioned it.  That tag (label/field) can be used as a condition to other workflow transitions and/or in a filter.

Because a workflow transition can end on the same status on which it began (loop transition), you can use a transition just to apply labels or set field values without actually transitioning the issue.  And once you've tagged them, other workflow conditions can make transitions available that weren't visible to untagged issues.  So, for example, a loop transition could apply a label "hardware" and a condition could check for that label, allowing only properly tagged issues to transition.

Another approach might be to create a custom user picker field that you assign based on some workflow condition.  It might start out as a copy of the Assignee field, but then get modified in a subsequent workflow transition.  With that custom user picker field limited to only the people that you want to have in it, you can build reports and filters using that field and know that it won't have "just anybody" in it.

Hope this helps.  And, yes, it would be better if Jira had the required logic to do this without such a circuitous workaround.

[Jobin Kuruvilla [Adaptavist]]

You can use the JQL Tricks add-on for this. See https://www.j-tricks.com/jqlt-user-functions.html for the available user functions.

usersInRole is the one you need.

[Jozef Vandenmooter]

Thanks, that plugin indeed comes with exactly the function we need. However, that costs more $s.

We have ScriptRunner. Do you know if this can be done using SR?

[Randy]

You can checkout the Scription JQL function support in SR.  I've never tried it but maybe the jiraUserPropertyEquals function will work.  There's a note in the doc that only admins can use it though...

https://scriptrunner.adaptavist.com/latest/jira/jql-functions.html#_user_functions

[Jeff Boon]

So far still no real default way to do this?

[miikhy]

Hi Jozef,

As mentioned by @Randy, no native JQL for that. I would recommend either to name the users individually or to have groups assigned to Role and use:

type = Defect and assignee in membersOf("group-name")

Hope this helps!

Cheers

[Jozef Vandenmooter]

Thanks, but that would negate one of the advantages of using roles: that they can be maintained by a Project Administrator. Groups require JIRA admin access.

Bizarre JIRA does not have this function OOB, especially because of their push for the Project Administrators to take some of the load off of the JIRA Administrators.