Cross Project Issues and Dependencies

Question

Opened this suggestion for tracking https://jira.atlassian.com/browse/JSWCLOUD-17623

The problem: When one project/team has a dependency on other project/team - there is currently no easy way to set this up. The "traditional" solution/answer to this that is usually given is for the user to create an issue in ProjectA, then switch to ProjectB and create another issue there, then switch back to ProjectA and setup a link (i.e. "blocked by") between issues. Very cumbersome and as a result - most people just dont use this approach.

And as a result various  workarounds are used. One example (that we are using in classic projects) is to have 2 boards for each project : 1 board is "traditional" and filters in only the issues for that project and 2nd board is "cross team" board that filters in issues like this:

project = MYPRJ or labels = MYPRJ ORDER BY Rank ASC

So, when other projects add a label to their issues that matches the project key of the project they depend on - their issue will show up on that "cross team" board. Very easy to use, but creates other problems as you can imagine, since this is technically a "hack" or workaround if you will - like having to have 2 boards (due to permissions, releasing other team's versions when you release yours, etc), having to map additional statuses in cross team board when different project have different sets, etc.  And ... this will not work at all in next-get projects. Overall - not ideal, but MUCH easier to use and intuitive than "traditional" issue linking.

Looking for ideas and discussion on how to best implement this if it were added as a new feature for next-get projects.

Yury Zhytkou · Answer

@Petter Gonçalves it does make sense, yes ... for small setups. Unfortunately for us it will not work as we have a lot more projects that can fit this solution. Each with their own requirements, boards, etc.

Ideally we would like to see a friction-less issue linking cross projects where one can create and link an issue in other projects from withing theirs while updating the issue. Think sub-tasks creation experience, but with each sub-task actually being an issue in other projects.

Petter Gonçalves · Answer

Hello Yuri,

An option that may apply to your scenario would be to use a single project and split your team efforts on sub-task issues, adding Issue Security Levels to only allow the relevant team to access the sub-tasks. Let me give you an example:

- Let's suppose you have a task opened to your Support team which also requires the action from the management team and budget team

- You can create two sub-task issue types to map both management and budget efforts and link it to the current support issue: Management and Budget

- Once it's done, you can add Security levels to allow only the relevant users to access each issue - it can be even automated based on the issue type:

Managers can only see Management issues

Financial analysts can only see Budget issues

Performing the steps above, you will be able to use a single board and manage your requests without needing to move between multiple projects.

Let me know if this approach makes sense to you, Yuri.