Filter for board using multiple projects

[Damon Gaylor]

I'm a little stumped on this one.

We have multiple Jira projects using Scrum.  We have a group of people who use a special DBA project and this team is a shared resource for the other projects.

I'm trying to create a kanban or Scrum filter for the board and struggling to come up with the best way.  The challenge is subtasks.

My initial query was basically:

project = dba or membersof(dba) or issuetype = dba

This worked great for standard issue types.  However, when we create subtasks, they don't show up until it is assigned to a member of the dba team.

I was hoping to get around this by having the other teams just create issues in the DBA project.  However, it is not easy to know which ticket is for which project unless we put that in the summary, which I don't like to do.

Any suggestions would be helpful.  We don't use any plugins, and hoping to not have to go that route.  

[Carlos Garcia Navarro · Accepted solution]

Hi Damon,

If I understood correctly, I'm not aware of a way to accomplish without plugins. If you could use Script Runner you could add this clause to also include subtasks, e.g.:

issueFunction in subtasksOf("issuetype = dba")

[Damon Gaylor]

Thank you Carlos.  This is exactly what I was hoping Jira would provide in their functions, but not there.... yet.

I may look into script runner, just hate paying the price because I don't think we will need it for anything else and we have a large user count.  

[Wade Tracy _Boise_ ID_ · Accepted solution]

I'm sure there are many ways to skin this cat, but Components could work well here.  If each project had a DBA Component, you could then just add any stories, tasks, etc. to the component and filter on that.  You also get the added benefit of being able to assign a DBA component lead that would automatically get assigned the issue if you want.

You're JQL would end up like:

project = dba or membersof(dba) or issuetype = dba or component = DBA

As a side note, you may not want to have specific issue types for different teams since the issue type is probably just a Task or Story.  Since the DBAs are in their own project, you could keep the issue type standard and just give them a separate workflow if needed.  Otherwise you'll end up with a proliferation of issue types which could get messy eventually.

Hope this helps!

[Damon Gaylor]

Thank you Wade, I'll play with your suggestion.  I agree on trying to keep things simple.  I don't see how components are going to help with the subtasks unless we always make sure to include the component on the subtasks, but I will play with it.

[Wade Tracy _Boise_ ID_]

I guess it depends on the use case:

Covered

1. People create DBA issue with sub-tasks in the DBA project 
2. People have a different issue type in a different project and create a sub-task for a DBA (They'll need to flag it for DBAs by using DBA component--they would have to do something anyways to indicate a DBA should pick it up)

Not Covered

1. People create a DBA issue type with sub-tasks outside the DBA project

I agree the last one would be a problem because you would indeed have an issue of sub-tasks not having a component without extra, manual work.  In that case you would have to train people to create the DBA issues in the DBA project.  Where I work we use Case 2 above--a given story may have sub-tasks for multiple teams and the components help make sure the teams have visibility that items have been assigned.  The team lead gets auto-assigned the sub-task and as the gatekeeper for their team's Kanban board.  But everybody's situation is different.  Good luck!