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 Fields in Main Tab:
Change Fields in Main tab:
Add to Main Tab:
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.
So the procedure will be like this?
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?
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)
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?
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?
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.
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.
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.
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.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG