Page 1 of 1

Reporting Security

PostPosted: Fri Mar 19, 2010 2:04 pm
by Danny C
Whether v7 decides to go Crystal or Windows Reporting there should be security within Jiwa which will allow users to see (and run) reports or have them invisible.

Classic example is where users have no need to see General Ledger stuff, but currently the reports are still executable. The reports should also be restricted via user (or role) security.

I know that we can currently control report execution at the SQL level by setting SQL security based on the JiwaReports user, but that is cumbersome & technical & needs to be done by us JSPs.

cheers

Re: Reporting Security

PostPosted: Fri Mar 19, 2010 2:10 pm
by jiwameister
Agreed, but one method could be that reports be attached to roles. So that if you belong to a specific role, you would have access to the list of reports. Given that the reports definition would be stored in the database, it should be possible to only return the list of reports that are accessible by role.

To make things easier for us JSP - there could be a default setup based on most likely use by role - leaving it to be modified customer by customer.

Re: Reporting Security

PostPosted: Fri Mar 19, 2010 4:00 pm
by Danny C
yep - roles with report permissions would achieve it too.

Re: Reporting Security

PostPosted: Sat Mar 20, 2010 2:47 am
by Mike.Sheen
Danny C wrote:Whether v7 decides to go Crystal or Windows Reporting there should be security within Jiwa which will allow users to see (and run) reports or have them invisible.

Classic example is where users have no need to see General Ledger stuff, but currently the reports are still executable. The reports should also be restricted via user (or role) security.

I know that we can currently control report execution at the SQL level by setting SQL security based on the JiwaReports user, but that is cumbersome & technical & needs to be done by us JSPs.

cheers


Can't you do this by having those users have a menu without such reports on it - and not giving them permission to edit menu's or change their assigned menu ?

Re: Reporting Security

PostPosted: Mon Apr 19, 2010 3:26 pm
by jiwameister
Mike.Sheen wrote:Can't you do this by having those users have a menu without such reports on it - and not giving them permission to edit menu's or change their assigned menu ?


Unless I am confused, I think you can have menu's for people, and that the menu will apply to whoever has the same menu definition.

What I was referring to was the ability to say - ok this user is part of the Financial Reporting role, but also the Sales Reporting Role, and their menu would build dynamically based on that.

What you are suggesting I think, would require a new menu definition with reports on it, for every potential role combination that may exist.

Re: Reporting Security

PostPosted: Tue Apr 27, 2010 10:25 pm
by Mike.Sheen
jiwameister wrote:What I was referring to was the ability to say - ok this user is part of the Financial Reporting role, but also the Sales Reporting Role, and their menu would build dynamically based on that.

What you are suggesting I think, would require a new menu definition with reports on it, for every potential role combination that may exist.


Building a menu by masking multiple roles has been hotly debated in our office.

The Utopian outcome is what we all agree on wanting, but the technical details on how we achieve this elude us.

At this point I'm the security sentinel and have not seen an acceptable solution - rest assured the likes of Scott (Scott is an advocate of this feature) and yourself will present some sort of proposal in the future, and if it passes the security tests, it will be considered and subsequently implemented.

Until I can be completely satisfied security is not compromised, we cannot offer this feature.