1) You mention being able to control what components are displayed based on what release is selected, but you also mention using a custom field to do this. Component & Release are built in fields - in 2.7 can these fields (component & release) be made to be 'dependent' on each other - so you can display a different set of components based on what release is selected?

2) In the interest of making reporting easier I'm trying to make every custom field a cross-project field. However, I run into problems when the field needs to be required for certain projects and not required in others (at times not visible). Is there a way in 2.7 to adjust the required flag for a field based on project? If not then do you have suggestions on how to do this?

3) It sounds like it will be possible to relate fields and have the contents of one be dependent on the contents of another. It would be nice to have the select lists of a field, required or not, be based on the project the issue is in. Example - having a system wide field 'Milestone' where the list of available milestones to select from varies by project.

Thanks.
-wc

To answer your questions:

> 1) You mention being able to control what components are displayed based on what release is selected, but you also mention using a custom field to do this. Component & Release are built in fields - in 2.7 can these fields (component & release) be made to be 'dependent' on each other - so you can display a different set of components based on what release is selected?

It won't be possible for the component list to differ for each version. Nor do we currently have the ability to display fields differently based on workflow step.

It is possible, with some custom hacking, to limit the set of values displayed in a field based on the workflow state. So you could have a custom field called "component" containing components across all versions, and then override the getComponents() method to only return a subset based on the workflow state. Let us know if you need help doing this.

> 2) In the interest of making reporting easier I'm trying to make every custom field a cross-project field. However, I run into problems when the field needs to be required for certain projects and not required in others (at times not visible). Is there a way in 2.7 to adjust the required flag for a field based on project?

You should be able to do this in 2.6 Enterprise, with field layout schemes per project.

> If not then do you have suggestions on how to do this?
>
> 3) It sounds like it will be possible to relate fields and have the contents of one be dependent on the contents of another. It would be nice to have the select lists of a field, required or not, be based on the project the issue is in. Example - having a system wide field 'Milestone' where the list of available milestones to select from varies by project.

There isn't support for this yet (I think it is an open feature request). Again, with custom coding it could be done, in a very instance-specific way.

I'm going to strip most your comments out and address them 1 by 1:
1) I'm not worried about changing the list based on workflow step. I'm primarily interested in being able to control the list of displayed components based on selected version. Please reference the forum posting (reply) by Scott Farquhar, Tuesday, June 01, 2004 11:23 PM subject "Parent/Child related fields":

SF:Custom fields are much more configurable in JIRA 2.7, so you can have a custom field which depends on other parts of the system.

SF:You could have a custom field that is two drop-down values, and stores the value(s). Or alternately, you could have a custom field that checks what release you are in, and display different components accordingly.

I'm guessing that there's a disconnect on 3.0 Enterprise delivered functionality - and that your previous comment on this issue above is what will actually be delivered.

Given that please explain if the custom 'component' field will be displayed in a separate drop down or if it will simply be used to populate the system field 'Component' (multi-select box). I'm guessing the latter.

Does the 'getComponents' routine you mention operate on the client side in java script?

2) After playing around with field layout schemes I determined that I could do this already, as you explained, in v2.6.1. This is good.

3) A better description of this problem is the following: In TestDirector there are drop down fields which display a 'treeview' of components, where each component has 0 or more 'child components'. What I'm seeing we'll need is a child field to the component list that will limit it's contents to the selected parent component. I know that currently the component field is a multiselect - we'll change it to be a single select. I haven't looked at the 'getComponents' routine but I can guess how it works. Is there a similar routine for getting the contents of a custom field that will operate on the client side after the user selects the parent component?