-
Suggestion
-
Resolution: Unresolved
-
None
-
2
-
3
-
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
However, 12241 is looking at a deeper issue, in that the JIRA tracking system is rather flat, and does not contain a lot of functionality for organizing the 'project level' within the system. As well, organization by product is an imporant idea.
This is what I need to do. Currently, I"m trying to use categories to do this, as well as the 'key' in issues, so I may have several categories representing our products:
PPM
EPM
SPM, etc.
The key will then correspond to that, so I can see issues by product:
PPM - 001
However, this is a major workaround.
There may be a few things to consider, such as:
1. Ability to have custom fields on the project itself that allows you not not only filter by issues, but also by project. As many have stated in the other three issues you listed, there may be multiple PROJECTS for a PRODUCT. At least providing a way to filter by attributes on a project could help with this, as you can say, for example, "show me all my projects for this product". You can't do that right now, except through maybe a category, but, again, you can't actually create a filter on that. It only shows up on the dashboard - not very helpful for reporting.
2. The other issue is that there are times when a project itself may need to be broken down into smaller 'sub-projects' that then will collect their own set of issues. This is getting more into actual project management, which Planview does.
My problem I'm having here is that internally we are trying to implement our own tool, and use it in conjunction with JIRA. One of the problems is that the level of detail we want to collect issue information is at a level lower than the project....in our terminology, a 'phase' level, or possibly even the 'task' level.
Project
Phase
Task
The ability to be able to bring more detail into the system would be very helpful. For instance, we could import into JIRA the work breakdown structure for a project down to the level in which we want to collect issue information, and be able to roll that all the way to the project.
In the example above, import down to the Task level. Issues would be attached to the Task.
3. Another problem I see that people may be having is the ability to relate multiple projects to a particular version. Again, this gets back to #1 above, in that projects need to be able to have attributes on their own, outside of issues. So, you can create a filter that show you:
"show me all my projects for Version 10.x".
You can't do that right now because projects don't have attributes, except for category, and you can't create views based on project, only on issue.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The other thing I was talking about was to have custom fields on projects, with the ability to create filters on projects, NOT just issues. People want to see, by PROJECT, not by ISSUE, what is happening for a version. You can't do that right now, because you can't create a view on projects. You can only see, by version, project information for a single project at a time.
So, what that means is, in your filtering functionality, a user could not only create a filter to see issues, based on values within fields for those issues, but also create filters to see projects. I know this is a bigger change, but it looks to me like others are asking for it.
The other limiting thing I see, which others are also running into, is your 3 level 'hierarchy'. It really isn't a 'hierarchy' per se, and it doesn't take into account complex project structures.
Unfortunately, JIRA is using the term 'project', and requiring that issues come off of projects, instead of just having issues and sub issues, and using fields/attributes to categorize them. When you start using the word 'project', and requiring that issues become part of a project, you begin to move toward the idea of project management, and all the overhead that comes with that.
As a project management system, JIRA, personal opinion, is not ready for. As an issue tracking system it has very good functionality. I'm running into problems with being forced to tie issues to this 'project' level, when I personally think that the idea of a 'project' is not necessary in this system - even though there is rudimentary time reporting. You want to have this, then you need to support more levels than 3 in your 'project' hierarchy.
- duplicates
-
JRASERVER-2698 Create versions on multiple projects
- Closed
-
JRASERVER-71913 Order by version name (not ID)
- Gathering Interest
-
JRASERVER-8663 Ability to share components between projects
- Not Being Considered
- is duplicated by
-
JRASERVER-19819 Component Schemes
- Closed
- is related to
-
JSWSERVER-9237 Multiple versions in version report
- Gathering Interest
- relates to
-
JRASERVER-12241 Support for Product Suites / Sub-Projects
- Closed
-
JRACLOUD-14588 Implement Component and Version Schemes
- Gathering Interest
-
JRASERVER-19775 Allow ~ Operator for fixVersion field
- Gathering Interest
-
JRASERVER-64868 Make Versions' fields accessible for JQL filtering
- Gathering Interest
- supersedes
-
JRASERVER-14569 Implement Component and Version Schemes
- Closed