Restrict reporting ability in JIRA

[Christian Czaia _Decadis AG_]

Hi,

I have a question very similar to this one: https://answers.atlassian.com/questions/10496/remove-user-ability-to-report

Would it be possible to restrict the "report" button (on the project page) to a specific group / role? (As described for dashboards here:https://answers.atlassian.com/questions/29024/dashboard-managing-permissions-for-groups#56597)

My problem is that we have VERY strict laws governing data protection and data security in Germany. Manually filtering issues and creating a report based on the query requires more effort than just selecting a report in a dropdown box. Even though employees could always filter on issues management doesn't want them to have such an easy way to do so. I hope you understand what I mean.

For the same reason I needed to "hide" the option to create a new dashboard since the dashboard offers the same functionality (like pie chart gadgets).... It's all about preventing John Doe from analyzing the worklog, solution time etc. of Jane Doe.

Any ideas?

Thank you

Christian

[Nic Brough -Adaptavist- · Accepted solution]

No problem.

By raw data, I mean the data that you're entering into the system and then reporting on (although, yes, this is of course stored in the database/file system).

I quite like your Jane Doe/John Doe example, so I'll re-use it - the "raw data" in that case is the work logging that Jane is adding to issues in her project. For example "I did 4 hours on XYZ-123 on the 19th June 2012". Let's say John has access to that project (read access at least) and there's no other security settings. He'll be able to look at the worklog on XYZ-123 to see what Jane has done on it. Additionally, if he runs certain reports in Jira (workload, or a timesheet plugin etc), he'll be given information about that work, even if it's been manipulated into a summary.

So, if you make it impossible for him to see the reports, that's fine, but there is still nothing stopping him seeing the fact that Jane logged "I did 4 hours on XYZ-123 on the 19th June 2012". It might slow down any dubious analysis, or finger pointing, but he can still see, and hence extract, and hence work with, the raw data that Jane has logged it.

The point is that all the lawyers told me that the reporting was irrelevant, it's the raw data that matters. That has to be hidden from John, so that there's no way that he can do any form of analysis. If the information is privileged, he should not have access to *anything* that could expose the data to him, especially the actual raw data.

Jira does do some of this at one level - if a user cannot see an issue because of permissions, then all the properly written reporting (especially the built in stuff) will completely ignore that issue when someone runs a report. It filters the privileged data out before it even starts any analysis or reporting.

This can lead to odd reports in places where issue-level security is used - simple example - a shared dashboard with exactly the same settings was reporting a project to my InfoSec team as having 30 open issues for them to look at. When I ran it, I got a report of 6. Because I wasn't in a group that could read the protected issues. (Ok, as an admin, I can add myself, and if I bring cake to database people, I know what to look for, but you automatically have to trust admins...)

[Christian Czaia _Decadis AG_]

Thanks for your time and your detailed response. Now I have something to work with...I guess I'll suggest a broader usage of issue-level security.

Nevertheless, it's a pity that we have a collaboration tool people really like (many of which don't give a da... about data security) and limit it's power by law:-)

Cheers Christian

[Nic Brough -Adaptavist-]

Very true. Although, it does depend on what the data being stored is. Here, we've got a really simple structure - if you're in the organisation, you're ok to use the system and your contract covers misuse and inappropriate use of internal data.

But we've had to be very careful about a handful of projects because they hold data about personal email addresses, dates of personal events, etc, etc, etc. They're completely secured away from anyone but the core authorised users. A couple of these projects use issue-level security, but most of it is done at a project level.

[Christian Czaia _Decadis AG_]

I guess you'll have to find the right balance between security concerns (corporate secrets, misuse etc.) and efficiency without reducing the latter to a minimum.

[Nic Brough -Adaptavist-]

Er, no. I've been here before.

Stopping someone running a report is an utter waste of time. I am not a lawyer, of course, and I certainly don't know German law. But I've had this discussion a few times with UK, French, Dutch and European lawyers and they were consistent on the fact that you need to protect the raw data. Stopping reporting is not good enough, the raw data must be unavailable to unauthorised people. I'd be very surprised if that were significantly different in Germany (especially as you say the law is "very strict" - it's most certainly NOT strict if it allows you to expose raw data)

[Christian Czaia _Decadis AG_]

This was just a request from one of my customers. I don't know how they handle their data security internally and I'm far from being a lawyer myself . What do you mean by raw data? Data that's physically stored in the database or on the file server ?

If you have any further information on that matter I'd be very happy if you could help me out. From your perspective (experience) do European lawyers have a problem with the filtering and reporting features of JIRA? I mean they are restricted to those specifically involved in each project...

Sorry to bother you,

thank you Christian