This issue arises because, if the site allows any public sharing, the "create filter" UI gives team members the option to share a new filter with "Everyone", which sounds like an org-local scope but is in fact a public/non-logged-in scope. The org-level scope is called, "Open", and is not part of this UI. Sigh.
To prevent this issue as a site admin on Jira cloud, go to:
Jira Settings -> System -> General Configuration
and disable "Allow users to share dashboards and filters with the public." This doesn't affect existing filters, which you have to manually fix.
In true Jira fashion, if you try to reassign a filter after flipping this setting, it will deny the operation and ask you to edit the ACL, which there is no convenient admin UI to do.
I admit I have mostly avoided using it, so a question:
> Jira is a disaster of UX.
Jira is trying to be all things to all people. It seems to me to be based on a sort of shared illusion, namely that when people talk about work getting done they are talking about the same thing, when in fact they're often talking about wildly different processes, different philosophies. I think that sort of illusion guarantees a UX mess, because it's trying to cover up/accommodate too many different things. Is Jira a UX disaster because of just that? Or is it bad on top of that?
And I worry that makes no sense, so by analogy let's imagine that somebody sold a "transport solution". This sounds great, because transportation is a universal need. But in reality transport solutions include shoes, scooters, bikes, motorcycles, cars, buses, trains, and airplanes. So this "transport solution" comes with a great mess of wheels, gears, shafts, etc, etc, plus reams of Ikea-style instructions for putting pieces together. It's universal, but also guaranteed to be a pain in the ass for any actual specific use.
Don’t mean to create a pile-on, but since you asked, yeah I should explain my barb:
Is Jira a UX disaster because of just that?
Or is it bad on top of that?
My opinion - it’s both.
The product has a ton of permutations, as you said, which makes stuff like this happen: Customers who never in the world imagined public issue tracking, suddenly bit by a feature they didn’t even know existed. Conversely I’m sure there are shops, who love this feature, for whom the distinction between “Everyone” and “Open” was always obvious. I don’t envy the team building / supporting the product across all that; I don’t know how I’d do it.
But there are also endemic, continuously-poor design choices large and small. Unannounced and hard to disable major changes to the UI are the standard, and large. I’ll give you one example of the small: Recently, unannounced, the issue comment UI started auto-correcting the capitalization of Atlassian product names in the comment box. Type “JIRA”, get “Jira”. In my words in my issue tracker. (Yes, it was the js app, not the browser). It just always seems so user hostile.
Net net, to me it’s an aging hydra of a product with ongoing missteps. I’d take good design and limited features over what you get here, at least with out heavy investment and expertise.
I tend to agree Jira is a bit of a mess, but the responsbility needs to be shared with the users.
- Why buy a complicated mess?
- Why let a random Scrum Master / Product Owner manage it?
- Why don't we think we need to protect an IT system we buy like an IT system?
Many of the reasons engineers hate Jira are specifically related it being a complicated mess that is hard to use and admin. So if management would listen to engineer about IT systems, maybe this wouldn't happen?
Another possibility is we actually did a risk assessment and what we put in Jira isn't of sufficent risk for us to care, so actually IT doesn't need to be involved because we're not super worried about it leaking.
There are likely worlds of both involved.
My own pet hate is just that it's too slow and often configured in a convoluted way that makes me spend too much time in it.
And now that you describe it, I suspect it's inevitable that anything bad in the first way becomes bad in the second. If the purpose and the use cases are clear, that can guide good design. But if the product is too complex for mere mortals to understand it, then of course the teams building it will eventually turn it into a frankenstein collage of UI issues.
I think it is caused by Atlassian changing their branding: since most people did not bother to capitalize 'JIRA', they branded it as 'Jira'. By the way, I am on an older version of Confluence and it autocorrects the other way: 'Jira' to 'JIRA'.
I think you hit the nail on the head there. The question as phrased is kind of nonsensical. From a bad foundation, it’s not possible to build a good UX. Correctly identifying the problem is a critical step in product development.
To take your transportation example, there is no good way to provide one product which scales from “shoes” to “airplanes” by user configuration. It makes no sense to ask if the shoe-plane is well implemented or not. It’s a terrible concept to begin with.
I mean, it makes a lot of money. But it's widely hated, and from what I've seen it's pretty bad at solving the problem it purports to solve. I guess some people call that success, but I wouldn't. My goals go beyond filling my pockets.
The problem Jira solves is giving a useless, parasitic class of managers visibility and control of what teams of developers do, because the managers cannot and will not learn what the developers actually do. This is done even at the expense of the productivity of the developers.
Of course, there are good managers of developers. But they neither use nor need Jira.
I think that's exactly it. Many in-house tools are designed not for the users but for the people with power and budgetary authority.
As an aside, I think that's why Agile and Lean methods have been mostly adopted in name only, leaving the substance untouched. The goal of both movements was to shift power to people doing the work, and managers see that as a reduction in importance.
Yes. It's crazy how many times I've made mistake in Jira or was surprised by it. It feels like there is no consistent in Jira and each feature has its own set of rules and logic and all these features were tacked on to create Jira.
I’m not sure which IP you are restricting - it’s a cloud based service, so, by definition, your clients are pretty much anywhere on the Internet. What would you restrict?
Honestly I don't see how we could use the cloud version unless we could at least lock it down the same way we do behind a firewall; VPN or office only.
It's weird - the last company I worked at (and ran IT for about 4 years had everything behind a firewall (like you are describing) - the current gig that I started at about 18 months ago (with about 80 employee) - no concept of a firewall. The entire office just sits behind a Comcast Modem. There is nothing to firewall. Atlassian/Salesforce/GitHub/CircleCI/Gmail/GoogleDocs/Drive/Slack/Lots of K8S and about 15-20 other cloud services make up our "IT" environment. There is zero difference to working from home to working from the office from a tech perspective.
Defense in depth is always a nice thing to have but it hardly seems like a requirement since the reason you lock down services behind a firewall is supposed to be because they're aren't hardened enough to be on the public internet. I don't think that would describe the Atlassian suite who probably has better SecOps than most of their customers.
The post you replied to mentions other methods to separate a service, not being hardened enough is only one of the reasons you would want to do that. A major one being that many Jira deployments are only useful internally anyway so there is no reason to expose it to the outside world.
JIRA can also be run on your own servers and then you can do whatever IP whitelist you want in front of it, or just not put it on the public internet at all and require VPN...
I don't think there is a dominant alternative but there are almost an infinite number of them. PivotalTracker, Rally, Trello, Aha, Asana, Basecamp, GitHub Issues, etc
JIRA is for people who like to do more planning of work than actual real work. See also: meeting moths.
It’s commonly used by technical managers who have no skills to contribute but need to justify themselves as important so they will spend countless hours setting up complex workflows, tweaking forms and starring at pointless “burndown” charts describing work they have absolutely no clue about.
JIRA also generates an enormous amount of automated email which is further exploited by these folks to advertise to others in the company that they are doing work.
When you interview some place, pay attention if they have a culture ruled by JIRA. If they do, and you like to get real work done, do not work there. It may be possible some use JIRA as a tool but the risk is far too high to take.
I wish I could upvote you twice. Exactly describes my experience and it is soul sucking. It gets so bad that the work-planners actually succeed in creating faux importance and are valued more (and value themselves more) than the actual workers.
JIRA can be used in a way that is beneficial to the team. It is ok as a simple shared task list. Of course, a shared spreadsheet is actually better and infinitely less expensive.
Unfortunately JIRA is monstrously complex and dead weight hides in that complexity as you've noticed. My company is so far gone. We use JIRA as the system of record for change audits. This is a function it is particularly poorly suited to. I don't even want to list the other things we use it for. They are too numerous an depressing. But rest assured, if you can somehow map a process to JIRA, it's there.
<insert joke about how nobody wants to suffer through anyone else’s Jira anyway>
Seriously though, this isn’t good. Not because of this hack specifically but because of the greater problem of which this is a symptom. Software these days is really hard to configure and get right, so lots of big companies just offshore things like this as they don’t want to deal with it with FTEs. Then the budget for maintenance gets deprioritized and cut as a whole for all these little systems that keep projects humming along. Probably just as many misconfigured wikis, git servers, etc through a rats nest of different VPNs and providers. It gets really expensive really fast to host these things right and in a way where accessibility for valid folks is still reasonable.
I think we are at the point of risk where the volume of discoverable information is so great that the parties at "risk" are needles in the haystack. There may be some analytical value in combing the available data, but if a specific target were interesting, they are probably already compromised.
In a way, it is to say that few organizations have especially interesting information. The few that do can be compromised with social approaches. So exposures such as these are becoming less and less embarrassing. Every organization is dysfunctional to some degree, and every org has some communications that (especially taken out of context) might raise eyebrows; but that is life, and that is what happens when you gather numbers of people in one place.
Point is, stories like these are useful for adding to a corporate checklist of exposure safety, but they aren't worth much else (unless of course the org holds secrets that could hugely disrupt the world).
This very much depends on specific threats, opponents, risks, and the interactions of these: your (perceived, actual) threat model.
Some years back as a member of a third-party services provider I had to sit through the e-learning session of a very large financial services provider. The course (tediously boring, natch) established three tiers of information importance, with the highest being not consumer information, but the organisation's own marketing and product plans.
Which is precisely what you're going to find in a Jira or equivalent project planning trove.
The risks of a lawful competitor running across this are ... reasonably low in many, though not all cases (see the Waymo smart car case for risks involved), though there are certainly cases of corporate espionage.
And petty criminals are somewhat unlikely to see much use from this.
But, to draw from recent HN posts: the ability to specificaly target developers to drop malicious payloads, for foreign governments to exfiltrate technologies or identify individuals to target for enhanced surveillance, to blackmail, to thwart or confuse plans, etc., all exist.
Information of itself is not power, but information with both the impunity to acquire it and the ability to act on it most certainly is.
And that's where Jira-class risks are significant.
> by default the visibility is set to “All users” and “Everyone” respectively, which instead of sharing with everyone of the organizations (which people think and interpret), it share them publically [sic]
To test if you are vulnerable, check whether you can publicly load one of these URIs on your domain:
inurl:/UserPickerBrowser.jspa -intitle:Login -intitle:Log
inurl:/ManageFilters.jspa?filterView=popular AND ( intext:All users OR intext:Shared with the public OR intext:Public )
It gets worse. You can modify those permissions, but every single Jira page that involves a permission check (and they get pretty granular) involves a nontrivial query to the user DB (which might, itself, involve a query to a backend like LDAP) to determine if you can do a thing or, critically, see the UI element to do the thing.
Best guidance when I was running Jiras were to restrict access at the network if at all possible, and don't use permissions any more than strictly necessary unless you like 5-10 seconds per page load. In other words, if only your developers need to see your Jira, don't grant only your developer group permissions, set it to "everyone" and lock everyone else out at the firewall.
We run massive JIRA instances with very granular permissions using multiple custom authorization backends (LDAP/Kerberos/in-house stuff), and it doesn't seem to add much of a delay.
Hm. Perhaps they took some time and worked on the performance then. It was ungodly slow a couple years back, and relaxing permissions led to a significant performance boost.
When you setup an S3 bucket the permissions are pretty explicit. The issue here is the UI is confusing (arguably it's wrong but I digress) and is related to a configuration that you'd have to hunt for. It's not an obvious permission that you can easily know it should be changed unless you have experience with it (whereas S3 it's listed right there when you created it and by default it's pretty private).
It didn’t used to be. When you set up a bucket with public read access, you might also decide to give other people on your team write access to the bucket. AWS conveniently provided an All Users option for this.
Except it wasn’t “All Users in your AWS account”, it literally meant ALL USERS of AWS. Disaster. This led to the same problems as this Jira issue.
AWS changed it so that’s no longer an option. Atlassian should do the same.
Would we? Amazon requires you to explicitly make the bucket open. It also allows you to prevent that account-wide with IAM policies. It also allows delegating the opening to public to specific people.
And I believe you get warnings about public buckets from their advisor. (May be misremembering that one) You can easily audit that too.
So basically I don't see what else could AWS do to make this more secure. It's 100% on the user at this point.
Huh? It seems the exact opposite of that. The top comment here is blaming Jira[1]. But when Capital One got hacked last week due to apparently some AWS misconfiguration, it seemed no one blamed AWS (even though the hacker had previously worked at AWS)[2].
The instance at the company I work at isn't exposed. But it isn't firewalled off/behind a VPN because our clients can also log in and create/update tickets.
Some companies have customer-facing dashboards. The AdTech company I used to work for had kanban boards that were visible to major clients for them to track the on boarding status of their data. Honestly, it was much better than having to email them all the time.
Because (in theory) the Atlassian stack is sufficiently hardened and can be safely run over the public internet.
The idea that everything must be behind a VPN at all times and you must hit the exact same login form twice to do anything is silly and why most office staff love off-prem services.
It's not everything, it's services that are only used internally (which might or might not be the case for Jira depending on the use case).
There's no two login forms anyway if your IT doesn't want it to be, on one hand VPNs are usually not accessed on demand during the work day and on the other hand all Jira versions I'm aware of can be integrated with some form of SSO anyway if you feel like it. Offices are usually internal and wouldn't have to deal with a VPN anyway.
The problem is that my fellow IT people define "only used internally" to mean "only used by employees" instead of "only useful to someone physically at our office."
Protect your VPN with SSO and then protect your service with the same SSO is incredibly common and perfectly demonstrates, in my view, the stupidity of VPNs.
The VPN added NOTHING to your your authentication or authorization.
If you're going to fully check a users credentials at the VPN where users are in a totally untrusted domain and fully check them again at the service then clearly your internal network is also being considered an untrusted domain -- which I think should be the case -- but then all the VPN does is move users from one untrusted domain to another. Why is the VPN there?
I think offices would actually be more secure if services like this were only accessible externally (doesn't have to be literally, just philosophically no reason to route out and back in your WAN). Instead of connecting to a VPN and having access to the internal network where there's probably a lot of surface area exposed the external only model means that you're only connected to the single service you authenticated to.
I don't think I get this argumentation. VPNs are easy to use these days so there's no "physically at our office" angle imho. The VPN adds a zone that the client can trust (which should not entail your whole internal network being exposed to it but I've never seen that anywhere to be quite honest). They get their Windows/AV/whatnot updates from that, connect to the services they need on the road.
Simultaneously the VPN shields said services in a managable way, though that's more of a on-premise vs. cloud discussion I feel like, with the VPN being the way to get access to the on-premise stuff if you do not happen to be in the office. Maybe I'm missing your alternative? VPNs have some upsides over, say, a reverse proxy for that use case (weird sales clients for example that talk TCP, not HTTPS) in the setups I've seen.
It also prevents exposure to the exact scenario we see in this very thread. Finding public instances of popular software is easy, enabling drive-by exposure to vulnerabilities. Putting them behind a proxy/VPN at least provides a hurdle for non-targeted attacks from my point of view.
Except the homeowner doesn't own the alarm. It's more like a mapmaker allowing access to the index of the map, which a clever person happened to figure out revealed where some houses with broken locks are. And the mapmaker has the decency to say "hey, let's see if this visitor is at least human" before allowing you to proceed from the index to the map itself.
Ok, now the mapmaker has solid evidence that this human is doing something shady.
So, in the documentation, "all" was very unclear. Users guessed that "all" meant all in the company while it mean all in the whole world!
So, wildly ambiguous, unclear, dangerous product documentation.
Could clear that up by being really clear and explicit about "all in the world", "all in the company", "all in a particular project", etc. and then lots of very clear examples.
But it was easier just to have some check box, icon, etc. described as "all".
In current computing, such documentation nonsense is usually resolved by the usual way of making sense of a computer user interface, experimentation, or use the TIFO method (try it and find out), or throw the options and combinations of options over and over against a wall to see which ones appear to stick, or do the usual, my usual description, "mud wrestling", all due to bad documentation.
It is as if the software were designed and written by people who thought that a check box with "all" was all there was to the work.
Well, in this case the TIFO experimentation involved hundreds of Fortune 500 companies and many other organizations, small to the largest, around the world.
It is as if the documentation writers were inarticulate and essentially illiterate.
So, Xerox PARC thought that some buttons, say, as on a microwave oven, would be sufficient for controlling lots of Xerox office machines. Then the computer industry, with graphical user interfaces thought that nearly all of computing could also have such a user interface. Nope: Commonly even makers of microwave ovens have well written users guides. The many millions of Web site user interfaces are generally much more complicated to control than a microwave oven and also need good DOCUMENTATION, e.g., much more then cryptic, not a chapter, paragraph, or sentence, not with examples, clear definitions, etc., but just a word or two from a roll over. And often there is just an icon, can't pronounce it, can't spell it, can't type it in text, can't send it in e-mail, can't look it up in a dictionary or with a search engine -- which takes us back to pictographs before the Roman alphabet. That situation, in technical language, is a bummer; more clearly a disaster as the OP shows.
IMHO, a good candidate for the biggest bottleneck in the future of computing is the quite general lack of good technical documentation.
E.g., two weeks ago I signed up with a different Internet access provider (ISP). They promised me I could have up to five e-mail addresses. Sooo, I tried to get a second address for the alpha test I plan for my project (Web site -- no icons!). It took 14 hours of my time and nearly that much time with third level technical support. With decent documentation, I could have done all the work in about 10 minutes. But, three days ago their Internet service quit in my neighborhood. Their efforts to reset my equipment (cable modem, IP router, WiFi connection) make my connection from before the outage work no longer. The fix took a day and a half, about 30 hours of my time, and about 15 hours on their third and fourth level technical support. With decent technical documentation, I could have fixed the problem myself in 10 minutes. And I have MANY other such examples. Several hours or days instead of a few minutes -- HUGE bottleneck to progress.
I say again: One of the worst bottlenecks in the future of computing is the lack of decent technical documentation, in a natural language, e.g., English, and mostly in text. No joke, guys. Icons, check boxes, radio buttons, text boxes, pull downs, pop ups, roll overs, etc., are NOT and can never be good natural language technical documentation.
TIFO on world-class issues is a huge disaster waiting to happen.
I'm all for good documentation, because not everyone learns in the same way, and if you have a product as broadly used as Jira, I think its user base deserves it. But in the basis it's just an inefficient, after the fact attempt to mitigate poor UI/UX. Which could EASILY have been clearer about the access rules, and they could (should) have defaulted to a more restrictive setting. First of all to protect users against the clearly more damaging of the two extremes (too restrictive versus not restrictive enough) but also because it better fits Jira's nominal use case.
I take your point about icons without text but I would guess for 90% of people all the buttons on the microwave are blank except the time keypad, the start button, and maybe the power level setting. No one reads the manual.
I just moved and now have a refrigerator that promises to make ice and dispense it.
Well, it didn't make ice. Since it would dispense water, the water line WAS connected and working.
Well, the front door has lots of buttons. They didn't help.
Finally the solution: Look in the freezer. At the top pull out a complicated plastic piece of unknown utility. For me, bend down, look up, look at the back wall of the freezer in the upper left corner, and see a switch, ON-OFF. It was OFF. Now it's on, and the ice maker is working!
I needed a manual and didn't have one.
The documentation I mentioned is important, for microwave ovens, fancy refrigerators, and certainly for the user interface of high end software that can have disasters such as in the OP.
And I also just verified by checking myself against some known Jira dashboards and searching for some of the search queries he provided... I'm not sure what there isn't to trust when he tells you exactly how to verify the information.
To prevent this issue as a site admin on Jira cloud, go to:
and disable "Allow users to share dashboards and filters with the public." This doesn't affect existing filters, which you have to manually fix.In true Jira fashion, if you try to reassign a filter after flipping this setting, it will deny the operation and ask you to edit the ACL, which there is no convenient admin UI to do.
Jira is a disaster of UX.