Security Approach

knoxjr

knoxjr

Member
Implementing 8.9.3 and we want to have seperate security structures for each environment so security changes can be tested before affecting production.

We are looking for the pros and cons of
1. Having a uniquie F00950 table in each environment, or
2. Using just one system f00950 table and having parrallel roles defined for each environment.
3. ???

Your comments are appreciated
 
I vote you leave the duplicate tables out and just handle it with ROLES.
So you would have a set of ROLES for Production, a set for PY (CRP) and another for DV (DEV).
Then you don't have to deal with multiple sets of tables and OCM mappings and such.
 
I vote that you keep separate security tables. I would hate to set all of this up in one table, then have a new service pack that changes the security table and have to duplicate it anyway.

it brings up the issue of keeping the security setup straight between them, though. It would be nice to have a way to promote security workbench records like UDC records in OMW. This would be a good audit trail, too. hmmmm. another enhancement request.
 
I would suggest separate tables. This way you can fully test the security with less limitations. You can manipulate sequencing, *PUBLIC, etc without worrying about impacting other roles, or production users.
 
I prefer the one table / use Roles approach myself. Just for the simplicity and administration of it. How often do you feel you will make changes that will affect users globally? Should you need to make any changes that make you feel uncomfortable, you could setup a temporary copy in another environment to test.

If you go the multi-table route, I highly recommend few (one) Security Administrators or a frequent refresh plan. We went the two table route with many administrators and no one kept the tables in sync. We went back to the one table, one administrator route.
 
We use the one table approach. If we want to test something out prior to production, we either create a new group with the new functionality or we use a test group. We have one standing test group that is being constantly wiped out and refreshed. If we want to test something, we wiped out the settings for the test group, copy in the new stuff and give it a whirl. It works well for us.

Gregg Larkin
JDE System Administrator (CNC) / North America
Praxair, Inc.
 
Back
Top