Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,703
Community Members
 
Community Events
176
Community Groups

Cross Project Issues and Dependencies

Edited

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.

1 answer

0 votes

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.

@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. 

Like # people like this

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events