This can be changed by going to Jira App Main Page > Projects (left menu) > ... (ellipsis menu on far right of the project of choice) > project settings > Permissions (left menu) > Actions (top right) > edit permissions
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 completely understand the points given. My contention is that it should be up to the administrator of the system to determine how the collection of projects is administered. It just seems odd to make that decision where you immediately create a case of a single sole user setting up the system for the first time, perhaps testing many complex workflows other permissions, customization etc.. and out of the box the administrator is not granted a right to delete something that the administrator created. Presumably, even the project lead does not have those rights.
This is making a sensible default decision which I respect, but it lacks intuition and assumes an use case that may be many hundreds of iterations ahead of the initial use case, ie. a first time administrator setting up the software.
I found the switch I needed, and really the difficult part was more along the lines of, finding that switch was way more difficult than it needed to be. At the very least, the system should know that I am the administrator AND project lead AND creator of the object and give a link to the CURRENT knowledge documentation that would indicate how the only person in the system that has the ability to perform that action would finally do so. That is all.
I don't understand your contention. It is up to the admin how the projects are administered.
I think where you're failing is to understand that deleting is a project permission, not admin. Having the system try to work out a random set of reasons that you think might be a good reason to allow something is less intuitive than a simple "you can only delete issues if you have delete permission"
Again, I respect sensible defaults. The fact is, the permission system comes pre-configured to whitelist the delete operation. out of the box no one is allowed to delete. From an admin point of view, a person who opens the box for the first time, this is not intuitive.
For someone, as myself and you and Joe, it may make sense to archive the issue rather than delete it so having to explicitly allow deletes seems like a good choice for an administrator to make.
Clearly, this choice is made by the Jira team since the software comes pre administered in such a way.
This is not immediately clear and absolutely not intuitive even for someone who agrees with the sensible default since as an administrator, and a project lead, and a ticket creator and in fact the only person who has access to anything in the system at all is told by the system to 'ask your administrator' for this permission.
Ok, I get it, I am being prompted to explore the permission system. Great thanks for the tip/pointer.
My intuition tells me that I will concern myself with permissions when I actually have users and roles to create, not when I first start the software and my user has every role and every permission. A link to documentation of all the administrative choices that the Jira team has made (the sensible defaults) would be appreciated in this case.
I understand the problems that explain why this sensible default choice was made on the behalf of the system administrator. Just think it would be a good idea for the software to not automatically assume an administrator wouldn't want to delete issue cause 'reasons'. Let the admin decide when the time is right to make that choice. That is all.
I agree with John here. Out of the box, as an administrator (and presumably the person setting up, configuring, and testing the system), I should have the permissions to do everything. It's counter intuitive, and counter productive for me to have to grant myself rights to do anything. If I can give myself permission to do it, it's not protected or securing anything and just creating unnecessary hassles and work to not only do, but to even figure out how to do it.
Part of configuring the system is developing processes and security plans that meet the business requirements. At the end of the day, someone still needs to be an overall admin, and that role should have access to everything by default.
It's a poor security model, and it falls over hideously at scale. Admin rights should give you admin rights, and project rights should be separate from them. If they're not, an admin can't do their job when trying to set other people's permissions, and can easily be blinded by the sheer volume of data they simply don't need.
This model, while at first glance, is counter-intuitive, is by far the better way to handle it.
You're thinking far down the road. Again, focus on out of the box.
I setup a new system, new workflow, the next thing I'm going to do is test. Now i have 20 test issues that I need to delete before going live. I try to delete, but I can't. Why not? I'm the admin, I should be able to do everything? So now I have to spend time researching why it's not working to find out it's something silly like this.
Once the system is configured, tested, and confirmed good, the very last thing you do is going to be permissions. It's there that you should then not allow deleting based on necessary processes and rules.
To recap, I agree with you that permissions should be separate for admin right and project rights. I also agree that there should be limited access to the delete function in a live and working system. Out of the box however, this is such a pain and hassle.
It's a proven fact that if you don't start well with Jira, you make a mess.
At what point do you decide to switch from a (broken) open security to one that makes sense in the long run? What's the benefit from starting out with one scheme and switching later?
Thinking down the road is exactly what you need to do, and starting with a correct model is the right answer.
At what point do you decide to switch to a different security model?
At the point you're ready to go live.
When you're setting up a brand new windows domain, do you need to grant the enterprise admin rights to delete OUs?
Why does the software make modeling decisions for the business? That is counter intuitive from domain driven agile design philosophy.
The mess starts out of the box when software is designed based on trying to fix past admin failures rather than education of the user base.
>>At what point do you decide to switch to a different security model?
>At the point you're ready to go live.
But then you've tested against something you are not implementing. So you haven't tested it properly.
>When you're setting up a brand new windows domain, do you need to grant the enterprise admin rights to delete OUs?
False analogy. Deleting OUs is an admin right. A Jira admin can delete admin objects without further permission, as it's their job.
> Why does the software make modeling decisions for the business? That is counter intuitive from domain driven agile design philosophy.
It does not. You are perfectly free to set up "admin can do everything". The reason it's not done by default is that it makes a hideous real life mess and opens security holes.
>The mess starts out of the box when software is designed based on trying to fix past admin failures rather than education of the user base.
Actually, no, it's designed to help reduce the incidence of new admins messing up. As well as being designed for better security and scale.
> But then you've tested against something you are not implementing. So you haven't tested it properly.
But the SYSTEM works which is the FIRST concern. You can (and should) then go back and test security before going live.
> False analogy. Deleting OUs is an admin right. A Jira admin can delete admin objects without further permission, as it's their job.
OK, do you have to go back and give the enterprise admin rights to remove people from security groups? Or an exchange admin rights to remove people from distro groups? Or remove distro groups themselves?
> The reason it's not done by default is that it makes a hideous real life mess and opens security holes.
In a live system, I agree. Again, OUT OF BOX.
> no, it's designed to help reduce the incidence of new admins messing up.
Perhaps Atlassian should have more confidence in their customer base.
> being designed for better security and scale.
In a live system....
I think you're missing the entire point here. I agree with what you're saying in a live system. Out of box, it's frustrating, annoying, and a huge waste of time. And honestly, if it wasn't for the $10 price tag, I would be going with another solution. This is just one example of overly complicated and backwards thinking I've found trying to setup the service desk.
I think you've completely missed all of what I've said. I've already answered all of those points you've made, but I can see you're just not understanding it.
I think we'll have to agree to differ. Especially as it's not going to change.
Like I said, I completely agree with sensible defaults. For an experienced admin with proper secruity credentials, this isn't one of them. Anyone who is trying to deploy a professional SDLC suite should understand separation of duties, not because it's a meme of the software community but because it makes sense for there business model.
Designing software base on failures of amateurs gives me pause when it comes deciding which software I will use. Wix.com is for people who don't know how to write HTML. As a professional web developer, why would I pay for a software solution that is designed in such a way that I don't have to make a decision between a table and a div?
I want SDLC solution that caters to professionals, not amatuers that can read an interface and yet fail to properly implement.
First impression of JIRA out of the box based on this thread, it's amature software. Can a pro use it? Sure, and will only not be frustrated if they accept the developer opinion of what is best practice and be prepared to slog thru confusing documentation to discover how to assert his or her own requirements of the software.
Sorry, these answers aren't good enough for someone who understands the reason for the decision but disagrees with the method of implementation.
Perhaps those admins who fail to properly set up there separation of responsibility should study more on why this is important. In the mean time professionals shouldn't be saddled with the responsibility of reading the docs for something as trivial as how can the only user of a system, the admin and OWNER of that system create and destroy freely without tripping over system defaults designed to cater to people who don't know what they are doing.
I have, I'm just not going to repeat the arguments already given above, as you have chosen not to listen. That's fine, you've got one belief, I have another.
No I do not work for Atlassian.
I've worked in several places, including ones that have software where "admin can do everything off-the-shelf", and seen just how much of a nightmare it is (even in non-production systems), and come to appreciate Atlassian's model is broadly right. (I'd like more delegation abilities, but never admin-all)
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
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.
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 it
setting 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.
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?
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
And you may be called upon to explain what happened to those missing numbers. I've been around a long time and I've had to produce information about all types of things for managers, especially if something goes wrong, and they hate missing data. The 'are you sure you didn't delete anything by mistake' will surely come up if there is a problem. I still suggest not deleting issues, but using a resolution of 'deleted' to close them.
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.
See how to use Jira on the go! Demo Den Episode 5 is here: meet Jira Mobile with Jira Product Manager Rayen Magpantay. Demo Den is in our monthly series where a Jira PM demonstrates...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events