delete subtask in JIRA

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

1 answer

1 accepted

Comments Closed
1 vote

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.

ok.thanks , So it means that we have to deleted subtasks manually from frontend.?

 

Thanks,

Prakhar

Please re-read the answer.

@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.

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.

 

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.

 

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. 

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.

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.

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.

>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.

Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,305 views 14 20
Join discussion

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot