Securing One user against two environments

mgerritt

Well Known Member
We run 2 production environments, one for the main facility one for a subsidiary. The Subsidiary repackages and sells, but does not design and develop. The Main manufacturers, designs, repackages and sells.

Since the subsidiary does repair, they have asked to be able to view the Main facility's Bill of Materials for only one product line. So they can identify parts needed for repairs.

I would like to restrict these users ONLY to the BOM menu (our version od the G3011 menu) in the Main environment. HOWEVER, they must have full access to their own environment's menus.

I can bring them into MAIN on 3011. But I cannot restrict their movement from 3011 without locking out menu and fast path travel, which they need to simplify their production environment.

Further, I cannot restrict action security to I in Main, without also restricting it in Subsidiary. None of the security fucntions seem to be aware of LIBRARY, only program ID.

Any way in JDE that I am not seeing to restrict Action Code, Travel, anything else in one environment disfferently than in the other? We use one common library, but a different data library for each environment.

And yes, I am aware that I could probably code EACH menu item with the A J K DP F functions, but the time and complexity would seem to be utterly overwhelming for something that should be very straightforward.

Marc Gerritt
A7.3 CUM 13
 
Action code security is controlled by F0003, and business unit security by F0001. If you have these in each data library rather than a single copy in common you will be able to set them by environment.

Command entry, menu travel and fast path are controlled by F0092. This would normally be in your common or security library. If you want to vary these by environment you will need a separate f0092 for each one.
 
Marc,

Would business unit security help here? If your two sections were in
different Business Units then you could setup one range of access for
one group and another range of access for the other.

Douglas Belcher
KV Pharmaceutical
St Louis, MO
Opinions expressed are not necessarily those of my employer

_____

From: [email protected] [mailto:[email protected]]
On Behalf Of mgerritt
Sent: Thursday, February 02, 2006 9:37 AM
To: [email protected]
Subject: Securing One user against two environments


We run 2 production environments, one for the main facility one for a
subsidiary. The Subsidiary repackages and sells, but does not design and
develop. The Main manufacturers, designs, repackages and sells.

Since the subsidiary does repair, they have asked to be able to view the
Main facility's Bill of Materials for only one product line. So they can
identify parts needed for repairs.

I would like to restrict these users ONLY to the BOM menu (our version
od the G3011 menu) in the Main environment. HOWEVER, they must have full
access to their own environment's menus.

I can bring them into MAIN on 3011. But I cannot restrict their movement
from 3011 without locking out menu and fast path travel, which they need
to simplify their production environment.

Further, I cannot restrict action security to I in Main, without also
restricting it in Subsidiary. None of the security fucntions seem to be
aware of LIBRARY, only program ID.

Any way in JDE that I am not seeing to restrict Action Code, Travel,
anything else in one environment disfferently than in the other? We use
one common library, but a different data library for each environment.

And yes, I am aware that I could probably code EACH menu item with the A
J K DP F functions, but the time and complexity would seem to be utterly
overwhelming for something that should be very straightforward.

Marc Gerritt
A7.3 CUM 13

Marc Gerritt JDE WorldSoftware 7.3 cum 13

_____


The entire JDELIST thread
<http://www.jdelist.com/ubb/showflat.php?Cat=3D&Board=3D"W"&Number=3D"102 is available for viewing.

Looking for a job? Check out the Job Opportunites forum
This is the JDELIST World Mailing List.
The instructions on how to unsubscribe from any JDELIST mailing list are
available here <http://www.jdelist.com/unsubscr.shtml> .
JDELIST is not affiliated with JDEdwards(r).

.
 
Back
Top