Usually i saw 'delete' button in "More action" sections.In my onDemand instance there is not delete link.
Question is: how can i delete issue?
if you want to delete issues you should have permission to delete issues, to get permission contact you jira admin or project lead
Thanks, it`s work now.
What is the right way to get such role? I did create a project but I couldn't find a way to delete an issue in that project...
I am the damn project lead
Some jira ideas are really weird. Yuo should click tons of screen in order to give YOURSELF (!!!) a right to delete issue.
Project Administration -> Permissions -> Edit Permissions (top right action menu) -> Select 'Project Lead' on the radio buttons -> Save This will affect all projects that share this permission scheme
thanks
Can we have a simple explanation? I am project lead still cant delete stuff..
any help will be appreciated..
worked
it is simple had too many beers....
1. Don't delete unless you are 100% sure. The community is full of questions about restoring deleted issues, and it's not easy or fun.
2. Use the "delete" option from the ... menu
3. If you don't have it, then see exactly what Alchemytec Admin said above.
thanks Mate..Got what I wanted..
The given reasoning for not have ability to delete an issue makes no sense when it's so simple to delete the entire project.
It took me ten minutes find where to give myself, the admin, permission to delete an issue.
It makes perfect sense. Deleting a project can only be done by administrators.
Users, in a few cases (see points above about why you should generally disallow delete), should be allowed to delete issues, without needing admin rights.
I think I agree, as project lead i think the ability to delete an issue is helpful and pretty basic... imho I shouldn't have to dig around into permissions and grant myself access. For those still looking for itsetting cog > permission schemes > permissions > delete issues > edit > show more > project lead > grant
It's mostly an unmitigated disaster to allow delete issue in Jira.
One of the things good admins do when they inherit a Jira system is remove delete permissions throughout all the permission schemes unilaterally, so that they don't waste weeks of time dealing with the nightmare of accidental or mistaken deletions.
As @Nic Brough -Adaptavist- said in an earlier post, the forum is full of people trying to recover deleted issues. It will eventually come around and bite you in rear. I suggest closing them with a resolution of 'Deleted'.
Right. Ok, I understand. Thanks @Nic Brough -Adaptavist- and @Joe Pitt So sort of following this thread, I've gone into project settings > workflows, to add that as a 'status' as 'closed'.
Yeah I think this system is better, sort of works like an archiving system.
It'll be good if archiving was built into the default.
I created almost 20 additional more tickets which later found its redundant , will there be any harm to the system backend OR database if i decided to delete those redundant tickets from my Jira?
No, just be 100% sure you want them gone, as it's a nightmare to get them back from backups.
Thanks for your fast response Nic , just to get a confirmation no issue will be happening to DB , cause notice the ticket ID let's say is issue with ID 3 , once deleted and create a new ticket with the ID 3 no able to create the same
No, Jira does not reuse numbers.
I am finding some lack of intuition in using this software. Just because some people are carelessly deleting their issues, doesn't mean that an administrator trying to set up a series of projects should have to be hassled with giving themselves permissions to do a basic admin task.
If it will come back to bite me as an administrator that is fine. that is why I am administrator. I am dealing with much more complex decisions with my software than to worry about accidentally deleting a ticket.
Please, lets not make those decisions for the admin. It should not take me having to search through forum posts to learn how an admin can get 'rights' to delete something as trivial as a ticket.
given the number of posts trying to find out how to restore an issue (you really can't) I wouldn't say deleting tickets is trivial. And depending on how you are using JIRA, if it is a system of record deleting anything isn't allowed in some environments. The best model of permissions and security is to only give people what the NEED. Administering a system doesn't automatically mean you are in charge of the DATA. In some cases 'separation of duties' would mean you have NO rights on the data.
Joe, your answer sounds like scope creep from the Jira team into my collection of projects, does it not? I understand that Jira is providing some sensible defaults for users. I can appreciate that.
I would hope that leaving those decisions up to the users of the software is at the top of the priority list for the Jira team however.
I would also hope that Jira would consider the case of first time users setting up the system where there is just one single person to set it up. In other words, no enterprise level concepts of separation of duties etc.
Like I said, it's just not very intuitive usage for someone looking to start up a dev team with this software and looking to build it out from scratch. I didn't bother wasting any more time looking for a delete button, since apparently deleting issues is 'an unmitigated disaster', doesn't exactly inspire confidence. I'll just deal with cleaning up my test integration stuff some other way..
I think you're missing another point we've not really mentioned in this conversation.
Admin rights means you can administrate the system. Delete rights are project level things, not administrative. It's deliberately and rightly separated out.
There's nothing wrong with giving yourself those rights as an admin (by adding "jira administrators" to "Delete" in the permission schemes maybe), especially after you've shown you understand why experienced admins like Joe tend to remove or at least be very selective about delete permission.
I think there's been a general interface redesign since the last time someone in this comment section answered the question.
I've just struggled with this myself and managed to stumble my way into getting it working.
This got it working for me.
For the record, I find this wildly unintuitive. I was a member of a group in the Administrators role, but I didn't have access to the Delete permission until I was added explicitly as an individual user with that role. This is nuts.And going back over the earlier conversations, I find myself in 100% agreement with John Busciglio.
Problem is, he's wrong. He has not read and understood the previous postings. His last essay on the subject was well-formed, but totally missed the previous points.
Anyway. You are a lot closer to seeing the right way to do it, but you have missed a layer. It's not about you being in a particular role, it's about explicitly saying "this person can delete issues". That is done in the permission scheme for the project.
You don't need to be an administrator, you just need to match the "can delete" rule. One way to do it is to be an admin and have a rule that says "admins can", but there are other rules.
My project only has one permission scheme.The Delete Issues entry under that scheme includes:
When I go to people and look at the roles I have available? There's only one role. The role is 'Administrators'. That's it. There's no distinction at the Add User level between different flavors of administrator. There's only Administrators.
As a member of a the jira-administrators group with that role, the Delete Issues permission wasn't working for me. The permission helper confirmed this was denied to me despite that group membership and role assignment.
But when I added myself explicitly as an individual user given that role, suddenly the Delete Issues permission was unlocked for me. The permission helper confirmed it.
This is in direct contradiction with every DACL-inspired norm about group/individual permission sets on resources that I have worked with in every computer system I have ever touched since my very first Amstrad as a kid in the early 90's.
'Wildly unintuitive' doesn't even begin to cover it.
To be very clear: Atlassian isn't necessarily under any obligation to follow those established industry norms in how they implement security. They can do whatever they want, it's their software. But it's a weird-ass decision all the same, and the userbase is justified in expressing their confusion and frustration at having those norms subverted without an intuitive pathway forward as to how to resolve their problems.
It seems like this entire set of confusion around the delete permission is a consequence of the lack of a good recovery option for issues that are deleted erroneously. If that existed then there would be less of a need to protect users from themselves by putting together this convoluted self-certifying thing that's going on.
It feels like the current setup is to make granting yourself delete permissions deliberately confusing. It requires expertise to search through online documentation, most of which is out of date or incomplete or otherwise unhelpful, stagger through trial-and-error to try and get a grip of what's going on, until eventually you stumble on the right series of incantations to unlock the delete issues ability in practice. So by the time someone manages to unravel the gordian-knot of granting themselves the delete permission, they have demonstrated that they are competent enough to use that permission responsibly.
Finally, based on my most generous and impartial reading of your conversation with John, you were the one failing to address John's point and not the other way around. That you think John was failing to address what you saw as the core point under consideration is actually a sign that you were confused about what the point actually was. John's point that the out-of-the-box functionality of Jira runs against established conventions, is confusing to understand, and frustrating to fix, is a valid and meaningful point that, as far as I can tell, you neither acknowledged or meaningfully addressed.
Interestingly, you seemed to miss John's tree because you were too busy pointing at the rest of the forest, which at least earns you points for subverting how that trope usually goes. :P
Wow. You really care about this, but still completely ignore almost everything that has gone before.
The only part I picked up on as new was "That you think John was failing to address what you saw as the core point under consideration is actually a sign that you were confused about what the point actually was." But you have that the wrong way round - I understood the point. John did not. Nor do you.
I think we may have to agree to disagree, as you're not getting it.
LOL, thanks Daniel Schealler, your answer worked.
So an admin can delete a project but not an issue? Definitely designed around *very* large organizations if that's the case.
They are two different actions. A project is an entire structure, filled with issues. Deleting a project has been flagged as a global administrator responsibility, no-one else's.
Issues within projects are controlled by permissions, as you do have cases where someone might need the right, and most others do not. By default, administrators get admin rights, not "can do everything" or "automatic project rights".
I'd strongly recommend not allowing most, if not everyone, to delete issues, as a deleted issue is utterly destroyed and it's horrible when someone deletes the wrong thing - better to have a process that closes them or moves them somewhere out of sight).
This whole thread is an excellent demonstration as to why you need customer focused product managers who LISTEN. Every response from "community leaders" has been about why the users and customers are "wrong" and they are "right". If this many users are expressing this problem ITS A PROBLEM - that's how product works.
They have listened, and I don't think you've quite understood the real problem.
The presented problem is "I can't delete issues by default". The actual problem is "people delete without understanding the implications". Those two contradict each other, and Atlassian have tended towards listening to the vast majority of users who have the second problem.
Allowing delete by default is a really bad thing. In some cases, it's even illegal (although that could be fixed with a new feature that Atlassian have put near the bottom of the to-do list)
Hey again Nic. Long time no see.
Just to prove I listen: You say that the disagreement here is a conflict between "I can't delete issues by default" on the one hand, and "people delete without understanding the implications" on the other.
The complaint is not "I can't delete issues by default."
The complaint is: "Users assigned to a group, where the group has the administrator role, cannot delete issues unless they are explicitly added as individuals to that role, which is confusing, undocumented, and breaks the user/group/role norms everywhere else in the security model".
Sure, that's a lot longer. Being a member of a group with administrative role is not "by default". That's "by administrative group membership". You keep talking as if those two things are equivalent. They're not.
Second, you've misrepresented the second leg too. The problem isn't that "people delete without understanding the implications". The problem is that humans make entirely forseeable mistakes. Accidents happen. Sometimes those accidents include deleting something that they shouldn't have deleted.
If a civil engineer made a multi-lane bridge that would collapse if people merged lanes, putting up a sign to tell people not to merge lanes won't work: Motorists will merge anyway.
So the civil engineer could put up concrete barrers to block merging. Then when motorists in backed up lanes that can't merge out into unused lanes will complain.
Then a community leader for the civil engineer's company could show up, and try to spin the conflict as being between "motorists want to merge lanes by default" and "motorists don't understand the implications of merging lanes".
But that's wrong. It's blaming the motorists for not understanding that the bridge is badly designed. The problem isn't on the motorists for merging lanes. The problem is on the civil engineer for designing a bridge that will result in unrecoverable failure in the event that motorists try to do what the civil engineer should have been able to predict that they were going to do right from day zero in the design process.
It's entirely predictable in an issue management system that sometimes users will want to and need to delete things - and that sometimes they'll delete something by accident. Any software engineer should have been able to predict this right from day zero in the design process. But instead of adding in a recovery model to the design, instead they wanted to put in concrete barriers by breaking the user/group/role security model just in the case of the deletion privilege, so that the ability to delete in the first place becomes really hard to get to.
And you know what? If they did the cost/benefit analysis and concluded that this kind of user-hostile design was the right move, business wise? That's okay. I'm not happy about it, sure. If you get this far into this comment, please include the word zebrafish in your reply to demonstrate that you actually read this all the way through before responding. But I get why a company might decide to implement a user-hostile tradeoff.
But what's irritating us is that you're trying to spin this as being something other than a user-hostile move. You're blaming the motorists on the bridge for the bridge being badly designed. And you're doing it while talking down to us as if we're too stupid to understand the point you're making, while ignoring us telling you we understand your point but we have really good reasons why we think you're wrong. Then you ignore the reasons and just tell us we're ignorant.
You're defending a user-hostile move with a user-hostile tone, when user-hostility in communications is exactly the problem that TJ was complaining about in the first place.
You set out to disagree with TJ, but you're just proving them 100% correct.
If you think you're doing a good job at community engagement, then I beseech you, in the bowels of Christ, think it possible that you may be mistaken.
Thanks, Daniel. You are saying everything Jira needs to hear. We are moving to another product already because we cant stand this anymore
It looks like you're new here. Sign in or register to get started.
