How can I query on number of times in a status?

[Lisa Zentz]

I'd like to find the number of times issues were moved to a particular status type that would result in a count - e.g. 3 times in status x.

How do I structure that?

Thanks!

[Randall Robertson]

Sorry for the slow response. I've been sick. You can set up a security scheme and grant rights to see the issues based on the groups you have set up. Will you ever assign a ticket from your team to another team? If so, you will have to make sure to change the security level so that the person on the other team can see the issue. See https://confluence.atlassian.com/display/JIRA060/Configuring+Issue-level+Security for more information on Security schemes.

[Raghav Adiga]

Thanks Randall for the response... I have another question regarding the security of the groups. We have created one group for each team and also have the components listed as teams. The groups perform similar tasks across multiple projects and i have the permission scheme for that created. The plan is have all the issues to be assigned to the component lead and inturn he would then assign the tickets to his team members, but i am having a tough time in defining security on the issues assigned to a particular team or component. How do i do that? I do not want the other teams to know what is going on with my teams issues... and also the teams should not have access to filters or dashboards on any other teams data....

Appreciate all your help with this as we are in the initial stages of setting up JIRA and want to make sure i am doing it right..

Thanks

Raghav

[Randall Robertson]

Groups are helpful for managing permissions in an easily scalable way, so I would create a group for each team. Components can be used to auto-assign an issue, so it might seem useful to have your teams listed in the components field, but whether you do that or not, you still need groups for your teams so to can manage permissions quickly. Depending on your team definition, you may need more than one group per team - maybe an admin group and a developer group. How you grant those groups permissions depends a lot on your particular organization. Roles are helpful if your groups do different things in different projects, but if they are the same across projects, you can grant rights directly to the groups and share the permission scheme across all projects for simpler administration. You cannot assign issues to a group, so if you do put your teams in as the components, you will still only be able to auto-assign the issues to one user as defined in your component settings. Generally it is better practice to identify the major parts of your project and make those the components. Then you choose the component lead for each item. This allows JIRA to assign an issue by having the person creating the issue indicate the part of the project where the work needs to be done. The reporter is not required to decide who will do it. Finally, as mentioned, you cannot assign to a group, only to specific users. Some teams create a generic use to represent the whole team and make that user account the component lead. That works if your team is watching the Jira dashboard regularly and can see when that user gets new issues or if you set up an email forwarding rule that forwards the notifications from the email address for that user to the whole team. There are plenty of threads in the answers forum on assigning to groups, so read through those for more ideas. Assigning an issue to the user who clicks Start is an easy post-function you can add to the start transition in your workflow.