|
History
| Log In
|
|
|
|
HI Mark,
The component field only really differs from other fields in that you can set default assignees against them and that there is a tab available for the field in browse projects. So if you do not use these components for these purposes it is possible for you to implement a global custom field so that all projects have the same component options. Thanks, That's a nice workaround if the components really stay the same. Perhaps it is sufficient for me.
But what I really want is to have the chance to remove and add components in later versions as can be seen in the example:
If using your suggested workaround (and if I got it right) it will lead to components A, B, C, D in every version. In our situation it would result in a huge scrollbar to browse through all components and meaningful component-names so that deprecated names won't be selected in newer versions. When I was first evaluating JIRA, and before I knew about components, I created a custom field for effectively the same purpose. It worked well except for a few areas. In my opinion, using components is better in the long run for the project and worth the extra setup required to create them for each project. If you create a custom field that is the equivalent of a component, or module, you probably want it to be a multi-select list, rather than a single select list. By default, one can assign an issue to multiple components, so I assume you would want to keep that functionality. However, the ability to sort, search, and filter on such a custom field is more limited than the built in abilities that JIRA provides with components. For example, try sorting your issue navigator by the custom components field. Aside from the specific features Brian mentioned, all of JIRA is more geared to use them more readily than a multi-select custom field. So, for example, when you want to create a 2 dimensional portlet on your dashboard with components on one axis, it'll work and generate an accurate count. You probably won't get the same functionality from a custom field. So, aside from just cosmetics, I'd say to stick with components since you're leveraging all of JIRA's built in functionality that so many people already use. And you get those pretty puzzle piece icons. and you already mentioned what you perceive as a problem when you want to stray from the rule where all components are the same for each project anyway. Well, that's my 2¢!
Hi Mark,
If you will be creating and removing components for particular projects/versions on a regular basis then the above workaround will probably not be too useful. Options in the custom field will be available across all projects, so you will have little control over the size of the select box. Please note though that the sorting and use of portlets with the custom field should be no different than with the component system field. The main difference will be seen in the reports. Thanks, Brian,
I am no longer with the company where I originally implemented this, but to the best of my recollection, one could not sort the issue navigator by a multi-select custom field ( The functionality to sort on Multi Select custom fields has been added in JIRA 3.3. Neal, thank you for pointing this out.
The only problem now is JRA-8124. Hopefully this issue will not cause too many problems until we fix it. Thanks, Hi
I want to comment on this issue because quite many Jira users have asked me the same question: Isn't there a way to copy components from one project to another and I have to give the answer: No, unfortunately not. Why is this relevant to us? It is because all our customer projects are based on our own base software products. That is, it never happens that a project just delivers a software product to a customer. Rather, all software delivered to customers is project specific - however it is always based on our underlying software product. And all development of our software product happens through the projects. So if a projects includes a new feature that would be advantageous to add as part of the software product then the project shall update the base software and release it. Afterwards the project can use the updated software product as base software. In Jira we have reflected this product strategy by having a Jira project for each project and two Jira projects for each product. The reason is that we often have ideas for new features or implementations for the software products or we may find bugs that are not relevant for the current use of the product but they may become important later on. All such issues are registered in an Archive Jira project. Here all issues that are not worked on at the moment and those issues that have not yet found a sponsoring project are stored. The other Jira project for a product is the "active" Jira project that contains all issues that are not "archieved". This is no problem as it is so easy to move issues between the two projects. However, it is annoying that we have to manually create the (almost) same set of components over and over again whenever a new project is realized or when we create a new couple of Jira projects for a new software product. I imagine a functionality where it is possible to select "Select Components from existing project". This can lead to a scroll list of the union of all components defined in the Jira installation. A more elegant solution would be to let the user select among the existing projects - having selected a project the scroll list should include all components in the selected project. It is important to emphasize that a solution where it is only possible to copy components when a project is created does not really fit our needs. We would really like a solution where a component can be copied at any time from the "Add component" functionality. Best regards I'd just like to add my $.02 on how valuable this sort of feature would be.
Like one of the other posters, we find it MUCH easier to manage multiple releases of a product by having a distinct Jira project for each release. Thus we create new projects that are, in a sense 'clones' of an existing project all the time. Not only does this model make for more finite issue views in order to understand just what is/is not in a release, it also enables deferment of issues. I feel that this is a natural way of doing product change management because in each case it also maps to a specific development branch in our revision control. The only negatives to this is the housekeeping involved with copying existing components over to the new project and having to manually set various project attributes like the CVS repositories, workflow scheme, etc. It would be cool for Jira to recognize the branching/merging aspect of product change management by having a 'branch' feature that clones all project attributes, copies/shares selected components, and then provides a means for bulk Move / Clone of selected issues from the parent project to the new project. And yeah, the same functionalities need to be available for copying/sharing components and cloning/moving issues between already existing projects (thus recognizing the 'merge' aspect of product change management). There is a way to import components into new project by using Bugzilla. You can Import a default project from Bugzilla into Jira.
An other way is use a CSV file (from a Bugzilla of a project ) and import this in Jira. The best way is, make this option availlable in Jira. The only thing what is needed is export function for 1 project and import functions like bugzilla import. (this solve also other issue's) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Add a feature to copy/paste components between projects
JRA-501andJRA-6999.