Very cool - have been waiting for the term "issue" to be changed for many years. Not sure I love the new term "work item" though!? Don't get me wrong - it is much better, but we customise / store information about Equipment, Documents and other Physical Items meaning "work item" is a little nonsensical too. Maybe just "Item" would have been a better/generic term...but thanks none the less!
This is ridiculous — who in their right mind thinks it's a good idea to change the names of structured fields? Clearly, the person behind this nonsense didn’t stop to consider for even a second how it would impact the development work integrated with the platform. Not only are they wasting time on pointless changes, but they’re also kicking their own clients in the process.
The Key to success is to innovate, and maintain quality in industry standards and where this is not feasible define the new standard !>>>>Not something Atlassian seems to do !
The renaming of "issue" to "work item" has no impact on the operation of the CSV importer.
I used the CSV importer today and everything worked perfectly fine.
I suggest exporting a set of manually created issues and studying the structure, and reading the documentation. For the work item to be imported with a custom work item type (issue type), you need to have a column with cells mentioning the type name and then map it to the "issue type" field during the second importer step.
But I will say that it would be nice if the field "issue type" was renamed as well.
My first question was answered in the FAQs "Will filters and APIs etc still function with the term 'issue'." But I didn't see the answer to my next question "In filters and other places, can I replace the term 'issue' with 'work'?"
Hi @Jamie Echlin _ScriptRunner - The Adaptavist Group_ Thanks for replying to my post. I am referring to the real ISSUES which almost everyone is talking about. The question is why aren't the main features of JIRA working properly. For importing test cases, what is the template that is proposed. Someone commented that one needs to have a column added to the csv file which talks about the Issue Type and it has to have a value of "Test case" or "Test", I am not sure.
Anyway, for me, I used the same import template I have been using. And it resulted in creation of User stories for all those items in csv. Isn't this a HIGH RISK item? If there is a change in step, Please Highlight it.
What about Traceability Matrix- Do I need to even get started on it :)?
See, the thing is, there are so many issues in JIRA for so long (I have highlighted just a few coz I am tired) and the Atlassian team comes up with this cosmetic change.
@Anupam Jha your question is not related to this topic, and it seems that you are trying to import test data, but you don't have the fields created in Jira, or corresponding testing app.
As this is not what this thread is about, I don't think you will see much action for this here. Do you have a topic for this already as a question? Otherwise, I would suggest you create such a question so we can help you with this issue in a more appropriate way.
Once you have created the questions, feel free to ping me, and I'll help you with this, but chances are many others will help you before me :)
We recently started migrating our work items from Azure DevOps to Jira and have noticed that work item types no longer align with how they did during our trial process.
Before, they matched what we expected in terms of hierarchy. Epic -> User Story -> Sub-Task or Epic -> Task -> Sub-Task.
Now it only has the Epic -> Task -> Sub-Task option, and User Stories no longer can have Epic parents nor can they have Sub-Tasks. All our original work items still have the old way, but you can't add more without changing the User Stories to Tasks first.
Is this expected behavior or is this a bug that needs to be reported?
145 comments