Version Security

The philosophy appears to be open unless closed and I cannot figure out a way to change this. I would like to simply specify the version that I wish the role/user to have access to and have that appear on the menu once the task is defined for the report (as prompt for version).

One has to grant access to the report template in order for it to show up on the menu then deny all versions other than the one(s) desired. This creates an administrative burden by having to deny access to each newly created version or it is available by default.

I do not wish to create a separate task for each version.

Any ideas?

Jeff,

What about this? Put in *public, versions, deny all. Then grant back the ones that you want users to use? This will prevent the new ones from being instantly availible.

Gregg

Hi,

we have applied row security on VERS by role / user utilising the a value from and to of the version name and setting the permissions appropriately

The problem was that JDE does not naturally recognise this security, but there is a solution that was given to us by response line.

Here is the instruction to update the krnlspec to set up Row Security on DD Item VERS for F893051 table on fat client/deployment server.

1. Run the following command to extract the F983051 table spec from a windows command prompt.

krnlspec -Tam2Zip S:\PeopleSoft\E811\SYSTEM\bin32 c:\krnlspec.zip

2. Extract all the xml files from the zip file under C:\TEMP

3. Open the C:\Temp\GLBLTBL\F983051.xml in a text editor

4. Update the DataItem element with Alias as VERS to have CanHaveSecurity="true" attribute.

Here is an example

<TableColumn SQLColumnName="VRVERS">

<DataItem Alias="VERS" LongName="Version" SystemCode="51" EVDType="String" Type="A"

GlossaryClass="" Length="10" EditRuleFunction="" DisplayRuleFunction=""

CanHaveSecurity="true" ControlType="4" />

</TableColumn>

5. Save the F983051.xml

6. Zip up the GLBLTBL folder with all the xml files under C:\Temp\ in c:\temp\GLBLTBL.zip

file.

7. Back up the original jdekrnl.ddb and jdekrnl.xdb under S:\PeopleSoft\E811\system\bin32.

8. Run the following command to update the F983051 table spec

krnlspec -Zip2Tam c:\temp\GLBLTBL.zip S:\PeopleSoft\E811\SYSTEM\bin32

You then need to build an update package that will include and compress the founation and deploy to all fat clients that do package builds and/or generations.

You need to do this every time you ugrade your tools release or you will find out that you are quickly back to the beginning again.

I forgot to add that if you organise your versions names logically then you could set *PUBLIC to No / NO / No etc and then set to Yes the a range that your roles / users reports lie within. (i.e. From FIN To FINZZZZZZ) that way any new versions you create for that role within that range are already covered by your security entries.

[ QUOTE ]
Jeff,

What about this? Put in *public, versions, deny all. Then grant back the ones that you want users to use? This will prevent the new ones from being instantly availible.

Gregg

[/ QUOTE ]

Hmmmmm, interesting thought. Then I would have to grant access to *every* version I wanted the users to have access to- not an administrative task I want to bestow on anyone.

The way "version" security currently works is that one grants access to a report, thereby granting access to all that report's versions. If you then want to limit access to versions you must deny access to the versions you don't want a user/role to access. So, this is an open unless closed model which means that every time you add a version you have to ensure that you close security to it.

What I want is, at the report level, a closed unless opened model where, if you grant access to a report, you do not automatically have access to all versions. That way, if a new version is added one does not have access to it unless granted.

That's not asking much huh? All I need to do now is get Oracle to change the code.


Anyone have a better idea? Maybe I am missing something.

Terry,

I found your instructions most interesting. Please excuse my ignorance, but I have to ask: Will checking the Row Security Check Box at the bottom of the Work with Data Dictionary Items - Item Specifications Tab, screen will do the same thing? (see attached screen shot).

Hi,

we had the row security box checked.

Even though we had this checked it security did not work as we wanted. Apparently the DD Item VERS is a bootstrap item and ordinary security will not always work unless you follow the instructions I mentioned earlier.

This is particularly the case for our web users (E811.SP1 / TR's 8.96.D1 & 8.96.1.2 (in multi foundation)).

It may seem a lot of work but you only need to do it every time you do a TR upgrade. And as I mentioned earlier if you plan and devise your versions in relation to your roles you can set minimum and maximum ranges of the version name for that role and grant back that range to the entitled role(s).

Like everything within E1 if you want to setup something that will stand the test of time with minimal maintenance after that, you need to devote some time to planning it up front.

Please see solution 200980732 on customer connection for full explanation.

Terry,

Thanks for the additional information/explanation. It is good to be aware of the unique problems regarding bootstrap tables and columns.

I did a little investigation and here are some Solution IDs for information on bootstrap tables and columns:

The original that Terry mentioned:

SOLUTION ID: 200980732 E1: SEC: Row Security on Bootstrap table Data Dictionary Item

Others referenced that I could find:

SOLUTION ID: 200998497 E1: DD: Impact of Changing a Bootstrap Table Data Dictionary Item
SOLUTION ID: 200966230 E1: TDA: Adding custom index to bootstrap tables like F9312
SOLUTION ID: 201032987 E1: SEC: Row Security on F983051 and VERS is Not Working
SOLUTION ID: 201033947 E1: SEC: Unable to Apply Row Security on Bootstrap Tables

Others referenced that I could not find:

SOLUTION ID: 200955961 E1: FDA: Generating krnlspec Data Dictionary Items
SOLUTION ID: 201010861 E1: DD: How to Update JDEKRNL specs in EnterpriseOne