Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-14588

Implement Component and Version Schemes

XMLWordPrintable

    • 2
    • 3
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      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.

              Unassigned Unassigned
              f995cd09adc6 Shawn Walton
              Votes:
              111 Vote for this issue
              Watchers:
              57 Start watching this issue

                Created:
                Updated: