How can I find inside a Birt Report, who is currentUser

[Gregory Kneller]

I use Birt reports, and I what to make sure that users cannot see the report data, that they are not supposed to see due to their permissions (such as user groups or security levels).

Is there any way to pass the user name of current user, who is running the report from Power Report gadget, into the sql code of the report?

[Brice Gestas _Elements_ · Accepted solution]

Hello Gregory,

To retrieve the current logged in user (the one who generates the report) into BIRT report template, you have to declare a new report parameter called _rp_JIRAUserConnected as it is described into online documentation => https://confluence.valiantys.com/display/PWR/%27On+the+fly%27+Mode+Specifics

Cheers

[Gregory Kneller]

Brice, I cannot test it now, but thanks - it looks really as the answer. So now I could try to write an sql to retrive the security levels

[Gregory Kneller]

Brice, how to use the parameter? could you give an example of a report file where it is used in sql?

[Brice Gestas _Elements_]

Hello Gregory,

You have a sample template on this page => https://confluence.valiantys.com/display/PWR/Quick+Start.

You can have a look at it to see how it is used.

Cheers

[Pablo Beltran]

You have not to care about the logged in JIRA user if you use the Birt Reports for JIRA add-on which it resolves in a state-of-the-art way all the issues mentioned by Nick about running an external reporting tool just because it runs BIRT as an internal reporting tool 

[Nic Brough -Adaptavist-]

This is one of the main reasons for avoiding external reporting against Jira data.

Your reporting tool needs to replicate ALL of Jiras functional logic on who can see what. You need to decide how the tool is going to ask (and worse, enforce) "which Jira user am I running as", then pass that information into the potentially quite complex SQL to run the data queries as though that user were doing it in Jira.

[Gregory Kneller]

Nic, thank you for your advice. However, using external reporting is not in question, I feel pretty confident with sql and jira tables. There is no native way to get the reports I need.

[Nic Brough -Adaptavist-]

Ok, so you'll need to read the permission scheme for each issue, work out if the user you are running matches the "browse" criteria (bearing in mind these can be dynamic, not just role/group - you may have to cross-reference custom field content, security schemes, and the project info). This is complex, hard work, and I've never seen it done usefully anywhere. It once tripled the size of an "upgrade Jira" project, and the answer was "dump the external reporting and write a report plugin for Jira".

[Gregory Kneller]

Nic, thank you for advice. I will try to simplify the task using some assumptions (like not to check browse permissions, assuming that issue security level is enough; or to check only groups, because in my project i do not use more complicated permissions). I mean, I would not probably cover very general case, but I am sure that it is feasible to write an sql function for it

[Pablo Beltran]

SQL for JIRA resolves in a natural way the problem mentioned by Nick because it takes always the logged in JIRA user from the session in order to fetch data which the user has enough privileges to see only: https://marketplace.atlassian.com/plugins/com.kintosot.jira.jdbc4jql