Joseph_Sadler
Well Known Member
Re: Restricting access to CRP
Thanks a lot Owguru.
I was loosing hope that somebody would help us here.
This gives us far more than we have now, and I believe it is enough to make
it work.
World Vision Canada attempts to save on administrative costs as much as
possible,
so that we can help the children of war and poverty that much more.
God bless you for helping the kids. . . and have a Merry Christmas!
Joseph.
owguru
<[email protected] To: [email protected]
m> cc:
Sent by: Subject: Re: Restricting access to CRP
owner-jdeowdevml@j ~~2590:2651
delist.com
12/13/00 04:51 PM
Please respond to
jdeowdev
Having tried a host of ways to create this security, I can tell you it
isn't easy or pretty.
The most common test that DOESN'T WORK is to set row security on the
pathcode table (F00942). This can restrict access to checking in to other
pathcodes, but also restricts a lot of other necessary developer functions.
The only thing I've found that will work is to set database security on the
database to disallow developers to write to the prod central objects
database. Unfortunately with this the user can still select to check in to
production, but a database will pop up letting them know it failed. This
can also be a little hairy with oneworld's "master" database security
sign-on. If your developers use the same database pass-through user as all
the other user (typically this is the case), then you will be securing
everyone out of writing to prod pathcode. This would typically create
problems if your production users do things with versions, like setting
processing options, creating new batch versions and checking them in. They
too would be locked out unless they are assigned a separate system sign-on
with a different database security setup.
The good news is that the new omw in xe has added security features to help
with this. The bad news is that omw can be a pain in the a** to set up and
administrate... a lot more complicated than object librarian.
Good Luck
owguru (at least I'm trying
>all versions
>all platforms
--------------------------
Visit the forum to view this thread at:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat
=&Board=OWDEV&Number=2651
*************************************************************
This is the JDEList One World / XE Developers Mailing List.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found at http://www.JDELIST.com
*************************************************************
Thanks a lot Owguru.
I was loosing hope that somebody would help us here.
This gives us far more than we have now, and I believe it is enough to make
it work.
World Vision Canada attempts to save on administrative costs as much as
possible,
so that we can help the children of war and poverty that much more.
God bless you for helping the kids. . . and have a Merry Christmas!
Joseph.
owguru
<[email protected] To: [email protected]
m> cc:
Sent by: Subject: Re: Restricting access to CRP
owner-jdeowdevml@j ~~2590:2651
delist.com
12/13/00 04:51 PM
Please respond to
jdeowdev
Having tried a host of ways to create this security, I can tell you it
isn't easy or pretty.
The most common test that DOESN'T WORK is to set row security on the
pathcode table (F00942). This can restrict access to checking in to other
pathcodes, but also restricts a lot of other necessary developer functions.
The only thing I've found that will work is to set database security on the
database to disallow developers to write to the prod central objects
database. Unfortunately with this the user can still select to check in to
production, but a database will pop up letting them know it failed. This
can also be a little hairy with oneworld's "master" database security
sign-on. If your developers use the same database pass-through user as all
the other user (typically this is the case), then you will be securing
everyone out of writing to prod pathcode. This would typically create
problems if your production users do things with versions, like setting
processing options, creating new batch versions and checking them in. They
too would be locked out unless they are assigned a separate system sign-on
with a different database security setup.
The good news is that the new omw in xe has added security features to help
with this. The bad news is that omw can be a pain in the a** to set up and
administrate... a lot more complicated than object librarian.
Good Luck
owguru (at least I'm trying
>all versions
>all platforms
--------------------------
Visit the forum to view this thread at:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat
=&Board=OWDEV&Number=2651
*************************************************************
This is the JDEList One World / XE Developers Mailing List.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found at http://www.JDELIST.com
*************************************************************
