Both, sort of.
JIRA doesn't have field level security. There are a couple that are controlled by permissions (e.g. you need schedule permission to be able to set or amend a due date, and you need assign permission to re-assign issues), but on the most part, if you have "edit" on the issue, you can set a field to any available value for it, at any point in the workflow.
There is some flexibility - you can set workflow properties to say "do not allow edit while in this status", or even "only allow group X to edit while it's in this status". But that's an issue level thing, not field.
The standard way to "protect" custom fields is to move it into the workflow. Let's say you want to protect the field "penguin", allowing only the user "Arnold" to edit it. If you remove penguin from the "edit" screen, no-one will be able to edit it at all. But you need Arnold to change it, so you add a new "transition" to your workflow that goes back to the same status, and has a "condition" that says "only Arnold can use this transition". You make the transition go through a screen that does have penguin on it, and you now have a protected-edit field.
There are other options - there's an add-on from Quisapps called "field security" which does enable all sorts of protections, and works well. You can also protect fields using Behaviours in the Script Runner add-on. (Generally, I'd recommend Field Security if it's something you have to do a lot of fields because that's what it's for, and Behaviours if it's only one or two fields, because the Script Runner lets you do lots of other stuff)
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
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