How shall I customize this schema?

[Jirong Hu]

Most of our projects are using a standard workflow schema which is designed for development teams, e.g. DevSchema. Now business users from one of the project (this project already has a JIRA project based on DevSchema) wants something different (the requirements as follows). What's the best way for me to achieve this? We are thinking about making a copy of DevSchema and modifying it. What should be changed and what's the exact procedure?

Issue Type - Auto default to request

Remove Tabs:

• Optional Details
• Resolution Details
• Suspension Information
• Attachment

Remove Fields in Main Tab:

• Business value
• Dependencies
• Persons to notify
• Epic Link
• Due Date

Change Fields in Main tab:

• Request type – Change to drop down menu with pre-populated with options we choose

Add to Main Tab:

• Start Date/End Date
• Time Spent on request
• Request Complexity rating – Drop down menu (1- simple to 5 – complex, difficult)
• Resolution Box
• Attachment Box – Basically move the attachment option to the Main Tab

[Nic Brough -Adaptavist-]

I'd start by looking in the right place.  This appears to be related to fields and screens and nothing to do with workflow.

Re-reading that, I suspect I sound grumpy and pedantic, which is not really the way I feel.  I just want to be clear that workflow and fields/screens are very different things when we are talking in Jira-language, and I dont' want to get it mixed up.

The documentation you need to start with is https://confluence.atlassian.com/display/JIRA/Configuring+Fields+and+Screens - this covers most of the "exact procedure"

But I'd like to add that your instincts about "make a copy and modify it" are absolutely right.  That is, by far, the best way to approach this.  Copy the schemes you want to change, and apply them to the new project - that gives you complete independence from the original project, so you will not break it while you try to get the new stuff right.

[Jirong Hu]

I can't format it properly here, so put my further question in the Answer section.

[Jirong Hu]

So the procedure will be like this?

1. Make a copy of Dev issue type schema, modify and save as Bus issue type schema. Delete most of other issue types we don't need in this project.
2. Make a copy of Dev workflow schema, modify and save as Bus workflow schema.
3. Make a copy of Dev Field Configuration schema and modify according to https://confluence.atlassian.com/display/JIRA/Configuring+Fields+and+Screens#, save as Bus FC schema.
4. Create a new project using the above schemas.

[Nic Brough -Adaptavist-]

Yes, you are spot on!

[MattS]

Scheme not schema. I know, the terms are confusing!

[Jirong Hu]

Thanks, never noticed that.

[Jirong Hu]

I just found out this project is used by business users only, no developers. So now the request is just want to make some changes to the existing project, but this change shouldn't affect other projects, therefore still need its own schemes for the changes. Looking the changes, I think I just need to create a new screen for the Request issue type and a new Screen scheme for this project to use this new screen. Is this right?

[Nic Brough -Adaptavist-]

That is correct. As you said before, you can copy the current scheme to a new name and associate it with the project you want to alter. Then, because the copy is only used by that one project, you are safe to re-arrange it, because it will only affect that one project. Just remember that this principle cascades through the layers. You are going to be editing screens, so you need: - A new "issue type screen scheme" for the project you want to change - One or many new "issue type schemes" (the "issue type screen scheme" may specify several of these) - One or many new "screens" for use in the new "issue type schemes" (This is complex and feels messy, but it is very powerful too, that's why it's complex)

[Jirong Hu]

Thanks a lot for your helping. I think I got the principle now. But if I am still using the same Request issue type and there is no change in the workflow, I don't need a new "Issue Type Scheme", right? I just need a new screen for the Request, and a new "Issue Type Screen Scheme" to use that new screen?

[Nic Brough -Adaptavist-]

Correct again, yes. You only need a new scheme if you want that part of the project to behave differently. If the list of issue types is the same, reuse the scheme - only split when you have a need to!

[Jirong Hu]

Thanks, Nic. I have some further question regarding the detailed changes. 1. They want the Start/End Date and Time Spent on request. Shall I use the Log Work and Time Tracking together to achieve/replace this? However, after adding Log Work and Time Tracking , the Estimated field says: Not Specified. How shall I add this? 2. How can I move the Attachment field into the Main tab? Is it a good practise?

[Jirong Hu]

3. For the Request Type list, they want to use their own list. I can't find a way to create a new list to associate it with this field. Do I have to create a new custom field to achieve this?

[Jirong Hu]

4. After I remove "Business Value" field, I got an error says "Business Value" is required. I figured the field is Required in the current Field Configuration. So do I have to create a new Field Configuration? If so, I guess we'd better resolve this kind of discrepancy at the process level to make them more aligned.

[Nic Brough -Adaptavist-]

1. How are you defining Start/End date? For time spent, yes, use the work logs. Doesn't matter about the estimates, the work logs will still add up time the users log 2. You'd hack code, and no, it's a bad idea because the attachments section is quite large and it would mess up the display unless you were really careful 3. What's the request type list? 4. Yes, that's the field configuation scheme - you'll need to create a new one for that.

[Jirong Hu]

1. Don't know, guess they just want to record the Start day to working on this issue, and End day to resolve it. I guess we can convince them using the standard fields available (Created, Updated, Resolved), plus the Time Tracking "Estimated, Remaining, Logged". I found the Estimated time will be entered when creating the issue. 3. The list contains "Technical, Process, Business", I guess this is a custom field then, so I have to create a new one? Thanks again.

[Nic Brough -Adaptavist-]

Yes, that's always a bit of a problem - your users will say things like "start date" without really understanding that it needs a clear definition. I'd ask them to be precise - does start date mean "issue created", "issue enters an in-progress status", "issue is triaged" etc. Once you know that, you can nail it to a point in the workflow. You'll want to do the same with "end date" For 3, yes, I'd say that's a custom field. You could try adding a new context to it instead (a context lets you say "for project A, B, C, use list 1, and for D, use list 2". That would generally be better for the users because it remains one field when they search.