Hello All ,
I am new to JIRA ,
Is there any way to delete subtask in JIRA using json script.
like we do for updating a customfield.
{"fields":
{"customfield_XXXX": "ABC"}
}
Can a similar script be written to delete subtasks ?
Please help.
Thanks,
Prakhar
Community moderators have prevented the ability to post new answers.
Subtasks are issues in their own right, and hence have the same interface as issues. See https://docs.atlassian.com/jira/REST/cloud/#api/2/issue-deleteIssue
But don't.
Deleted issues are entirely destroyed. There's no recovery without going back to a backup. If you allow delete in general, you will quite quickly find your users coming to you to ask for restoration of stuff they deleted accidentally. That way lies hell.
Please re-read the answer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Nic Brough [Adaptavist], I know what you mean but, to be precise, subtasks, by definition, are not equal to issues (subtasks cannot carry subordinate tasks). More to the point, if a user can create a subtask, the user should be able to delete his own subtask, IMO.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, you have not understood the answer, and you're making incorrect assumptions.
The "equality" of sub-tasks is utterly irrelevant to the question and the answer.
It's also irrelevant to your second point, which is related to both question and answer, but you've not understood the answer. Just because someone "owns" an issue does not mean it's fine for them to delete it. As a rule, it's a bloody nightmare to allow deletion. Don't do it, unless you've thought it through properly. Which your comment implies you have not.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Brough,
Your argument is (a) that allowing deletion creates a burden of restoration and (b) they are issues, not sub-tasks as they share the same interface. Given that sub-tasks cannot carry sub-tasks (they do not have the identical interface - there is a distinction which can be tested for somewhere or they would have the same "add task" functionality.
Furthermore, they are at a different level of granularity - they cannot carry the weight of data that their parent issues do, thus the perceived potential burden of restoration is exceedingly diminished if not entirely gone.
If the user can have the authority to create a sub-task, they should have the authority to delete their own sub-task. Otherwise, you get users who will not enhance your process for fear of not being able to correct and refine.
I can see your argument for issues which are greater and some user might come to you begging for a restore. The solution is not to deny deletion but provide them with the ability to perform their own export/import or backup/restore.
How is it "a "bloody nightmare" if you define your transactions? Relational databases have been doing this with ease for decades.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, again, you have not understood.
I will admit I was not clear on this point - technically sub-tasks are simply issues in their own right. In the code, the difference between them and a parent issue is simply that they can't be created in isolation and there's some stuff to connect them to a parent.
Your choice to interpret sub-tasks as "different" to parent tasks in a specific way with whatever weighting you choose, is absolutely fine, but it's up to you and your usage. (I've got one project here where the parent issue types are pretty much irrelevant, and the sub-tasks hold 90% of the "weight" of the data". That makes your interpretation wrong for that set of users. It's a technical point only)
>If the user can have the authority to create a sub-task, they should have the authority to delete their own sub-task.
No.
As an admin, I'm sick of "how do I get my deleted thing back" and explaining that it can be days work to do it. It's a counter-productive waste of everyone's time. The solution is to prevent deletion and have a simple route to say "this is a duplicate or error"
The database stuff is irrelevant to this argument too.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I could agree with you, but then we'd both be wrong :)
Bottom line: In a project management system, if a user can create a record, they should be able to delete one. You "being sick" of performing a job function is more indicative of a need for the user to have the ability to do so without you - or for you to find a new job.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
In a change management system, a user should be able to say "actually, I don't need this".
Deleting a record destroys the information that someone else may have worked on it or started to make changes and so-on. So, no, just because you can create something does not mean you should be able to destroy it. In some cases, yes, it's fine, in most, it's not.
So, that's a totally invalid argument, and you've still not grasped, or managed to refute the other things I've said.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I see where you're coming from regarding a record that someone else may have worked on. Thus, the logical solution is to allow deletions only for which the user is deleting his own records. Given the specific case of a sub-task created in error with no time from another user on it, there is no reason to not allow the owner and create to delete it. I understand all of your points - I just disagree. There is no harm in allowing someone to delete their own subtasks against which no time from another user has been logged.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
>There is no valid reason to not allow someone to delete their own subtasks against which no time from another user has been logged
Absolutely wrong again. You really need to read through the reasons above properly. There's a difference between your opinion and reality.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.