Am I to believe that the one web page, entitled "Importing data from JSON", is the entirety of documentation for importing to JIRA via JSON? Really?
@James Mason we imported >85k issues to Jira Cloud via JSON last year from another old system (BugZilla), complete with custom data, histories and issue linkages. Agree with your doc concerns, there was a lot of trial and error involved in the initial stages. Thankfully it was from a flat hierarchy but many of your other points are familiar.
It was a fairly intensive exercise in data manipulation but did ultimately bring everything across we needed without data loss.
I note the points above about duplicate custom field creation and users. We worked around this by making the import a multi-part operation, creating all the users and custom fields before any issues were moved, and then reading the custom field ids back from Jira via the API as a precursor to each data load. We were batching issues into various Jira projects and ran at least forty separate data imports (max 3,500 per batch) for reasons I'm sure you're familiar with regarding total JSON size and potential import failure.
We still have the workspaces we used in our ETL tool (FME) to migrate data between the two systems, and did a webcast on it here if it should prove useful: https://www.youtube.com/watch?v=eUDzD3nIiK4
Broadly speaking, it went something like this:
1. Create all users, custom fields and certain fixed reference data (teams, etc) as a one-time operation
2. Importer reads back all custom field IDs used in the import for mapping
3. Form and import JSON for bug data using these mappings
4. Read back Jira issue IDs and drop them back into the source system (BugZilla) as breadcrumbs for migrated issues (we had parallel running for several months)
5. Write relationship data into Jira for the imported issues once we have references from both old and new systems (we also updated old links inside comments to refer to the new Jira issues). This was done after issue import for reasons of synchronicity (we needed both ends of the relationship present before link creation)
6. Write additional linkage data asynchronously post import (including attachments and Salesforce linkages through third party tools)
Good luck, if you would like to see any of this in more detail please get in touch!
Are you on Jira Server or Jira Cloud? We do have slightly different versions of the same document for each platform:
Jira Cloud: Importing data from JSON
Jira Server: Importing data from JSON
Could you explain in some more detail what else you are looking for here? I gather you want to import some data into Jira, I'm just curious to learn the source of that data to see if perhaps there might exist other alternatives to importing such data.
We're not supporting our own server, so I suppose that means we're going to be on the cloud. I suppose I had seen that there were two forms of the document - and while a simple example is highly valuable - I would have expected something more like a grammar to help me generate acceptable JSON.
We're trying to migrate from GNATS. The data extracted from there has a modest hierarchy - where issues are allowed to have an arbitrary length list of audit trail events. Events being "State Changed", "Responsible Changed", "Comment Added", "FixForReleaseChanged", "Originator Changed", and some a couple types that relate change in custom issue fields.
I didn't think CSV would be as convenient a way to input hierarchical data - if it's even possible.
I have a python script that successfully loads the GNATS data base, as well as representing the attached list of audit trail items. I was looking for something to help me emit all that in an acceptable JSON form.
I have not found much in the way of other requests to migrate from GNATS to Jira. However from the way you have described this hierarchical nature, it sounds much like the way Jira would represent an issue's history.
If you then look at a particular issue in Jira, under the History tab you can see the changes that happened to the issue over time, who made changes, and to which fields, like so:
This is something that you can define in JSON that Jira could handle. The guide does cite at least one example of this in
<span>"history"</span> <span>:</span> <span>[</span> <span>{</span> <span>"author"</span> <span>:</span> <span>"alice"</span><span>,</span> <span>"created"</span><span>:</span> <span>"2012-08-31T15:59:02.161+0100"</span><span>,</span> <span>"items"</span><span>:</span> <span>[</span> <span>{</span> <span>"fieldType"</span> <span>:</span> <span>"jira"</span><span>,</span> <span>"field"</span> <span>:</span> <span>"status"</span><span>,</span> <span>"from"</span> <span>:</span> <span>"1"</span><span>,</span> <span>"fromString"</span> <span>:</span> <span>"Open"</span><span>,</span> <span>"to"</span> <span>:</span> <span>"5"</span><span>,</span> <span>"toString"</span> <span>:</span> <span>"Resolved"</span> <span>}</span> <span>]</span> <span>}</span> <span>]</span><span>,</span>
In this example, it's a single historical change made by user Alice, at that specific time where the status is being changed from open to resolved.
But I would agree that using the CSV importer in Jira does not really appear to offer the same level of data that could be imported as JSON. I don't believe that the CSV import in Jira is really intended to import such historical changes on an issue.
Does this help? Forgive me if I have misunderstood the hierarchy you are referring to in GNATs is not historical information. I admit that I have not used this particular system before.
Your understanding of my thinking and why I'm interested in JSON is essentially correct. But please do not focus on the fact that I'm coming from GNATS. As I noted previously - I've solved the problem of extracting GNATS data. I can turn what I have into a structured file of almost any sort rather easily.
I need specific information on the JSON format for import to JIRA.
Interestingly, my question appears to have been asked in May of 2013 - "JSON Format for JIRA Import". The Atlassian team member responding at that time explained that only an example was offered because things were incomplete/preliminary/etc. I'll quote the frustrated user from May of '13:
I can't emphasize enough that the documentation -- including the data schema -- needs to be better.
Indeed.
Are you really expecting customers to successfully build JSON import data for JIRA - on the basis of the cloud/server documentation pages noted above?
Still no success at this effort. But I think I've learned a few new details that aren't part of any explicit documentation for creating JSON input:
Hoping for support on this from Atlassian. Got an initial response from Gabriel Senna, who helpfully noted that I should consult the documentation that is the subject of this entire thread. Perhaps that would have been more understandable, had I not observed in the support request that, "For the record, I am the author of....".
This doesn't seem overly complicated for Atlassian to remedy - am I missing something?
Further discovery - contrary to what I said above - no, your JSON doesn't have to name an existing project. A project will be rolled up as needed.
Further discovery - it is very easy to overlook a tiny bit of JSON structure. And if you do - the Jira JSON parser pretty much falls on the floor without telling you much that's useful. The "items" field in each history item is a LIST of one dictionary. Enter it as a single dictionary and your history will not be understood.
Further discovery - when creating users - Jira insists that they have an e-mail address. Apparently, even if they're marked as inactive (as would be the case for former employees who no longer have a valid e-mail address). Further, there appears to be some scanning going on for the content of the email string - such that "@example.com" addresses cause the associated user entry to be rejected. Finally, to my embarrassment, even though I'm working in a test environment that will never go live - when I used a "real" user with a "real" e-mail address - Jira automatically sent them an invitation on the basis of the JSON upload.
Thanks.
I've simply been trying to add detail information/discoveries as I come across them. Hoping to save someone who follows a bit of the trial and error.
I have taken swings at loading in projects and loading as a rather giant entity. I expect to eventually split the user load and the project/issue load as you did - but I haven't reached the end of the rainbow as yet.
If you like to know how to import issues in JIRA by using JSON, you can try to start to export it in JSON and take a look how it's setup on your version.
JSON(searchrequest-json)Enable this module to export Issue Navigator results in JSON (beta) format. Note only admin can export the data but the JSON (beta) view will be visible to all users.JSON(issue-json)Enable this module to export Issue in JSON (beta) format. Note only admin can export the data but the JSON (beta) view will be visible to all users.
(searchrequest-json)
Enable this module to export Issue Navigator results in JSON (beta) format. Note only admin can export the data but the JSON (beta) view will be visible to all users.
(issue-json)
It looks like you're new here. Sign in or register to get started.
