Where do custom fields store their data?

[Jim Stewart]

I somewhat inherited a Jira setup. As per the attached, you'll see that in this rule, if an issue is opened with certain employee types and locations, it will assign it to me (as a test.) But I have not been able to figure out where either Employee Type or Location are pulling their date from. I can find both of them in Custom Fields. But I cannot figure out, for example, to see the list. Let's say I wanted to change Salaried: FT to Salaried: Full Time or add some other employment type. Where would I find the ability to do that?

[Daniel Ebers · Accepted solution]

Hi Jim,

if I get you right the question in this step is just about where the options for a custom field are configured. Please find those information in the following article:
https://support.atlassian.com/jira-cloud-administration/docs/edit-a-custom-fields-options/

I could think of a more unlikely scenario where they are pulled from some other system (through an App, maybe?) but first I'd kindly ask you to review if those are simple values to a custom field.

Please let us hear from you if you found the values to the custom fields using the guide linked above.

Cheers,
Daniel

[Jim Stewart]

Well, in the interim I think I figured that out. Maybe. Here's where I am now. Essentially I'm trying to test a rule. One of the choices in the rule is Employee Type. (There is also an Employment Type but I don't want that.)

When I go to Create Issue to test the rule, Employment Type pops up but not Employee Type. I clicked on 'Configure Fields' and then 'Where is my field?' it tells me all is good and the custom field 'Employee Type' should be on this form. But it is not. I've looked at it 100 times. The one that IS there is 'Employment Type.'

So Jira tells me all is A-Ok but it's not. What am I missing?

[Daniel Ebers]

It seems to me the custom field you are looking for is missing an appropriately set context and/or is set to a specific project and/or issue type.

Could you please double check the custom field 'Employee Type' for context configuration?

https://support.atlassian.com/jira-cloud-administration/docs/edit-a-custom-field-context/

In case it does not make any sense to you a screenshot would be perfect here to be put in, so somebody can have a look at it.

[Jim Stewart]

It does make sense. I'm still not there but I think I'm getting closer. You'll see the Employee Type custom field in the screenshot 'Employee Type Custom Field.' Those are the exact values I want to show up in Create Issue and then to be pulled in by the rule. 

I then went into Edit Configuration and I'm supplying two screenshots because it did not fit on nne. I then went into Edit Context but that gives me the exact same screens as Edit Configuration so I am puzzled by that. (In Edit Configuration, I did make sure it was applied to People Ops project so that was a modification.)

Alas, when I go to Create Issue it continues to tell me that the Employee Type is on the form. It is not. Nothing has changed. I still see Employment Type. 

[Daniel Ebers]

This is a bit hard to debug without access to the system - but nevertheless.

On first sight I'd say there still needs to be an appropriate screen scheme assigned to your project while there is still a wrong one assigned (or a non-matching screen is assigned to the screen scheme). That would answer why you still see a field which you do not want to see but it will not answer why the "Where is my field?"-helper is telling the field is there - somewhat confusing!
Is there any probability that the field is on the screen - but in a second tab of the screen (in that case the theory that the screen/screen scheme needs still to be change can be neglected)?

[Jim Stewart]

I'll take a look. I'm in kind of a weird position. I'm doing work for the customer but using my own personal Jira account to ask questions. Don't know if he'd be cool with letting the instance by seen by anyone outside the company. Maybe, I suppose if we keep hitting roadblocks. 

[Jim Stewart]

Ok. I got it. The wrong screen (or screen scheme) was associated with the project. I fixed that and it worked as advertised. I think one thing that threw me off was this:

We had changed the name of the project somewhere during setup. (This is all pre-production BTW). So the original key was DHSD and then it become PPLOPS. I think the key is now back to DHSD. So what to do about the key? Any reason we can't make it PPLOPS again and then make sure we're using the right screens?

Also, can you point me to the doc that details screens and screen schemes and their relation? I find it all very confusing. But thanks, great job. 

[Daniel Ebers]

The keys are just naming - important is that screen schemes/screens and projects match. From the project names I could not unclutter this just in mind - you would probably need to go through the whole configuration in a quiet minute.

For the relation screens <-> screen schemes it is not so complicated. I like this article because of the graphical representation - it explains the relationship very well.
In the official documentation there is also such graphical representation.
Here is the portion for cloud that goes more into detail:
https://support.atlassian.com/jira-cloud-administration/docs/what-are-issues/

[Jim Stewart]

Thanks much