|
[
Permalink
| « Hide
]
antesa added a comment - 21/Feb/03 09:31 AM
we have large hierarchical list of components. High level components are assigned to groups (several groups in one project); issue goes automatically to group leader when it is created. So, there are no groups under project, as far as I understand, and no possibility to associate a set of components to one group that has a leading developer responsible for these components quality.
I agree.
Our software product [accounting] is structured as follows: modules (customers/stock/suppliers etc) = Components I think that lack of support for hierarchical organization of projects is the inconvenience number one in JIRA.
If you take a look at average installation of JIRA - like this at codehaus: you will notice that there are too many things visible at the top level. So JIRA should be able to support a hierarchy like Maven ---- Maven Core
at the Moment it just supports: Maven Core When number of projects is growing it is becoming not maintainable and things are very difficult to find. Michal,
What you are asking for it sub-projects, not sub-components. You can already group projects into project categories - which I think that codehaus are using? Subcomponents would be useful on jira.atlassian.com. We could have "Custom Fields", and then "Custom Field requests" as components.
I use sub-components for my 'management' project. In this project we plan/evaluate/prioritize change requests for all enterprise projects. this creates a horrible mess if we have one flat component namespace, so I utilized the new cascading select for this, where the parent == platform and the child == component.
I have experienced a different problem since utilizing this method: Scott,
>Michal, >What you are asking for it sub-projects, not sub-components. Yes - you are right. IMO the entire concept of "component" is not really needed in jira. >You can already group projects into project categories - which I think that codehaus are using? Yes codehaus is grouping feature but the number of groups is getting out of control as only flat hierachy is allowed. Note also that there are diffrent grouping staregies are often used. For example you can assign projects to active/inactive groups. Once you do this afaik you cannot have subgroups of projects active/clientX Michal I completly agree with all your comments about subcomponents. I just would like to insist on the possibility to affect specific groups to those components/subcomponents.
I would like to pile on regarding the desire to have "sub-projects". We have a large degree of IP reuse among projects, and ideally, all end-products would be described within Jira as a collection of other projects. When an issue is logged against "Fender, version 1.10", then all other projects containing "Fender, version 1.10" should get a clone of the issue - or someting similar.
Scott wrote:
"You can already group projects into project categories ..." (Not in the Pro version) Even with project categories you can only have a 1..1 association between any set of projects when you need 1...N. Jira should have 1...N project associations as well as 1...N component levels. We would love this feature. In fact we are having to break the metaphorical connection between how our real development teams work and how they are represented in Jira. Our product is very large and has around 40 major components (or what we'd like to call components) and each component has a potential average of 5 sub-components). Since we can't really handle this in Jira, we are using a cascading select custom field. But considering the well known problems with not being able to sort custom fields, and not having the same 'visibility' as components, we are really not happy with our current solution.
As an aside, having some meta data about components and versions and potentially subcomponents would also be a great help for us. It makes training new users in the system much easier (they have descriptions for the various components, and secondly it allows us to set the meaning and missions of the various versions). It sounds like components and subcomponents naturally fit many business' and teams work environments. From out point of view this is a must have feature. Component hierarchies within a project will really help. In JIRA there already is good starting - we can point to actual cause of issue by defining a component. With hierarchies we will more precise information.
By the way, this issue should be reviewed in conjunction with JRA-1991. can someone please specify when is this feature will be available in JIRA?
Cheers Hi Shobhit,
Unfortunately, there is no scheduled date for implementation of this feature as yet. The following document details how new features and improvements are scheduled by Atlassian: http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements Regards, As a work around to this issue, we use a cascading custom field, tho would love for there to be subcomponents for the many benefits components privide.
As a (minor) workaround i have created a listener that updates the component field from the first value of the cascading cutom field every time the issues is modified in any way. The listener takes two parameters, the project key, and the name of the custom field. This allows for multiple instances of the listener to be running across different projects using different custom fields. I am happy to contribute this listener if anyone is interested Hi Sam,
Can you send me details how I can setup this listener? Thanks, Irina This is one of the only areas of lost functionality that we'll experience moving from our current system to JIRA. It will definitely cause us some pain. I hope it will be considered at some point soon.
I have one project that needs this feature. As said before, this is a loss from the system we are migrating off of.
This is something that we need as well - project categories just don't cut it. Ideally a true "sub-component" is desired, but is there any way that a multiple select custom field could be based off of a current field. So this sub-component would just be a "Cascading Select" custom field, where the parent fields would be locked to the components. Not sure if this would be easier or not to implement as a work-around. (this kind of functionality might be useful for other things as well)
Sub-Components is a key feature for us which is very well supported by our current issue tracking system (but it has other limitations
 . When can we expect to get this feature? This may very well be a buy/no buy reason for us. I am not sure we need a subcomponent. If we can share component across the Project, It while do the jog and I thin it more simple to implement. Ex. I have two executable exec1 and exec2 (projects) that use the same CommonLib (component). I want to be able to see on the release note of exec1 the change that has been made in exec2.
Thanks Subcomponents are essential.
You need subcomponents for each system/app. Pretty much a system breakdown The definition of a project is that it is timebound i.e. has a start and an So in Jira two views would be nice. One from the NOTE! A jira record in a project does not have a mandatory link to a system Regards email: sundstromlars@yahoo.com.au Subcomponents would be great!
Another thing id like to see is relations between components, compare .net dll's and their dependencies among them selves.. So when i touch component A i would like to know that component x,y and z are dependant of this and needs to be changed/recompiled/tested. We then close in to continous integration.. but /Johan sub projects really does sound like what we would be looking for. We have a huge list of projects each managed by an individual group. Each group of course is working on more than one thing. sub components would get us the functionality we need but sub projects is probably a more correct term. Either way a more granular breakdown of projects / components would be greatly appreciated.
Just to add a more comprehensive "me too" to this than just a simple vote allows... Not being able to have sub-components is really beginning to get in the way of our ability to correctly represent our projects in Jira.
I'd just like to add another "me too, please" comment to this request.
We have several core projects, made up of several high-level components with myriad detailed components. Reporting on what is costing us time/effort is a nightmare without enumerating the subcomponents, but having hundreds of components for a project doesn't make any sense. Additionally, grouping projects doesn't do anything but put several projects into the same cosmetic space when navigating. Maintaining several projects is nightmarish when the prospect of synchronizing version numbers, SVN histories, release schedules, etc. between them. Please, please help those of us who are using JIRA alongside a long-term team-wide multi-project plan! Sorry that should be JRA-1538 and JRA-846 require support for subcomponents and cross project issue tracking. The issue of coordinating and tracking issues across projects (as noted above, a project may only be a current phase of work, while components live on) is an issue we see Jira as handling very poorly.
Is there any hope of addressing this issue? I'd like to echo on Matt's comment.
We are currently looking for a tool that integrates powerful issue tracking with project management functionality. Jira seems to come with the necessary features. However, we are a software company that highly leverages the component based development approach for our applications. The lack of possibility to share one reusable component among multiple projects, and to be able to run project management features such as time tracking and release note generation on the whole project tree, limits the planning capability to a degree where the whole functionality becomes almost useless to us. And with it, IMHO Jira looses one of it's main competitive advantages. My questions are the same as Jason's: This definitely gets my vote.
We use JIRA for keeping track of issues in embedded systems - both the software and electronics. One such product contains 3 pieces of software (application, bootloader, self-test), and 2 PCBs (motherboard, communications board), each of which has its own version label and components. Together they make up a single assembly, which has a corresponding assembly number. At present, each of these parts is a project in itself, which is not ideal - not least because you don't need many products being tracked on JIRA for the project list to become very, very long. Having sub-projects would tie together the various projects making up a product very neatly. In addition, we're currently experimenting with using JIRA to track errata in our documentation (user manuals, etc). Again, each document has its own version numbers, and possibly components (chapter headings or similar) as well. We produce a significant number of documents, which again could make the project list very long. The Categories function could help a bit with both these - but we're reluctant to spend $4000 to upgrade to the Enterprise edition for such a small change in functionality. why not generalizing this by providing a way to add keywords to a jira (like we can in confluence) ?
this could fit many needs, couldn't it ? Generalizations often also mean inferior interfaces.
For example, we're currently "solving" the problem by expressing our having hierarchical names, let's say: Input But since JIRA doesn't know the logic behind this, searching for issues in component "Input" doesn't find issues in component "Input: Keyboard", even though the user might expect this. You can add keywords all you like to a JIRA issue (use a custom field), but this doesn't really help in any way, because you don't get any logical relationship between the keywords. Note that project categories doesn't really work for solving this problem. We tried it when first importing our data, and there are quite a few problems. For example, when you search for items, they get grouped by project - which is logical if they really are projects, but otherwise just confusing.
Instead of sub components, would sub-projects be better? I don't just mean one level either, i mean many.
Oops, JRA-12241 has the details. – This comment originally posted in JRA-12241
In order to keep from confusing the users, we've had to oversimplify our components and projects - we were spending far too much time correcting poorly-chosen components previously. This solution has reduced frustration on the part of the users at the expense of the software team - very broad components (ex. "Appliance back-end or support processes" - this appliance has dozens of processes, daemons and jobs running on it) result in more accurate classification, but effectively make JIRA useless for tracking issues with specific pieces of software in a large system. Understand what this means: we cannot use this tool to help us plan long-term improvements to our product based on defect rate analysis without a painful, manual data-mining processes. Subprojects or subcomponents allow us to present the increasingly granular details of the product in a simple, logical fashion. They also allow a user to say "I don't know which of the subcomponents to pick, so I'll use the parent (general case) instead", while giving us the ability to properly classify that issue when we receive it so that we can properly associate a defect with a piece of software. Splitting the components across projects works (we did this originally), but it makes release management a nightmare. I agree that a single feature should satisfy most of these use cases. n-level nested 'projects' are fine, n-level nested 'components' are fine - it doesn't really matter what they're called, IMHO, just that this ability to organize hierarchically exists. The ability for a sub-project or sub-component to have multiple parents would be unbelievably good - it would satisfy the 'suite' or 'product' use case as well. In my case, I'd much prefer sub-components, even if it is initially just a single level of subcomponents. While you could probably achieve the desired functionality with sub-projects, logically it doesn't make as much sense. We have a single project in which we are updating multiple components and sub-components of our system. Ideally this functionality would include (in priority order):
This seems like a pretty seamless and simple extension to the exisitng functionality. Cheers. No, they're quite different. Sub-components provide for functional Forcing these fine-grained decomposed components into "projects" doesn't seem – I wouldn't want to be adding "version 2.0.1" to hundreds of Of course, if details like this could all be fixed for projects/subprojects, Hi Darren:
Sub-projects and sub-components are two different things, as others have touched on. I NEED sub-components, but I can do without sub-projects. Just my opinion on this. Obviously having both would be great. And properly nested issues, too. And... and... and... Adam, I agree that they are different. Sub-components would be very useful to us too. But, sub-projects would be sooo nice to have as well.
Hello Sam Craig,
I will very appreciate if you will update me with the details . Until now , the only solution I could find , is to create cascading custom field and define hierarchy of parent-->child , but in that case users need to choose component twice (one in Component field , and another time in the custom field I have created . Thank you , Stella Khosidov Amdocs Re " the only solution I could find , is to create cascading custom field and define hierarchy of parent-->child.." This isn't a real solution. Seaching in custom fields is a problem (see JRA-7686 ans JRA 6218) . Also you must have more rights to add new options.
The only solution is that Atlassian add this feature. We pay for the Enterprise version but we only get updates for the Standard version. I would like to see the following hierarchy as an option, with version ability at the Module level.
Project Some of our modules are pretty complex and we need to have a finer grain control. It would be nice to have this option on a project by project bases, just like you have with Sub-tasks being on or off. I know this isn't 1-N, but it would work for 98% of your customers and be a lot easier then 1-N to implement. Expanding the hierarchy would call for version control on components.
I'm out of the office until February 5th. If you require an immediate response, John McLean can be reached at jmclean@parasun.com or I can be reached on my cell at (778) 288-9982.
Thanks, -Matt ------ This is a copy of the message, including all the headers. Date: Mon, 28 Jan 2008 12:23:39 -0600 (CST) Tom Miller commented on JRA-846: I would like to see the following hierarchy as an option, with version ability at the Module level. Project Some of our modules are pretty complex and we need to have a finer grain control. It would be nice to have this option on a project by project bases, just like you have with Sub-tasks being on or off. I know this isn't 1-N, but it would work for 98% of your customers and be a lot easier then 1-N to implement. – I have voted for this - We have 2 developer groups that support over 50 applications each, and they really want to exploit JIRA for accurate reporting and issue assignment, but we can't do it under the limited 1 level components. They are strongly pushing for 1 project for each of their apps, which would become an admin nightmare - I hope this enhancement is put in soon.
The other workarounds are to use cascading select custom field, but that is duplication and no automatic issue assignment, or to just specify all possible component possibilities (1 and 2 levels) as a component, which would make the component list huge. This is my #1 enhancement request for our installation. I'm out of the office until February 5th. If you require an immediate response, John McLean can be reached at jmclean@parasun.com or I can be reached on my cell at (778) 288-9982.
Thanks, -Matt ------ This is a copy of the message, including all the headers. ------ Date: Tue, 29 Jan 2008 12:56:42 -0600 (CST) tmiller edited comment on JRA-846 at 1/29/08 12:55 PM: I would like to see the following hierarchy as an option, with version ability at the Module level. Project Some of our modules are pretty complex and we need to have a finer grain control. It would be nice to have this option on a project by project bases, just like you have with Sub-tasks being on or off. I know this isn't 1-N, but it would work for 98% of your customers and be a lot easier then 1-N to implement. was (Author: tmiller): Project Some of our modules are pretty complex and we need to have a finer grain control. It would be nice to have this option on a project by project bases, just like you have with Sub-tasks being on or off. I know this isn't 1-N, but it would work for 98% of your customers and be a lot easier then 1-N to implement. – Why not
Project (= product) Version product ( fi 5.0)
i add my vote for subcomponents. for me, it's critical to be able to assign developers based on server side, vs application side. otherwise, i can't figure out how to distinguish between the two and the accurate auto-assigning of issues is not feasible.
i've seen that alot of people are using a cascading select custom field. do you use the component, then subsequent sub-component on the issue sheet itself? thanks, I note that this is linked from the JIRA 4.0 requirements page ( http://confluence.atlassian.com/display/JIRACOM/JIRA+4.0+Enterprise+Requirements
 ) - does that mean that it will definitely be included in the fall/winter release this year? If so, (1) hooray, and (2) we will continue to buy support from Atlassian. The lack of an extra level beyond Categories, Projects and Components probably means that we won't be purchasing JIRA.
Sam,
Is the listener code available? This would be my #1 feature request for jira.
Given that it has a considerable number of votes (the 5th most of all open issues by my count) does anyone from Atlassian care to comment on whether / when it has any chance of actually happening? We discussed this during our team meeting yesterday and would like to have it as well. We are going to use JIRA to integrate with our time tracking system, and this would help us achieve greater granularity doing so.
Chalk up another vote for sub-components. I have a question for whoever is watching this issue...why is this issue not assigned to anyone? Isn't that the whole point of putting these issues in Jira in the first place? Is there any news on whether or not this is going to be implemented anytime soon?
Kevin
The issue is not assigned to anyone as the are no current plans to implement it. Notice that the fix version field is also blank. Once this issue makes the cut for a release plan then it would be assigned a fix version and then assigned to an engineer to implement. Until then we beg for more voters so it will creep up the list. I have been using Jira now for about 6 months so I am relatively new at this, so someone can correct me if I'm wrong about that. I find it equally thrilling and frustrating to see the list of popular issues for Jira. Thrilling to know that I am not the only one that needs this feature or that feature, but frustrating to know that issues like this one were created over 5 years ago remain unassigned without any clear indication when or whether they will ever be implemented. For this particular issue I created a custom field called "Feature" using a cascading select list where the first list mimics the component list and the second list breaks the components into features. It works well enough but it forces the user to enter the component twice, once for the component and again for the feature. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Support for subcomponents
