How to offer a field only to specific issue keys

[Tobias]

Hello guys, 

I am currently thinking about if there is a possibility to limit a field on a screen to be presented only on specifc issue keys. 

We have an issuetype called "Test", which was created about 200 times. 

Now I want to have the possibility to provide a specific field only to the issue keys Test-1, Test-3 & Test-4.

I am not sure if this is possible because adding it to the screen would lead to an offering to all issues existing and new ones. 

Maybe there is a possibility with Scriptrunner. 

[Radek Dostál]

Well, you can do basically anything with scriptrunner, but that doesn't mean you should - the use case goes against Jira's design principle (which may sometimes be arguable).

Probably the easiest way to do this would be with behaviours, probably along the lines of:

// This should refer to Edit screen specifically, 
// because Create would be non-null as well as any other transitions
if (getAction() == null) {
  String[] issueKeys = new String[]{"Test-1", "Test-3", "Test-4"}
  String issueKey = underlyingIssue.getKey()
  if (issueKeys.contains(issueKey)
    getFieldByName("My Field")?.setHidden(false)
  else
    getFieldByName("My Field")?.setHidden(true)
}

If I recall correctly you cannot hide fields from Issue View, so this assumes other issues do not have any values.

This doesn't do anything about the Create action, or workflow transitions. Need to implement separate getAction() conditional blocks for those.

This is just an example on the spot, think it looks correct but not totally sure about setHidden()

Before trying anything like this, I would still urge to rethink the use case behind this. This is not scalable, not with the issuekey array growing, and will get you to administrative hell trying to troubleshoot something later on when you start introducing magical issue keys.

It would probably be a lot simpler to add a description to the field akin to "Only used for .. and y ..", since you don't see empty values on view. No hidden stuff to keep track of and continually provide maintenance for.

If you must do this it would be better to switch to other conditions than magical issue keys, at least, such as issue type or other field values.

[Tobias]

Hi @Radek Dostál

I already thought about putting the field on the mask, but it is a select field. The default value is yellow (field for a project status). As it only refers to certain projects (in this example the same as activity types), the customer asked me whether it is possible to restrict the field to the issue key.

The setting is currently 10 issue keys and I would map the issue type of the request in the description of the behaviour for traceability.

I just thought about setting a lable like "Tracing projectstatus" and set this as a condition for a transition called "Light status" where I can provide the fields. That would lead to the same solution I think but without customizing Jira that much. 

I am very unhappy with the solution myself but my hands are almost tied here. What would the query look like if it were not just one field but several?

[Mark Segall]

Hi @Tobias - You are correct that there's no way to limit fields to specific issues.  You could create another issue type/screen for those specific issues or look into a Scriptrunner behavior.

[Tobias]

Hey @Mark Segall 

what would you suggest? 

I thought about two possible solutions: 

1. Adding a behaviour like @Radek Dostál mentioned above 
2. The users want to have the possibility to edit the light status at every time. That means that from my end I would add transitions to every status itself and add a condition which includes the issue keys of the desired issues. Than I would add a screen with the mentioned fields. 

What would you prefer or do you have another solution?

[Mark Segall]

My thought is that the simplest approach is to create a new issue type/screen for those specific issues.  They can share the same workflow as your Tasks to reduce administrative overhead.  It's also scalable.