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 _Spark-Nel_]

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