What is the best practice for collecting field level data for an issue?

[djjay0131]

I have several different practice areas using JIRA for issue/request tracking and support. Each of these areas may have several types of issues they'd like to collect, and each one has different data fields. I started creating custom fields for each, but my list is starting to get very long and tough to manage. I was wondering if this is the best way to continue building out these new forms, or am I bending JIRA away from what it was intended?

For example, one manager would like a status report issue type, it's got about 10 new fields. Another manager is looking for Environement request issues, 25 questions to fill out.

Some of the info I'm sure can be used for reporting and those I know should be in the issue but if it's just informational, is there a better way to collect the information?

Since I can't comment on my own issue, I'm going to just edit it. Neither of the response to this question directly answered my question. However I was able to et an answer from the Summit. Basically it is perfectly acceptable to create more fields as needed, and there is not currrently an alternative way to collect info on an issue w/o creating extra fields. I only wish the user interface was better.

[djjay0131 · Accepted solution]

I was told at he Summit that this was an acceptable practice

[AgentSmith]

If you haven't already, I recommend exploring Screens because it presents information in a relavant way to users based on workflow transitions. From our documentation:

Screens group all available fields (or a subset of all available fields) defined in JIRA and organize them for presentation to a user. Through screens, you can control what fields are displayed to the user during issue operations (e.g. Create Issue and Edit Issue dialog boxes) or workflow transitions (e.g. Resolve Issue dialog box), as well as define the order in which these fields are shown to them. A screen also allows you to split subsets of fields across multiple tabs.

More info available here:

https://confluence.atlassian.com/display/AOD/Defining+a+Screen

As well as:

https://confluence.atlassian.com/display/AOD/Configuring+Fields+and+Screens

https://confluence.atlassian.com/display/AOD/Configuring+Workflow

Its a bit of info to absorb and its recommended you run through this a few times to ensure the behavior is working to your satisfaction (either in a test instance or by working independently in a test project for example).

Hope this helps and good luck to you!

[Rahul Aich [Nagra]]

Hi Jason

If I were you, i would question the need for additional fields from the stakeholders. If someone is asking for 10 new fields, it is highly likely that you already have a similar field to satisfy his needs.

And in case you have then you do not need to create a new custom field for him. You can re-use an existing in-built field or a pre-created custom field.

The way you display different list of fields for different projects is via screens. In the screens you define the list of fields you want, then associate that list of screen with issue operations such as create issue /edit issue/view issue (through screen schemes). You then associate the screen scheme with issue types sauch as bug, tasks etc (via issue type screen scheme) . Finally, issue type screen shcmee is assocated with your project.

This is the approach you would need to follow if you want to display customised views per project.

Coming to the issue of creating multiple custom fields, it does not affect performance of JIRA in the newer jira versions. I know for sure perforance was an issue with custom fields in the earlier versions. What i would recommend you is when you create custom fields, you restrict its visibility by controlling it from the custom field context and not by screens. What i mean is when u create CF's you do nots select the option - apply to all projects but only the ones you want it to.

Hope this helps

Rahul