Ideas for setting fields via API that are not on the edit screen

[jeremyn]

Hi All,

So we are in the process of migrating some data into Jira from another system. I've got a script running that will be able to set the field values, however it can't set them at this point because these custom fields are not on the Edit screen (yet).

Why don't I want to just add them to the Edit screen? Because there are data for thousands of issues in the external system and I want to prime the values before adding them to the screens. Plus we have many hundreds of users and I know from experience if I add anything to the edit screens they will instantly start setting them and then when the script runs and primes the data they will all complain that the data got corrupted.

I tried overrideScreenSecurity  and that doesn't work for API from a script (I'm a org admin and used an api token from my org admin account).


So my goal would be to prime the data, validate everything is good to go, then expose the fields on the issue.

Looking for any ideas of suggestions on how to be able to prime this data w/o exposing the fields to all these user who will definitely mess with the fields before they are supposed to. 

[Robert DaSilva · Accepted solution]

Hi @jeremyn 

You're correct, a field needs to be visible and editable on an issue screen for it to be updated via the API (and the GUI). 

I originally thought we could add the custom fields to any applicable screens before you import, and then remove them afterwards, but I can't seem to find a method on the API docs that remove fields from a screen. So instead we can try to swap screens before and after import. This will require a bit of preparation, however.

Here's what we'll need to do:

• Collect a list of all Issue Type Screen Schemes, and their associated individual Screens, that are related to the projects and issue types you're trying to import data into. Record the Issue Type Screen Scheme ID value, and the Project ID value for the pairing. Each project will have a unique ID, and a unique Issue Type Screen Scheme assigned.
• Create a new Issue Type Screen Scheme, and individual Screen, that includes every single custom field that you need to import data into. You may want to do this on a per-project basis, depending on how much the issue data overlaps. Record the Issue Type Screen Scheme ID.

Then, in your script, do the following:

1. Call the "Assign issue type screen scheme to project" method to assign your "bulk import" Issue Type Screen Scheme to the project or projects you are importing data into.
2. Execute your import as normal.
3. Once the import is complete, call the same "Assign issue type screen scheme to project" method, and assign the original screen schemes back to the individual project or projects.
4. Once you're happy the data exists and works as expected, you can then update the regular screens manually to add the custom fields you want exposed.

This process will first replace the screen scheme on all projects with your "bulk import" version, containing all the custom fields necessary for data import. And then once done, you're simply reverting this change.

Now, you are able to create Issue Type Screen Schemes, and Screens, through the API, so you're welcome to try and automate that process too. The methods you'll want to investigate are likely below. I will note, I can't find a method that will let you add fields to a screen of your choice, only the default screen in the instance.

• Create issue type screen scheme 
• Append mappings to issue type screen scheme 
• Create screen scheme 
• Create screen (EXPERIMENTAL) 

I would recommend testing this against a sandbox environment on Cloud first, to ensure there are no adverse effects.

[jeremyn]

Thanks Robert, that is a good Idea. I'll have to set it up on our sandbox and try it next week some time, but I think that is probably the most realistic option. I guess I'd just have to do it off-hours (which we don't really have due to global teams) or over a weekend still to avoid people running into the import screens while the script is running.

[Robert DaSilva]

Hey @jeremyn , come on back here and let me know if it works! 

I would recommend testing the import process first to determine how long it will take to import all of your data. You may be able to batch this in smaller sections and run it through the day without impacting your users all too much, but I do recommend an off-hours execution. Holidays work well for that (except for the having to work bit.)

Good luck!