OneWorld Security

Hi List,

We are on B7332, SQL/NT. Currently live on financials. Right now I am facing
an issue where I need to provide a finance user ERW development access, and
therefore access to Object Librarian, check in/check out etc. Most of our users
are on thin client, and I know this person needs to be on a fat client for any
development work. However, she is pretty green and still training. How can I
give her some access, yet not too much access? I realize security in OW is not
environment specific, although I know it can be setup by environment with lot of
work - so I am also concerned to give this user too much access to PROD, by
opening her up in CRP.

Is there any answer to this without having to setup security by environment (and
I don't want to go that path!). Any ideas or help is welcome. Thanks in
advance!

Dave
PCI Services

Hi Dave,
Here is a maybe silly idea from me:

What about to design your P9860 Object Librarian application?
You can acces the SL UserID and SL Environment system variables as well as selected object, object type, check-out and check-in location, etc., so you are totaly free to make additinal and special restrictions based on these informations for any of the actions in OL?
I suppose, it is much more simplier then making security to an environment dependent one, supposing that you are a bit experienced in using FDA.

Does it sound too foolish?
If not, then here is two additional hints:
1.) Do not forget to secure the check-out and design for P9860 application.
2.) Do not be surprised when your OW session hangs after you designed P9860 starting from P9860, simply restart your OW.

I am very curious that will you choose this method, so please, let us know your results if yes. Thanks.
Zoltán



B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)

What about a second ID with high security access with access to CRP only?

Crawford

Security in OneWorld is not environment specific. It only comes out of the
box this way. Changing security so it is not environment specific is not
rocket science - it's actually pretty easy if you know your OCM's and how to
copy a table in SQL/Oracle or in Object Librarian.

