|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Mark Imbriaco - 28/Jan/05 09:58 AM
I couldn't agree more. I have a huge need for this functionality right now.
Looking over my examples and finding they didn't even make sense to me any longer I thought I'd try again:
Suppose you work for ACME Inc. and have a product called 'ACMEEnterprise' which is currently being supported in production, enhance in development and tested in QA. The product is made up of 3 modules which are mapped onto JIRA Projects. So JIRA Project #1 contains all issues related to ACMEEnterprise.Module#1, and so on. To control this in JIRA Today you have to create custom fields which contain ACMEEnterprise versions in order to map a Module# version to a 'released' ACMEEnterprise version being used in the field, at a customer site, etc. This is the only way to find issues which affect the current release, or are being worked on for the next release, etc - of the flagship 'ACMEEnterprise' software. This rapidly becomes very difficult (read 'Nightmare') keeping the version numbers sync'd across projects and producing status reports on the 'ACMEEnterprise' product for senior management - who only want to know the big picture, not how many defects are 'active' for Module#3. There are several different ways people try to solve this in JIRA today and for several other reasons than what I described above. While I marked the issue as 'trivial' it is not - either resolve in JIRA or to the enterprise customers looking for a product to meet this need. minor correction - for my client we used the version field to contain the 'enterprise' product version release numbers to enable the use of roadmaps, etc., and created custom fields to hold the module release numbers. Regardless of the approach it's a pain to maintain - however, if you use a site-wide custom field to contain the 'enterprise' product release number then you only have to modify the contents of the custom field to see the changes in every project.
GLOBAL PORTALS, CONFIGURABLE PROJECTS PORTLET, PROJECT GROUPS Would address these issues.
I think the only realistic solution is true nesting of projects.
Versioning is the real problem. Here we have discrete applications that are integrated into one or more discrete products. This means that we have product version numbers as well as application version numbers, and product A version 1.0 might including application1 version 2.5, application2 version 0.9 and application3 v4.9 Currently we just cannot have this product relationship in Jira. We need to be able to release a Product version which will be tagged as including the latest Linking is a better solution than plain nesting, as Product A will need Application3 in it and so will ProductB. Then we need Product-level (highest level parent project) versions of reports and searches, and Roadmap, merged release notes and change logs etc. Also reports of which application versions are included in each Product-level release. This is a tall order but it will make Jira an absolute killer for engineering companies who produce reusable modules that are spread across their products. Thinking about it, the solution to organising this would appear to be a new panel on the Administer Project page called "Project dependencies" just like the Components page, where you can Manage dependencies and then add/remove any other Jira projects as dependencies of this project.
This sets up the parent->child relationships you need to achieve the rest of the functionality, in a clean and simple way. I would be happy with multi-level project nesting and the accompanying portlets and such for navigation/display to start off with.
Also, having the project categories in the professional version would more appropriate. That would leave the crm portion for the enterprise. can't get to linked external reference, get access denied message.
Adding Projects to a category is a chore, you have to do each project one by one. This is backwards, you should be taken to a page which has a multi-select list of projects and the category dropdown list. Select all the projects you want then select their category and submit.
Hi,
Categories and sub-categories are vital to our project hierarchy. Something like this would be excellent for us: Category A ... and so on The ability to apply permission & security schemes for these categories would be helpful, as well! Thx, Mihai I agree with previous comments, we absolutely need :
I couldnt agree more with Mihai L. When can this feature be available? I really hope very soon.
The analysis here is very good and pinpoints the enhancement I would like to see in Jira. In an enterpise like mine we have over 100 projects accross 5 departments.
Many of these projects have sub-projects planned with projects/sub-project teams etc. Having all these projects with only two layers (Categories -> Projects) invites caos. Visually managing these in Jira has become very hard, even to the point were we are seeing users neglecting to register work because "it's to hard".. thanks I too would like to see this feature implemented if each sub-project could either inherit the parent's properties or override those properties. For example, if the parent had a component named Database with a lead particular user named A, the child project should be able to inherit that component and the lead or override the lead with another user.
In addition, all project specific properties available to the parent project should be available to the child project. Thanks, I'd like to see these features added to the next release. We need to add more structure in organizing our projects as the list of ongoing projects continues to grow in our department. I really would like to see sub-categories.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Trivial
Enhance 'Project Category' functionalty (versions/components/roadmap) and allow nested categories
