Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to unlock the Sprint Field?

Hi, 
I want to make Sprint field mandatory for one of my projects, and I don't want to create a separate workflow for it.
So what I did was create a new field configuration and field config scheme and associated them to that project.

However, the problem is that the field I want to make required is 'Locked' and I can't edit it?

Can anyone help me out with how to unlock or make this field required? 

Many thanks in advance,
Tayyab 

2 answers

1 accepted

1 vote
Answer accepted

Don't do it with unlocking - the field is locked for a good reason and even if you unlocked it, changed it and re-locked it, you could cause yourself all sorts of problems.

A better option would be to simply use a validator in a new workflow.  I know you've said you don't want to do it that way, but the unlocking option is a vastly worse way to do it.

(Oh, and if you write a validator that says "if project != X" then exit true" on the first line before checking the sprint value, you don't need separate workflows)

I found this document on how to unlocking the custom fields: https://confluence.atlassian.com/jirakb/how-to-unlock-a-locked-field-779158866.html


But the problem is that these fields are locked again once the JIRA is started again. 

Could you please elaborate on the third thing you said about writing a validator? 
Can I add a condition like this on the workflow? Or are you suggesting to write a separate module?  

That's one of the reasons I told you not to unlock the field - it is locked for a reason and you really should not do that.  Unlocking fields is for correcting errors, it's absolutely NOT for what you are trying to do here.

Validators and Conditions are different things, but have some similarities.  You can use almost the same code for them as they ask a simple question - "does the data match X".  If it does then they return a success, if it does not, then they return a fail.

A condition that fails prevents a transition appearing for the user.  They can't start a transition, it won't be offered to them.

A validator kicks in when a user tries to commit a transition.  If it fails the test, it returns the user to the previous screen (where they clicked the commit) and (ideally) tells them why it failed.

Now, there are already validators available that can check the sprint field (in the JIRA Suite Utilities add-on for example), but they are plain "check field is filled" validators.  If you want projects or issues to do different validations, you will need to use different workflows (e.g. in project ABC, you want the Sprint field optional for Bugs, and mandatory for moving Stories to "in progress", you will need two workflows.  The bug workflow will need no validators, but the story workflow will need them added)

If you don't want to have multiple workflows, you will need to write some code.  A validator module is not hard to write, although I'd use the Script runner to avoid having to do any add-on work at all.  You can take the simple "check if field filled" code and wrap a "if project/issuetype = X, Y or Z" block of logic around it.

Okay thank you for the suggestions Nic. 

I think the most easiest way would be to add a behavior using Behaviors plugin and map it to a single project. this way only one project gets selected and you can chose which fields you want to make it appear required on.

Do you know anything about why are these fields locked in the first place?  

Behaviours would work too, saves you writing all the code.

The fields are locked because you are not supposed to be doing things like that with them, and the lock prevents bad configuration being done to fields you shouldn't mess with.

Doing this with a behaviour or a validator is not a problem because it doesn't directly affect the underlying data

(Although it does make it a right royal pain for the users if you can't create issues without a sprint, and breaks the whole principle of planning and scrum, but that's a different question)

I want to remove Sprint field from Epic issue type ... how would I do that?

No, you don't.  That would break parts of Jira Software and some related apps.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Asked in Jira Service Management

JSM June ask me anything (AMA)

Hello Community members! We’re wrapping up the end of JSM June with an Ask Me Anything (AMA) with the Jira Service Management product team. This is your chance to ask all your ITSM questions to o...

262 views 13 14
View question

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you