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

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.

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.

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.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Accepted answers

All comments

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?

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.
Make a copy of Dev workflow schema, modify and save as Bus workflow schema.
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.
Create a new project using the above schemas.

Nic Brough -Adaptavist-

Yes, you are spot on!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration

field

screen