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

Can we validate that field cannot be changed until it reaches certain status?

Adrian Szubert

Hello Community

Quick question, same as in the subject.

I have a field that is related to automation - although users tend to forget update JIRA issue status before providing value to the field that triggers automation.

Is there any way to validate "Story in Status A cannot do anything to Field X, but the story in Status B can update Field X".

The only thing I can find is an article on how to create a prompt to validate a field, but this is a bit the other way around.

Thanks!

Accepted answers

Trudy P Claspill

Hello @Adrian Szubert

You could use an Automation Rule to detect that the field has been changed. In the rule you would then check the current status of the issue. If it is not in Status B you could use the rule to revert the field to its former value.

Using the Field Value Changed trigger gives you access to a special smart value - fieldChange - that will give you access to the value of the field before it was changed. You can use that to reset that field to its former value. The exact method you would use to revert the field depends on the field type.

Aditya Ojha

Hello @Adrian Szubert ,

There is a workaround that should work.

1. Remove the required field from the screen associated with the 'Edit' operation. If all the operations (create, edit, view) are using the same screen, you might need to create a new screen for the edit operation and associate with the screen scheme for 'Story' -> Jira Screens Documentation. Removing the field from the edit screen ensures that it cannot be edited normally.

2. Create one more screen that contains the field(s) in question, that are supposed to be edited in particular status

3. Go to the issue workflow, and add a self-loop transition (source and destination statuses) are same. You can name this transition something that the users will understand for example, 'Edit Field X'

4. Associate the screen created in step 2 to this self-loop transition. When you associate a screen to a transition, it appears when the users perform the transition, hence it can be edited then. If required, you can conditions to this transition so that only specific people can perform it. Jira Workflow documentation

Thank you.

All comments

Trudy P Claspill

Hello @Adrian Szubert

Jason Krewson

I don't think that is possible out of the box, you can use validator to require fields when transitioning to a new status, but like you mention you are waiting the other way around.

A work around I found was posted by @Taranjeet Singh at the below link;

https://community.atlassian.com/t5/Jira-questions/How-to-show-custom-field-in-specific-statuses-only-hide-the-rest/qaq-p/1816591

Another good reference would be this;

https://community.atlassian.com/t5/Jira-questions/Prevent-users-to-edit-field-in-a-specific-status/qaq-p/1867467

Hope it helps!

Aditya Ojha

Hello @Adrian Szubert ,

There is a workaround that should work.

2. Create one more screen that contains the field(s) in question, that are supposed to be edited in particular status

Thank you.

Trudy P Claspill

@Adrian Szubert

Are you working with a Team Managed project or a Company Managed project?

The suggestion to use a looping transition with a transition screen can be used only with a Company Managed project.

Adrian Szubert

Unfortunately, we use TMP. Therefore, there is no option to display the field in JIRA only when it reaches a certain status.

The automation idea is good but does not serve a purpose here - setting this field to a certain value will trigger another automation. Reversing the change with automation will cause more issues, than good

Adrian Szubert

Hello Aditya, thank you for your answer. I will accept your answer, but mentioned that it can be done in Company Managed Project, so other can later on see this solution :-)

Welcome!

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

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

jira

cloud

jira-cloud