You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I assume there are people out there that have multiple products tracked under a single Jira Software project. I'd like to hear how people are organizing their issues.
I am working on a configuration for a group and I get the feeling that I'm not organizing this quite right. I'd like to hear how others are handling this.
We have many products. By product I mean an entity that is released. For example, one product might be a control panel and other product might be the configuration tool for configuring the control panel. The software for the control panel is released as a single entity. The configuration tool is released with a single installation file.
It seemed that Jira Component/s would be perfect for "a releasable entity". This project could use Component/s of "panel" and "config tool". However, the developers want to have modules that are based on the component. For example, "panel" might want modules of "I/O controller", "Event Processor", "UI" while "config tool" might want modules of "UI", "DB", "Downloader". The actual list of Component/s and Modules is quite long. We can use a custom field of Module that is a select list. However, I don't know of a good way to prevent a user from selecting a module that does not make sense for the Component/s selected in the issue.
I'd like to hear how others might be handling a similar situation.