Solution:

Go to Administration > Applications > Jira Service Management Configuration, and under Permission scheme errors.

Turn it On(yes) and off(no).

I suspect that “delete issues” used to be one of the “non-critical permission scheme errors”. Now it is no longer in the list and after switching it on/off the current list is used.

It boggles the mind how this suggestion was created in 2014 and nothing has been done in 9-10 years. Per their own documentation, as described in one of the attachments, they themselves say to "think carefully about which groups or project roles that you assign this [delete issues] permission to." 

How can we think carefully about who to assign the Delete Issues permission to if it is forced upon us?

I am also in agreement, we do not want to allow any user to delete an issue, and have a set process if this is ever required.  Therefore we have removed even admins from having the ability to delete, so do not wish to see this error message, as when clicking on the show more info, it does not even mention the delete option in the list, so unsure why we see this error message

In JSM, there are quite a few default permissions assigned to the Portal access users, ie: delete, move.... etc.

When we remove any of these permissions, the popup error in the Project is misleading. Ideally for our firm, we do not allow anyone to delete issues, especially not portal access users. We need a way to not throw this error every time a project user access the project.

For my team, we do not want anyone to delete issues under any circumstances except as an Admin. This helps us to see how our techs are doing with creating tickets correctly, timely and appropriately.  We also do not want anyone to be able to delete comments.  Again, this forces our techs to ensure that they stay professional and on key in their tickets. 

There are certain processes where it is no good idea to delete at all... I don't get why they should be able to delete... You have plenty of possibilities to close an Issue with an according state/resolution. So it's better to have it documented why it won't be processed than just deleting it and cause misunderstandings and confusion.

Ahhhh, that is a very good question and an excellent point!  I have a couple admins because they need to write reports and since I'm the only TRUE admin, I can't support this entire company and all departments.  So I've allowed them access to modify their workflows and such.  Risky, yes.  But necessary at this time.

I'll email all of my admins and remind them to DISMISS, not FIX.

Thank you so much for the insight.

08287db7dd59,  How many admins do you have?  If any of them click the fix issues button it will revert your change.    

I am on Cloud and don't see the option to change the Permission Scheme Error message.  Can anyone help?

But also, it seems that when I remove the Delete Issues permission from my Service Desk Team Members... after a while, the system just reverts the permission BACK to Allow.  I don't even know when or how that happens which means randomly, my Agents can delete issues.  And I don't even know about it!

Please implement this as soon as humanly possible.

This would be very helpful for our team. We need to keep records of all of our tickets, even if they have been cancelled, and as-such have turned the delete function off. Jean-Francois' work-around unfortunately does not work for our users as we operate multiple service desks and only are team are main administrators. We've had multiple complaints around this from users. The warnings are important and shouldn't be removed, but a 'Disable this Issue' button (ie. stop alerts around that specific issue, but not new errors from popping-up when they occur) would be fantastic. 

Thank you, this was helpful to me. faced the same issue. @jean-francois.forget2020484362 

Thank you for your fix suggestion, jean-francois.forget2020484362 - I think you just saved my sanity (there's only so many times you can ask people to dismiss the error before getting dis-heartened by them clicking the wrong button!)

This and delete comments should be allowed to be switched off without causing an error.

alexander.wechsler I think you can fix this from the JSD configuration page (https://your.jira.domain/secure/admin/SDConfiguration.jspa).
Set "Permission scheme error" to "Yes, don't show non-critical permission scheme warnings to project administrators."

We also do not want our agents to be able to delete issues from the Service Desk. Delete permissions are restricted to Admins only.
I am very annoyed by the constant popup when logging in and blocked it with uBlock Origin. Now I don't get any popups in Jira unfortunately, but there is always a small price to pay.

Here's our use case: We have 1200 Jira projects and most of them requires employees and consultants to enter worklogs. If an admin deletes an issue that contains even a single worklog, it gives serious budget problems. Especially with our consultants who are paid by the hour.

Our project admins are aware of this. But, humans makes errors and we have a thousand project admins. That's why we don't want project admins to delete issues without having some sort of protection when there's worklogs in them. 

What's the status with this one? How many more years you need to "gather interest" to fix this bug... 

+1 - dont see why and how JSD is hard coded to enforce assigning 'Delete' permissions (and others). I specifically don't want external clients to be able to do such actions.

Its an issue that has come up often -

https://community.atlassian.com/t5/Jira-Software-questions/Service-desk-customers-role-permission-scheme-error/qaq-p/729546

https://community.atlassian.com/t5/Jira-Service-Desk-questions/Permission-scheme-error-after-creating-nested-user-group/qaq-p/926700

+1

Hello All,

We've made an enhancement fix on how we handle Jira Service Desk permission errors. This allows you to retain or dismiss non-critical scheme warnings. More details can be found here.

Let us know if this helps resolve the issue you are facing. We appreciate your feedback.

— JIRA Service Desk Team

How did Atlassian ever think this would be acceptable? I don't understand how such high quality products overall can be plagued by so many terrible decisions on the details.

This permission should be able to be switched off with no error message to project admins.  Data Retention policies and Audits should be the only buzzwords needed for explanation.

Agree with the above comments. My organization struggles with this. There are no pieces to pick up after an agent deletes an issue. I've resorted to having email notifications sent to myself when an agent deletes an issue so I at least know the key and summary.

Really essential that this gets changed, quite a number of customers require the ability to audit requests such as changes, and that fact that everyone is allowed to delete issues causes problems.

And also in your own recommendations on Standard permissions, Atlassian recommend delete issues only to be given to Administrators, but in fact has Service desk Team as standard. Quite contradictory - Please remove delete issues from mandatory permissions for Service desk Team members.  

https://confluence.atlassian.com/jirakb/standard-permissions-in-jira-service-desk-838416600.html 

According to the documentation Delete issues permission is not mandatory for the permission scheme. See https://confluence.atlassian.com/adminjiraserver074/customizing-jira-service-desk-permissions-881683481.html

To add to this, the permission warning should only display for actual required changes, not suggested ones (or at least give us a setting that allows us to choose whether our users get permission warnings for suggested permissions or not). While "Delete" is the biggest problem for us, we're not fans of ever giving users more permission than they need.

Regards

Maree

Hello,

I have reopened this suggestion as it suggests that the permission warning message not be presented at all when a change is made to the "Delete Issues" permission. This is different from being able to dismiss the message

Cheers!
Tim | Atlassian

Hi

This issue has been fixed by JSD-1969, and will be available in an upcoming release of JSD.

Please watch that ticket for updates.

Regards
Matt
JIRA Service Desk developer