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.
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...
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.
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.
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.
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.
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.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs