That's not helpful. "Perfectly good design" is your opinion just like me stating that it's ridiculous the way it is. The amount of discussion would make most people think it's not a perfectly good design.
A much better design would be to show the 'Delete' option, but disable it unless you have permissions (can use hover tooltips to explain permissions are needed). Then, a user would know that the issue is related to permissions and not have to search 'where is the delete option'. Many of us (and probably others who didn't comment) had to search to understand why the delete option is not available. That may be a perfectly good design to you, but I think it is a bad user experience.
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.
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.
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)
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.
This is an attitude from the Jira community that says if its not broken, don't fix it. I can understand that. Its also a design pattern in their software. Maybe some people come across this issue and are just happy to get their answer and move on. Others like myself recognize that if its this much trouble to do this obvious and routine task, then most likely the one off and not so obvious tasks will be that much more troublesome.
Sadly, i wanted to like this solution and I just could not get over the pattern of not so user friendly design decisions.
And im sorry, if you are in a business where deleting a ticket is criminal, then you definitely dont want Jira to own that aspect of your business.
I think you've completely missed the point, and neatly condensed that down into the phrase "user hostile design". The problem is that sidesteps every main point - your evidence of "user hostile" adds up, but nothing makes it "user hostile". It all means "while people don't get it, it's stopping them breaking stuff"
You say "You're blaming the motorists on the bridge for the bridge being badly designed."
This is a great analogy, but it is not quite right. A better one would be that I am blaming the motorists on a road for complaining that bridge is not the shortest bridge they would have built (so it's badly designed in their view), but they don't quite understand that what they see as a well-designed bridge would take them through a radioactive swamp (harder to build on, and incredibly bad for them).
Anyway, as you've misunderstood, and your essay implies you're never going to understand my point of view, I think we'll have to agree to disagree. Hopefully amicably.
Nic, I think you've missed my points. I submit as evidence the demonstration that you didn't my previous message properly.
Read it properly, and you will learn how it is that I know that.
In your radioactive swamp analogy: The real solution would be to clean up the swamp.
Which in this case would mean implementing a recovery system for accidentally deleted issues.
Other people are flocking in to agree with me and tell you there's a problem with what you're saying, and instead of listening, you're pretending we're failing to understand you.
We aren't failing to understand you. You are failing to understand us. You didn't even read my full comment properly before dismissing it with a silly and easly countered analogy switch.
Once again: If you think you're doing a good job at community engagement, then I beseech you, in the bowels of David Dunning and Justin Kruger, think it possible that you may be mistaken.
No, we're still in the same place. You have missed my points, over and over. I can't work out a way to explain them in a way that you will understand, and I apologise for that failing.
All I can do is to quote someone else who gets it right (while ignoring their own advice) - "Read it properly, and you will learn how it is that I know that."
You emphasise "You didn't even read my full comment properly". I understand that. I'm on the receiving end - You put me in exactly that position, as you didn't even read my full comment properly.
Again, as you don't understand my opinion, and won't respect that people can hold an opinion different to yours, can we just move on and stop flogging this dead horse?
I guarantee you Nic: Every word you said to me has passed through my eyeballs and through my conscious mind before I reply to anything you've said.
You have demonstrably failed to extend me the same courtesy.
Please. Read. My. Full. Earlier. Comment.
Basic reading comprehension combined with the simple courtesy of paying attention before you dismiss us shouldn't be this much to ask of you.
I guarantee you Daniel: Every word you said to me has passed through my eyeballs and through my conscious mind before I reply to anything you've said.
You have demonstrably failed to extend me the same courtesy.
Please. Read. My. Full. Earlier. Comment.
Basic reading comprehension combined with the simple courtesy of paying attention before you dismiss us shouldn't be this much to ask of you.
Please, stop ignoring me. Please read what I have said. If you continue to ignore it, that's fine, but at least think about "agree to differ", because you're decided you won't accept that I can have a different opinion.
Sorry Nic, but no. I'm not going to agree to disagree on this one.
I will probably stop commenting after this one for a bit. May see you again in 2020! Who knows!
To agree to defer, there has to be a meeting of the minds, where we engage in good faith, consider the other point of view - and while we may disagree with the other view, we can at least respect it.
I believe I have met that standard to you. But it is demonstrably true that you have not met that standard with me.
As relbelsyntax pointed out: You're missing the serengeti horse ocean dweller.
To "agree to disagree" we have to both be engaging in good faith. You have demonstrably failed to do so.
Over to you for the last word on this year's joust. Or not. Whatever suits your preferences.
In closing: If you think you're doing a good job at community engagement, then I beseech you, in the bowels of David Dunning and Justin Kruger, think it possible that you may be mistaken.
<sigh> Repeating the same thing does not make you any less wrong. Oh well, I can't understand this for you, and I've tried to end the conversation amicably, but you continue to insult me (which usually means you know you're wrong and have moved from reason to "ad hominem" attacks instead). I give up.
And you have now proved it conclusively. Trying to set "traps" like zebrafish proves that you have not understood (or, worse, not tried to understand) what was said before.
Please, just read what went before, and argue against that instead of your straw man.
You do not seem to have not read any of this conversation. To be fair, you might have, but it is an absolute fact that you do not understand it.
Not opinion. Fact. Demonstrated.
Becuase you do not understand. I can't understand it for you.
Please, make a little bit more effort and read. Even if you ignore what I've said completely, other people have much better stuff to say that might help. Please, read that!
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.
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.
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).
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.
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.
Learn how to use two new reports for next-gen projects in Jira Cloud: Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...
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