JIRA should allow for import of issues via REST

[JIRA Administrator]

This is more of a rant than a question, but I'm tired of running into roadblocks in moving my large (20K+) set of issues into JIRA.

First, let me state for the record that I believe in workflow, along with motherhood and apple strudel.  That's one of the main reasons I'm trying to use JIRA, and probably it's main strong point.  But, that's fine for issues once they're in JIRA.  My job is to (programmatically) import my issues so I can do my real job of producing software.

Admittedly, if I wasn't doing JIRA Cloud, I could probably hack these issues in one way or another, but for various reasons, I need to use JIRA Cloud.  I'm starting to regret that decision.

Here are the things JIRA currently prevents that should be fixed, so far.  I've up-voted those I can find, but in general, the use case of importing data into JIRA is very clearly an afterthought, at best.  Don't get me started on the abysmal state of documentation and the Java REST API.  That's for another rant.  If it weren't for Google and this space, I'd be sunk.

• Status should be allowed to be set on new issues created via REST.  There is no workflow until the issues are in JIRA, so the mantra "You need to follow workflow" doesn't compute - they're already in workflow.  The issues are pre-existing - it's my job to put them into a status that makes sense, not JIRA's to prevent me from doing so.  I'm an adult - I can figure it out.  I'm faced now with creating artificial transitions from Open to <whatever> merely so I don't have to transition through all of my workflow to get issues into their proper state.
• Created/Updated should be allowed to be set on new issues.  I now have to create a custom field like Created to represent when my original issue was created.  That's doable, but of course, JIRA has virtually no support for R/O fields, so I have to exclude it from most screens.  (Yes, I could make it a R/O text field, but then that kind of makes it unusable for searches and such - it's a DateTime).  I see that there have been requests for general R/O fields for some 11 years - it really takes that long to set a flag?  Depressing.
• The REST API shouldn't depend on UI (screens) for field availability.  Atlassian should have a read about MVC at some point.  Like dummy workflow transitions, I now have to add fields I don't want anyone to touch to the create screens merely so they can be populated by the API.  Yes, I can remove them when I'm done, but during the transition period, which could take a month or two, I'm stuck with them, and the danger of allowing people to specify them when creating issues.
• Given that, REST should have its own screen scheme or something to at least make this tolerable.
• When creating a new Version (I have hundreds, over many projects), you cannot specify the start date for a Version.  You can't even change the start date.  The release date, yes.  But, that's only half of the picture.

</rant>

I don't expect much out of Atlassian w/r/t these issues - clearly if they're not much interested in adding things as simple as R/O fields, the rest of these won't be addressed anytime soon.  But, given "Cloud" is the future of everything, people should be aware of the limitations of this environment (including the relative lack of plugins, etc.).

Thanks for listening...

[Nic Brough -Adaptavist- · Accepted solution]

There was one thing that jumped out of that which made me want to scream "no".

There is no way the REST API should not follow the UI.  You set up a workflow, control the fields, set the screens and so-on, and then a user happily bypasses everything with a REST call.  No, no, no.  Absolutely no.

However.

You are (mostly) talking about an import process.  An import is, in my opinion, very different to normal JIRA operations.  During an import, you should be able to set created and updated dates, and the initial status, and other things, because there's every chance that an import is from another system which has that data and you want to retain it.

The REST interface is not built for import, and never will be.  (I would not rule out a REST based importer turning up though).

That leads me to suggest a look at the importers that are built in - to varying extents, they do meet your needs, just not over REST.

On the non-import/REST thing, you mention "version start date".  I'm curious as to what use that would actually be?  My limited imagination isn't seeing it.

[JIRA Administrator]

Nic, thanks for the response.  Your posts are among those that I've seen that have been the most helpful.

Actually, this is entirely about import.  For that use case, as far as I'm concerned, the rules don't apply.  For example, it would be fine if only the JIRA admin could do this stuff.  Even if were just enabled temporarily.

As far as I can tell, the built-in importers are unsuitable for everything except the most trivial of cases - a flat file does not an importer make.  I suppose I could create a monster CSV file and hope for the best, but it doesn't exactly let the process make decisions on the fly (e.g., has this issue already been imported, and if so, then skip it or update it).

As to the start date, our existing versions have both fields (start and release dates), as it happens, so naturally, one would hope both could be imported.  Sadly, no.  To me, if it's in the schema, you ought to be able to import it - I can't imagine why they left the start date out except by oversight.  It certainly seems more benign than the Create/Update fields.  It's just one more frustration about getting 90% close, and then falling short.  I guess I'll have to see if I can post-import update those versions via CSV, all 450 or so.  If it were only 50 or so, I'd consider doing it manually, but my time is worth way more than the value of that one field.

One way or another, I'll get my data into JIRA.  So far, it looks more promising than other systems I've worked with, these issues notwithstanding.  It's just a shame that Atlassian doesn't have a better way for new customers to bring in their data - into the cloud.

I also work for a cloud company.  If we were confronted with a similar request, we'd do better.  We have a far more complex schema than JIRA does, and many more ways to bring in data should a customer need to do so.  But then, our cost model is also different.

Thanks again...

[Nic Brough -Adaptavist-]

I think my point is that REST is not for imports, never has been, and never will be.

The difficulty with the importers I think is that you're asking Atlassian to code for every single possible import case, and even if the JIRA issue system could be mapped in a way that replicates any arbitrary other-tracker-system, it's still got the complexities that two people might want totally different things from the same import process.

It's worse for Cloud as well - the Cloud operators are trying to run and support systems for hundreds of thousands of people.  The developers are tasked with improving it for everyone.  An edge case import for one handful of users with a particular import need is simply not worth the effort, especially as it can increase the burden of support.

The importers you do have are limited by the sheer volume of possibility.  They've coded for a subset of the ones that are common enough to be worth it.

[JIRA Administrator]

Well, point taken, but really, it's more about them not coding against importers than it is for them.  Importing issues is kind of an edge case, but then it's always nice to make provisions for edge cases, as one person's edge case may be another's critical failure.  Anyway, thanks for engaging.  Keep up the good work.