delete subtask in JIRA

Prakhar November 11, 2016

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 for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

1 vote
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 11, 2016

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.

Prakhar November 11, 2016

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

 

Thanks,

Prakhar

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 11, 2016

Please re-read the answer.

Jungle Boi January 17, 2017

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

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 17, 2017

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.

 

Jungle Boi January 17, 2017

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.

 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 18, 2017

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. 

Jungle Boi July 3, 2017

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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 3, 2017

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.

Jungle Boi July 3, 2017

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.

Like Justin Lai likes this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 3, 2017

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