You can either give the user different security in the two environments (I
know you don't want to do this) or give the user two different profiles in
the two environments. Either solution will allow the user to use one ID
instead of two user ID.

Both solutions require two copies of either the security table F00950 or the
user profiles table F0092. Theoretically you could have an infinite number
of security tables or user profile tables - that's the beauty of OCM!

To give the user ie 'JOEUSER' the profile of 'FINANCE' in Production but
'DEVELOPER' in Crp you need to do the following: Copy the F0092 from the
System data source to Control Tables Prod. Next create an OCM for 'JOEUSER'
or '*PUBLIC' for the PROD environment that point the F0092 to Control Tables
PROD. The only consequence of this method is that if you remap the OCM for
'*PUBLIC' then you as the admin will have to sign into PROD to change the
PROD profiles for any user. You would still sign into CRP, TST or DEV to
change the any of these profiles as all these environments would still point
to system tables. I'm not using this method right now but I've tested it
with a few users and it works.

The other way you can do this is to copy the F00950 from the System Data
source to Control Tables Prod. Again create an OCM that point 'JOEUSER' or
'*PUBLIC' to this security table. I use this method to ensure that no
changes are made directly to the production security table. Changes are made
to the system security table, tested and then the table is copied into
production.

The other thing I would do is to put row security on the pathcode for the
two different profiles (if you go this way). This would restrict this user
to only being able to check-in or check-out of DEV. This is also what I call
the poor man's OMW (Object Management Workbench). Things are much easier on
Xe.

Table Data Item From Value Thru Value Add Change
Delete View Alias
*ALL CodePath CRPB733 CRPB733 Y Y Y Y
PATHCD
*ALL CodePath DEVB733 DEVB733 Y Y Y Y
PATHCD
*ALL CodePath PRISTB733 PRISTB733 N N N
N PATHCD
*ALL CodePath PRODB733 PRODB733 N N N
Y PATHCD

Hope this helps,


Colin




Colin Dawes, MSc
City of Guelph
B7332 SP13.1, Oracle 8.1.6, NT 4.0, Fat & WTS

Colin, maintaining multiple security tables seems more difficult.I am having
a hard time as it is controlling one but maybe that depends on how you
rolled out security in the first place.

Cheers,

Thanks a lot Colin for taking the time to document this for me. I'll have to
give it some thought if my best option would be to create security by
environment, and if so your document will certainly come handy.

Thanks again!

Dave






cdawes <[email protected]> on 02/22/2001 03:29:16 PM

Please respond to [email protected]
MailTo: [email protected]
cc: (bcc: Dave Laha/RLR/PCI/CHI/US)
Subject: RE: OneWorld Security



Security in OneWorld is not environment specific. It only comes out of the
box this way. Changing security so it is not environment specific is not
rocket science - it's actually pretty easy if you know your OCM's and how to
copy a table in SQL/Oracle or in Object Librarian.

You can either give the user different security in the two environments (I
know you don't want to do this) or give the user two different profiles in
the two environments. Either solution will allow the user to use one ID
instead of two user ID.

Both solutions require two copies of either the security table F00950 or the
user profiles table F0092. Theoretically you could have an infinite number
of security tables or user profile tables - that's the beauty of OCM!

To give the user ie 'JOEUSER' the profile of 'FINANCE' in Production but
'DEVELOPER' in Crp you need to do the following: Copy the F0092 from the
System data source to Control Tables Prod. Next create an OCM for 'JOEUSER'
or '*PUBLIC' for the PROD environment that point the F0092 to Control Tables
PROD. The only consequence of this method is that if you remap the OCM for
'*PUBLIC' then you as the admin will have to sign into PROD to change the
PROD profiles for any user. You would still sign into CRP, TST or DEV to
change the any of these profiles as all these environments would still point
to system tables. I'm not using this method right now but I've tested it
with a few users and it works.

The other way you can do this is to copy the F00950 from the System Data
source to Control Tables Prod. Again create an OCM that point 'JOEUSER' or
'*PUBLIC' to this security table. I use this method to ensure that no
changes are made directly to the production security table. Changes are made
to the system security table, tested and then the table is copied into
production.

The other thing I would do is to put row security on the pathcode for the
two different profiles (if you go this way). This would restrict this user
to only being able to check-in or check-out of DEV. This is also what I call
the poor man's OMW (Object Management Workbench). Things are much easier on
Xe.

Table Data Item From Value Thru Value Add Change
Delete View Alias
*ALL CodePath CRPB733 CRPB733 Y Y Y Y
PATHCD
*ALL CodePath DEVB733 DEVB733 Y Y Y Y
PATHCD
*ALL CodePath PRISTB733 PRISTB733 N N N
N PATHCD
*ALL CodePath PRODB733 PRODB733 N N N
Y PATHCD

Hope this helps,


Colin




Colin Dawes, MSc
City of Guelph
B7332 SP13.1, Oracle 8.1.6, NT 4.0, Fat & WTS
--------------------------
To view this thread, visit the JDEList forum at:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=6128
*************************************************************
This is the JDEList One World / XE Mailing List.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found at http://www.JDELIST.com
*************************************************************

Thanks Crawford, this certainly would be the simplest solution.

Dave






Crawford Winter <[email protected]> on 02/22/2001 01:45:40 PM

Please respond to [email protected]
MailTo: [email protected]
cc: (bcc: Dave Laha/RLR/PCI/CHI/US)
Subject: RE: OneWorld Security



What about a second ID with high security access with access to CRP only?

Crawford




--------------------------
To view this thread, visit the JDEList forum at:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=6116
*************************************************************
This is the JDEList One World / XE Mailing List.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found at http://www.JDELIST.com
*************************************************************

Dave,

Is setting her up with a second profile a valid option. If so, then you
could provide her with ERW access to the new profile, with access to only
CRP. And she is still properly secured in PROD.

Hope this helps.

AM


>From: dave laha <[email protected]>
>Reply-To: [email protected]
>To: [email protected]
>Subject: OneWorld Security
>Date: Thu, 22 Feb 2001 09:19:28 -0800 (PST)
>Received: from [216.122.12.105] by hotmail.com (3.2) with ESMTP id
>MHotMailBC5EA2FF003D40043211D87A0C69DFFC0; Thu Feb 22 10:18:48 2001
>Received: by jdelist.com (8.9.3/8.9.3) id JAA20260for a39685058; Thu, 22
>Feb 2001 09:19:35 -0800 (PST)
>Received: from shell.tsoft.com ([email protected] [198.144.192.5])by
>jdelist.com (8.9.3/8.9.3) with ESMTP id JAA20206for
><[email protected]>; Thu, 22 Feb 2001 09:19:31 -0800 (PST)
>Received: (from eric@localhost)by shell.tsoft.com (8.8.7/8.8.7) id
>JAA15123;Thu, 22 Feb 2001 09:19:28 -0800 (PST)
>From [email protected] Thu Feb 22 10:20:45 2001
>Message-Id: <[email protected]>
>X-Mailer: Mailer::1.0 (http://www.gossamer-threads.com/scripts/)
>Sender: [email protected]
>Precedence: bulk
>
>Hi List,
>
>We are on B7332, SQL/NT. Currently live on financials. Right now I am
>facing
>an issue where I need to provide a finance user ERW development access, and
>therefore access to Object Librarian, check in/check out etc. Most of our
>users
>are on thin client, and I know this person needs to be on a fat client for
>any
>development work. However, she is pretty green and still training. How
>can I
>give her some access, yet not too much access? I realize security in OW
>is not
>environment specific, although I know it can be setup by environment with
>lot of
>work - so I am also concerned to give this user too much access to PROD, by
>opening her up in CRP.
>
>Is there any answer to this without having to setup security by environment
>(and
>I don't want to go that path!). Any ideas or help is welcome. Thanks in
>advance!
>
>Dave
>PCI Services
>
>
>
>
>
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=6106
>*************************************************************
>This is the JDEList One World / XE Mailing List.
>Archives and information on how to SUBSCRIBE, and
>UNSUBSCRIBE can be found at http://www.JDELIST.com
>*************************************************************
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com