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

jeremyn_e0bq0q

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_a432as

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.