Two Step Deletion in Jira

[#1]

Hi Jira Community,
We’re introducing a new two-step process when deleting work items in Jira.

Why we’re making this change
We’ve heard your feedback, and want to help you prevent accidental deletions.

What’s new?
When you attempt to delete a work item, you can now choose to either archive the work item, or confirm that you want to delete it. This feature is currently only available for Premium and Enterprise users.

Tell us what you think
We’re continuing to improve deleting work items in Jira. Tell us what you think by leaving a comment on this post.

Thanks,
Shikhar
Jira Cloud PM

[Debbie Jolley]

tbh it's an annoying overhead

we only give the delete permission to trusted admins - therefore having the extra step to actually delete a ticket adds to the workload

[WS]

We do not want this feature. It adds unnecessary steps for our admins to remove unwanted items. Jira support said this was made because people were requesting a recycle bin when tickets were deleted. So instead of making a recycle bin, they now force users to basically type in a captcha on their paid instance of Jira when deleting. Any change made that requires admins to stop what they are doing, take their hand off the mouse and have to now move and look and type on the keyboard is never a good change. Stop treating your users like idiots. 

How do you disable this terrible change? What a bonehead idea from the Jira team.

[James Rickards _SN_]

To counter some of the negative (and quite hostile rather than constructive comments here) I like the introduction of the new "Archive" feature.

One of the things that "kept me up at night" was accidental or malicious deletion of issues/work items by users as there wasn't really any way to recover from it.  To meet BCP and Security requirements, it meant removing the ability to delete tickets from all project uses resulting in their projects having un-necessary clutter, or putting workload on me to delete stuff for them.

The new "archive" permission lets me grant archive to the project admins / power users letting them cleanup their own mess.   We'll never agree to actually delete archived tickets, so overall workload on admins will drop.

[Rick Westbrock]

Being able to archive issues is certainly a nice feature and it has been around for a while now. The pushback (which I don't think was hostile) is due to Atlassian again making it harder to do simple tasks by introduction more friction. Same concept as when they moved a bunch of buttons under the Add button on the issue view or when they changed the default transition comment type from public to internal in JSM.

I think the problem lately has been that Atlassian makes these sort of changes based on limited feedback from some customers and instead of taking a bit of extra time to make such things configurable by admins they just force it on everyone.

Fortunately we very rarely delete work items but I can see that for some teams this is going to add a non-trivial amount of time & effort to deleting work items.

[Haddon Fisher]

First, want to call out that Atlassian had an idea and posted here for feedback to ask us how we felt. I don't want to get my hopes up just yet, but tremendous start!

Second, the UX proposed here feels pretty screwy to me. To be clear, I think reminding someone that "Delete" in Jira means "pitch this into the Sun" is fine. However "Archiving" and "Deleting" are two distinct actions, already linked to independent permission levels and items in the "..." dropdown. This was done explicitly to allow admins to not grant people "delete" access.

If this is true, then people who have "Delete" and select "Delete" know that they mean "Delete". There's no need to ask them to re-confirm. They already went and got the access, had it approved, and then clicked the button. Or they're an admin, and frankly if they're admining Jira and need this then they have larger problems.

[Haddon Fisher]

Update: it looks like this change went out without any announcement or feedback on this thread from Atlassian, which is a return to form but still pretty disappointing. Given the mixed feedback here I absolutely can see the need for more feedback, but silently dropping it on a bunch of random folks "to see what happens" doesn't seem like a plan calculated to produce valuable results.

I'd really love for Atlassian to articulate their Product group's ideation and prioritization processes. I think Rick Westbrock's comment:

Atlassian makes these sort of changes based on limited feedback from some customers and instead of taking a bit of extra time to make such things configurable by admins they just force it on everyone.

is a fair assessment of how it feels to be on this side of things, and I would add: "why does this feedback generate a response when so much else does not?".

[Jochen Betz]

Having new ideas and proposals is a good thing, that's called innovations. But that's where it most of the time seems to stop at Atlassian. Just looking the first 20-30 comments on the new idea (actually they are going to do it no matter the customers comments) to rename "product" to "app"  proves this once more.

As it's mentioned in the comments before it is a good thing to explicitly distinguish between "delete" and "archive". But than go all the way and provide also to distinct icons to trigger this actions.

But what annoys me the most, and obviously also other commenters is the fact that it adds more work load. While I might be still willing to accept a confirm popup with ok/cancel, having to leave the mouse and type a text "delete" to really delete might be appropriate for rocket science and nuclear weapons but definitely not for an issue; the world will keep on spinning even after deleting an issue.

If you are concerned about people accidentally deleting issues, admins can already decided to whom to give this rights. If you are concerned that somebody accidentally clicks on delete (like mentioned above as well), the problem lies in the your UI design in the first place (as also mentioned in an issue). By placing the "launch nuclear weapon" icon just next to the light switch makes it error prone be design. Adding another 20 dialogs after the "launch nuclear weapon" is not going to fix the original issue but only try to mitigate the problem.