How to make a Jira field read-only based on status using Forge? (Pincode lock when In-Progress)

Question

Hi Team,

I’m building a solution in Jira using Forge.

Use Case

I have four fields:

* State (Text field)
* City (Text field)
* Pincode (Text field)
* Status (To-Do, In-Progress, Closed)

Expected Behavior

* When Status = In-Progress, the Pincode field should become read-only (not editable)
* When Status is anything else (To-Do / Closed), Pincode should be editable normally.

I would really appreciate any simple and practical workaround suggestions by using forge.

Geert __ 2improveIT · Answer

Hi @Paidipati_ Lokesh, You can do something like this in Forge and UIKit. Note: this is not tested and can contain errors. // TODO: Import required modules function Edit() { const context = useProductContext(); const [readOnly, setReadOnly] = useState(null) const [value, setValue] = useState(context.extension.fieldValue) const onSubmit = useCallback(() => { view.submit(value) }, [value]) useEffect(()=>{ const init = async () => { const result = await requestJira(`/rest/api/latest/issue/${context.extension.issue.id}`) const issue = await result.json() if(issue.fields.status.name === "In Progress") { setReadOnly(true) } else { setReadOnly(false) } } context.issue.id ? init() : setReadOnly(false) }, []) if (readOnly === null) { return } return ( {setValue(e.target.value)}}/> {readOnly && Edit is not allowed} ) } I have tried this scenario in ScriptGenie (disclaimer: I am the developer).

Germán Morales · Answer

Hi @Paidipati_ Lokesh , reach for UI modifications here. You point a jira:uiModifications module at the Issue view, and in its onInit and onChange handlers you read the Status field and flip Pincode with setReadOnly(true) when it equals In-Progress and setReadOnly(false) for To-Do or Closed. That is the whole behaviour you described, and the same module covers the create and transition screens too if you want it there.

The one trap is the field itself. UI modifications drives Jira's standard fields, not Forge custom fields, so it is clean if Pincode is an ordinary text custom field; if you built Pincode as a Forge field instead, UI modifications can't touch it and you would make that field's own edit component render read-only while the issue sits in In-Progress. Either way it only locks the input in the UI, not the REST API or automation, so add a workflow validator if the rule has to be airtight. The handler shape and the supported-field tables are in Atlassian's UI modifications guide.