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; } } }

Lock fields after adding data

Francisco Navarro_zsedh7

Hello community,

I'm struggling with an automation and I hope you can help. I have 3 date fields and 3 text fields. What I'm trying to do is prevent them from editing the value after entering data.

Currently, I've only managed to keep the data and return it to the original value if they enter something. Then I set up conditions based on "IF" and "ELSE" to go through all the fields, but now it doesn't do anything

I've attached images of the rule so you can better explain what I built and help guide me toward a solution. error automation3.png error automation2.png error automation1.png

Accepted answers

All comments

Marc -Devoteam-

Hi @Francisco Navarro

You can't lock fields.

What you can do is of these fields are filled in on creation, create referenced custom fields of type read only.

Then in automation based on issue creation copy the values of these fields to the custom fields and show these fields on the edit/view screens and not the initial fields.

Francisco Navarro_zsedh7

Hello Marc,

What I managed to do was "revert" the value of the modified field to the original. While this doesn't comply with the concept of "locking" as such, it helps users know after the announcement that after entering a piece of data once, they won't be able to change it again.

The problem started when I added more fields because it recorded the first changed field and then copied that original value to another field that had been modified, from the list of fields we specified.

Marc -Devoteam-

Hi @Francisco Navarro

That's why i provided this solution.

Use read-only text field to copy the initial value to and remove the fields from the screens, so that they can't be seen and/or edited.

Darryl Lee

Using Automation to revert fields that users are "not supposed to touch" is a pretty horrible user experience.

User: "What? Why did it change my field back? What is happening!?"

A better solution is to prevent editing of fields during particular statuses.

The way to do this is with Workflow Properties, a slightly arcane Jira Admin topic. Here's the official documentation:

Use workflow properties

And a great tutorial on it from @Bogdan Gorka:

A smart way to disable issue editing using workflow properties

And lastly, the great grand-daddy of resources from @Jobin Kuruvilla [Adaptavist]:

J-Trick's Permissions based on Workflow Status

The property you would want to set for Statuses where fields should not be edited is:

jira.issue.editable = False

Francisco Navarro_zsedh7

Thanks!

I'll check out the instructions you shared with me.

Marc -Devoteam-

Hi @Darryl Lee

I know about these options as well, but this would cause any field of the issue to be not be edited anymore in a certain status, not just some fields, correct?

Darryl Lee

Correct - it locks editing for all fields.

I think this didn't used to be such an issue before Atlassian introduced inline-editing in JIRA 5.1, because people had to go to the "Edit" button.

Anyways, for workflows that do require a bit more ... compliance, it always made sense to me that specific field changes be contained within specific Workflow steps and screens.

But yeah, Atlassian does not really advertise these properties nor make it obvious that you can do it.

(Haaaaaa, I bet the new Workflow Builder Agent does not know about Workflow Properties, @David Berclaz _Apwide_ )

Welcome!

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

Quick Links

Find more posts tagged with

custom-field

jira-software-cloud

automation

rules