This is a collection of resolutions and problems that are related with nVision Security.
Query security and security for nVision
Does query security also cover security for nVision?
Do you also need to setup separate security within nVision?
Do you need to implement and administer nVision Ledger Security in an environment with BU and Ledger security turned on and administered to the Operator Class, and with the secured reporting view specified in the record properties for each table that we want to secure on these two fields?
We have to add this view to the record properties for Query security. And if Query runs behind nVision, will the Query row level security be in force and be adequate to restrict the nVision results?
The nVision security is a separate security from GL security. User will need to turned both the Query security and the nVision security on
Operator Security: nVision Must set up security authorizing Operator access to nVision reports.
nVision Security and Reporting Views: Reporting views (secured views) allow you to take advantage of row level security within nVision. To use reporting views, you specify LED_RPTG_VW in the field ‘Report View’ on the Detail Ledger Definition panel. This is an optional field. If no view is specified, nVision allows anyone to report from that ledger. Then you set up the Business Units and ledgers that operators can access under Security Tables|Ledger Security. Access must be specifically granted for each business unit the operator can report from. If a user runs an nVision report and has zeros returned instead of the data expected, they may be using reporting views and not know it.
Setup Security by Set ID:
GO>DEFINE BUSINESS RULES>ADMINISTER SECURITY>USE>TABLESET CLASS SECURITY.
How do you secure nVision Report Requests: Report Request security is handled through the Security Administrator. Simply open up the operator id (or class) and go to the Menu Items section. You’ll see the menu item called “NVISION.” Double click on this and you can secure the various actions a user can perform with a report request. You can control their ability to Open, Run, Edit, and Delete them.
Currently it is not possible to secure the requests by business unit. Unfortunately the normal drop down security for the business unit field does not apply to the nVision dialog boxes. There is an enhancement to address this: T-EUYCHACO-7DG03. However, it is still possible to activate nVision row-level security for the business unit field. So, if a user runs a request for a business unit they don’t have access to (in the LED_AUTH_TBL) they’ll just get a report with all zeros on it. Please see the PeopleTools PeopleBook for a complete explanation on activating nVision row-level security.
Can you secure nVision reports and/or layouts by the report id:
The only way to secure nVision layouts is through network security. Each report “creator” can have a special network directory where their layouts are saved. No one else will have access to this directory. This prevents other people from accessing and modifying those layouts. In addition you cannot secure report requests by operator class. You can only secure the directory template via network security. When the report runs, if the user does not have access to the instance network directory the report will not complete successfully.
Tree-based Security: Using trees to create authorization tables combines ease of use with efficiency in implementing security provisions. Security is maintained using a tree that, for example, rolls up combinations of ChartFields. You would then use a batch process to translate the security provisions from the tree nodes into an authorization table. The detailed authorization table can be used with the ledger table to form a secured nVision Reporting View. The VIEW name is then entered on the Ledger Template panel in the Secured Reporting View field.
How do I build such a tree? Is it based off of OPERID or the particular ChartField, like department? I take it that there is a particular tree for each ChartField/security…ie one for departmental security and another tree is for account security and so one. Also, are there any examples of the batch files that we have to write to translate the trees into the authorization table? An example would be much appreciated.
PeopleSoft does not provide an example of a batch program that loads the LED_AUTH_TBL from a tree. However, building the security trees is easy. You’d have one tree for each chartfield you’re trying to secure. The nodes on the tree would correspond to the OPRCLASSes (or OPRID’s) you’re trying to secure. Underneath those nodes you can have the ranges (or singular values) of departments (or accounts, etc…) that those operator classes (or id’s) have access to. You do not need a special tree structure for this. The operator classes simply become node names.
Once the trees are built a custom program must be written to extract the tree data into the LED_AUTH_TBL. This authorization table is delivered as an example only. Your authorization table may differ significantly depending on your security design. To create the secured reporting view you simply join your authorization table to PS_LEDGER. Our delivered LED_RPTG_VW is just an example of a secured reporting view.
Options for securing data when nVision reports are run:
User has P&L reports that are run for every store in the USA. Each store has access to PeopleSoft but users are not able to run nVision reports. At month end all of the P&L reports are run from a centralized location (headquarters) and then they are distributed to each store via a secured web server. The User has to manually place each report in a secured location on the web server because the User does not want the stores to look at data for another store. The User only wants each store to see their own numbers. What are the options for securing these reports? Can anything be automated through nVision security options?
Options:
1) User can set up a Secured Reporting View for the “Stores” chartfield and they let the stores run their own nVision reports. (Each store does have access to PeopleSoft). This way if the store tried to run a report request that was for another store the report would just return zeros.
2) User set up a report request for each store. In the report request they hard code the network directory they want the report to land in. Each store would have their own secured network directory. Each report request would be pointed to each secured directory. Then, the reports would be run through Report Books. The output would automatically land in each secured directory and the stores would go into their directory and view the report.
The User understood both options. User said they do not want the stores to be able to run reports at all. (Training issues, etc.) User said that there is no common network that all of the stores can access so option 2 probably wouldn’t work for them. I told them that they are probably doing the best thing right now for their situation. User has to set up some sort of email distribution or web site thing but this would be outside of PeopleSoft at this point.
How do you secure nVision reports by business unit or any of the other chartfields:
This is accomplished by establishing a “Secured Reporting View” and attaching this view to the Ledger Templates. Detailed documentation is available in the PeopleTools PeopleBook under the nVision security section. PeopleSoft delivers an example of row level security by business unit and ledger. The two tables we deliver are LED_AUTH_TBL and LED_RPTG_VW.
If you want to change the delivered business unit and ledger security (and secure by another chartfield like DEPTID) you need to modify the LED_AUTH_TBL and add the new chartfields. You also need to modify the nVision security panel (in Security Administrator) to reflect the new fields.NV: nVision Row Level Security
Secure your XNV: You need to go to Start> People Tools>Operator Security >File > Open > select All Panel> This will bring up The select Menu Items Panel. From this screen you can set your security. Once you have chosen your security you must back out of People Soft and log back in. It is also a good idea to delete your Cache.
You may also may also create a protected directory and put your xnv’s in that and make it read only.
Apply Row-Level Security to nVision by OprClass instead of Oprid:
Clone LED_RPTG_VW record and save it according to your naming standards (e.g. LED_RPTG_VW_XXX).
? Add OPRCLASS (or ROWSECCLASS)
? Key Value
? Required
? Table Edit
? Prompt Table Edit
? Prompt Table = OPRCLASS_VW
? Delete OPRID
? Rebuild PeopleSoft view
? Rebuild Database view (Oracle)
2. Modify LED_AUTH_TBL record
? Add OPRCLASS (or ROWSECCLASS)
? Key Value
? Search Key
? List Box Item
? Required
? Table Edit
? Prompt Table Edit
? Prompt Table = OPRCLASS_VW
? Delete OPRID
? Add BUSINESS_UNIT, if not already included.
? Rebuild the PeopleSoft table
? Rebuild the Database table (Oracle)
? Change the Object Properties, Type SQL View text from OPRID to OPRCLASS
3. Modify the LEDGER_SECURITY panel
? Change Parent Record (labeled dummy name, if record already modified, OPRID otherwise) to OPRCLASS (or ROWSECCLASS)
? Change the label to RFT Short or Long
4. Modify the LEDGER_SECURITY panel group
? Change panel group properties search record to OPRCLASS_VW (or ROWSECCLASS) from OPRID_VW
5. Define LED_RPTG_VW_XXX in the Ledger Template
6. Enter all combinations of OPRCLASS (or ROWSECCLASS) and Business units in the nVsion security panel for operator class. If ranges are more desirable (i.e. BU?s are sequential), it is possible to accommodate. Will discuss further if needed.
7. Try the results in nVision
Note: Files in PSG Library under Joel Glidden “Secured Reporting View by Operator Class rather than Operator ID”
Limit Access to certain Report Books (Security):
This process can be done with some heavy customization. The User will first need to go into the NVS_BookDefn Panel under Application Designer and then find the search Record for that Panel which is PSNSVSBOOK. When the search record is open the next step is to Click on the PeopleCode Display. Then they will need to insert the customized code under the SearchInit which will need to contain a view to limit this access
nVision security for layouts is ignored:
The User wants users of nVision to be able to open an nVision instance (XLS file) only and run a drilldown. They do not want a certain class to be able to open a layout (XNV file) and/or run a report. They have tried operator security for the menu nVision and when they take security away, operators still have the access.
nVision is designed in such a way that operators can be set up so that they can bring up instances and run drilldowns without ever having permission to open a layout or run a report. This is done using operator security. (Security Administrator for release 7.) There are two things to keep in mind though:
1. After making any change to security, you must log that user off, and then back on. It is also best to clear the cache files for that workstation as well.
2. When security is taken away for a particular function, such as Report Request, you are still able to select that item from the menu. However, when the Report Request window appears, all fields will be greyed out and inactive.
NOTE: In Security Administrator when you unhighlight the option for Open_Report it still is not removed from the dropdown in nVision. This problem will be addressed in Release 8
nVision reports are returning zero amounts when row level security is activated:
The User is using a secured reporting view in order to enable row-level security in nVision. When they run the reports they are returning zero amounts.
The User’s LED_AUTH_TBL was empty. As a result, the LED_RPTG_VW contained no data and hence no amounts were retrieved when the nVision reports were run. The User populated the LED_AUTH_TBL (they had a custom panel since their LED_AUTH_TBL also secured by DEPTID) and the reports started retrieving data.
All of the operator Id’s or classes that will use nVision must be set up in the LED_AUTH_TBL. You cannot just activate security for a few operators and assume that all of the other operators will have full access.
nVision Security – Can view everything and run everything:
The Ledger reporting view was not specified through the Maintain Ledgers panel
User needed to specify the ledger reporting view (LED_RPTG_VW) through the Maintain Ledgers menu. Otherwise they had everything else set up incorrectly.
Business Unit, setid and ledger prompt security in nVision:
Currently, row-level security on BU, TableSet and Ledger in the on-line system does not apply to dialogs with nVision. Although nVision Ledger Security protects the data in particular Ledgers, it doesn’t prevent modifying/using Report Requests, Scopes, Trees, etc. keyed by BU or TableSet. In addition, users can create Layouts containing Ledgers which they are not authorized to access at run time.
This has been logged an Enhancement Request R-DXB-89 (Tools) and T-EMOU-IE91T
Status: Scope in Progress – Targeted for Release 9 of Tools.
Summary: Add BU, TableSet, Ledger Prompt Security to PS/nVision
Query-based drill downs don’t inherit the security established with Secured Reporting Views:
Users are using a security view to filter access to our Ledger table. Users have four drilldowns that won’t retain the security when the drill downs are run.
The four drill downs the user is having a problem with Query-based drill downs. The reason these drill downs are not inheriting the row-level security they have set up for the Ledgers is because these queries don’t access the PS_LEDGER table. nVision Secured Reporting Views only work when the data is being retrieved from the PS_LEDGER table (i.e., using a matrix layout for your drill down layout). When users are using a query based drill down, nVision does not use the Ledger table to get the data. It gets the data from the tables you’ve defined in your query.
Spreadsheet Journal Import not recognizing Business Unit security:
User has set up security through the Define Business Rules/Administer Security/Use/Operator Class to allow a user to have access to one Business Unit only. He entered the records and ran the FIN9001 to update PeopleTools security.
He logged under the ID having access to one Business Unit and entered items in the Spreadsheet Journal Import for a Business Unit other than the one he was assigned access to. He then pressed the Import button and the journals were successfully uploaded. Though he could not view or post the entries under the Business Unit he was restricted from, they were still processed and uploaded without incident. User believes this to be a significant issue.
Improper Joining of Security view and new Ledger Template:
User has created a new Ledger Template and added a custom View to the Secured Rptg Vw. He runs his report and it defaults back to the Standard Ledger Template.
This user had changed the Layout to use the new Ledger Template at a Global Level. He did not change the drilldown column criteria to use this new Ledger. The drilldowns where still referencing the delivered Standard Ledger.
nVision row level security does not work for budgets data:
User states that he set up his nVision row level security by the book, page 8-8 in the Reporting and Analysis Tools book, and is having problems getting it to work for their Budgets ledger. It will work for Actuals, but not for Budgets. Is this a known problem?
Where is the User storing their budgets data – in PS_LEDGER or PS_LEDGER_BUDG? If they’re using PS_LEDGER_BUDG the delivered example for nVision secured reporting won’t work. The PS_LED_RPTG_VW only looks at the PS_LEDGER table.
Issue: Any one who has access to the Report Request page will have access to run all the reports
PeopleSoft has recently discovered that someone has opened up NT Security to give full access to all users. When I tried to restrict access to the PeopleSoft program and reports directory to Add and Read only, no user was able to run nVision reports. Is there any documentation as to what the minimum access is needed for nVision to function properly from the NT4 Server (directory or file level needed)?
The User had changed the ‘Report Instance” directory (as defined in Configuration Manager) to be Read Only. This is a problem since nVision will write it’s output to this location (unless it is overridden by the Directory Template in the Report Request). The user must have Write access to the output destination or the report will fail. All of the other nVision directories in Configuration Manger can be changed to Read Only.
