riko44
Active Member
We planning to implement Reports security for some sensitive UBEs (Payroll/HR ones)
We have fairly big group of people (functional leads, Developers) who have access to everyone’s report outputs through WSJ. That is probably not a good thing, but that is the way it is at the moment.
One of the option we are researching is to create separate Job Queue for all HR/Payroll reports (R05*, R06*, R07* and R08* UBEs), and we would like to Default all such reports this new queue.
Then we are planning to implement row security on the F986110 table to limit access to the new ‘Payroll Queue’. I realize that this is not the greatest idea to put row security on Jobs table, but we still would like to test it.
I know that we can check-out version, go to Version Detail, change default Queue and check-in the version, and this will take care of our situation.
The problem is that there are about 1000 versions in 05-08 systems, and we have to repeat above steps for each individual version.
It also looks like Default Job queue is somehow encoded into the BLOB field in the F983051, so we can’t just run a simple SQL update.
I realize that we can try to identify HR/PR reports/version that will actually run in our system, and I am sure it’s going to be much smaller number. But I am not positive then we will not miss something.
With all that being said … I am wondering if there is another way to do mass Report/Version Default Job queue update based on our criteria ?
Any other ideas about securing payroll reports are also welcome.
So far we have also considered ideas of creating separate enterprise server for Payroll UBEs; Creating a custom code that will modify Queues names on the fly based on certain criteria or using 3rd party products
Thanks !
8.11SP1 8.95_O1
AIX 5.3 / Oracle 9
WAS 5.0.2 (Win 2003 server)
PS We are also putting additional security on the actual sensitive data in the database, but that is a different story.
We have fairly big group of people (functional leads, Developers) who have access to everyone’s report outputs through WSJ. That is probably not a good thing, but that is the way it is at the moment.
One of the option we are researching is to create separate Job Queue for all HR/Payroll reports (R05*, R06*, R07* and R08* UBEs), and we would like to Default all such reports this new queue.
Then we are planning to implement row security on the F986110 table to limit access to the new ‘Payroll Queue’. I realize that this is not the greatest idea to put row security on Jobs table, but we still would like to test it.
I know that we can check-out version, go to Version Detail, change default Queue and check-in the version, and this will take care of our situation.
The problem is that there are about 1000 versions in 05-08 systems, and we have to repeat above steps for each individual version.
It also looks like Default Job queue is somehow encoded into the BLOB field in the F983051, so we can’t just run a simple SQL update.
I realize that we can try to identify HR/PR reports/version that will actually run in our system, and I am sure it’s going to be much smaller number. But I am not positive then we will not miss something.
With all that being said … I am wondering if there is another way to do mass Report/Version Default Job queue update based on our criteria ?
Any other ideas about securing payroll reports are also welcome.
So far we have also considered ideas of creating separate enterprise server for Payroll UBEs; Creating a custom code that will modify Queues names on the fly based on certain criteria or using 3rd party products
Thanks !
8.11SP1 8.95_O1
AIX 5.3 / Oracle 9
WAS 5.0.2 (Win 2003 server)
PS We are also putting additional security on the actual sensitive data in the database, but that is a different story.
