Row Security

I was wondering if anyone has encountered the same issue as us. We have
setup row security on the F0902/F0911 tables (among others). The user
attempts to post a batch that is for a company that they are excluded from.
The f0911 records are not written, but the F0902 are. We have verified the
security multiple times, and opened a call with JDE that has not gone
anywhere.
From what I can see, it looks like the business function that writes to the
F0902 never takes row security into consideration. It is called, and the
F0902 table is updated even though it is secured. Here is an excerpt from
the log which I sent to JDE:


UPDATE CRPDTA.F0902 SET
GBAID='08460440',GBCTRY=20.000000,GBFY=3.000000,GBFQ='
',GBLT='SG',GBSBL='
',GBCO='65000',GBAPYC=1230900.000000,GBAN01=1672600.000000,GBAN02=0.000000,G
BAN03=-2903500.000000,GBAN04=0.000000,GBAN05=0.000000,GBAN06=37000.000000,GB
AN07=0.000000,GBAN08=0.000000,GBAN09=0.000000,GBAN10=0.000000,GBAN11=0.00000
0,GBAN12=0.000000,GBAN13=0.000000,GBAN14=0.000000,GBAPYN=1230900.000000,GBAW
TD=-1193900.000000,GBBORG=0.000000,GBPOU=0.000000,GBPC=0.000000,GBTKER=0.000
000,GBBREQ=0.000000,GBBAPR=0.000000,GBMCU=' 65000',GBOBJ='1305
',GBSUB='
',GBUSER='PRODUSER',GBPID='ER09801',GBUPMJ=103169,GBJOBN='WAS_JDE_CR',GBSBLT
=' ',GBUPMT=142425.000000,GBCRCD=' ',GBCRCX='EUR' WHERE CURRENT OF
C298DE60
Jun 18 14:24:26 ** 3992/3284 Entering JDB_CloseTable(Table = F0902)
Jun 18 14:24:26 ** 3992/3284 Entering JDB_ClearSequencing
Jun 18 14:24:26 ** 3992/3284 Entering JDB_ClearSelection
Jun 18 14:24:26 ** 3992/3284 Entering JDB_ClearBuffers
Jun 18 14:24:26 ** 3992/3284 Exiting JDB_ClearBuffers with success.
Jun 18 14:24:26 ** 3992/3284 Exiting JDB_CloseTable(Table = F0902) with
Success
Jun 18 14:24:26 ** 3992/3284 Entering JDB_FreeUser
Jun 18 14:24:26 ** 3992/3284 Return value is 0 for PostToF0902.



Anyone else encounter a similar issue? Any info or leads would be
appreciated..

Regards,
John



-------------------------------------
OneWorld B733.3 (XE)
SP 19.1_B1, Update 6
Win2k Server SP3
SQL 2000, SP2
Metaframe XPa v1.0/SP3
-------------------------------------

Hi Jgersic93,

I have experienced unexpected behaviour of security in OW. You always have to try out alternates. Perhaps you may want to secure the F0011 (batch table) on the userID. This may prevent users from trying to post batch numbers which do not belong to them.

Hope this help you solve your problem

How is row security set up? Are you using *ALL to lock down all of the tables or you locking down each individual table?

If the users don't need access to other company's data anywhere else in OW, you can secure it by MCU (Cost Center/Business Unit) across all tables.

JDE was able to duplicate my issue with row security (F0902 with the
R09801) and has
created a sar for it..
Does anyone know for sure if (most) business functions check row security?
I think that ER rules do (update table, etc), but business functions do not
check security..I am going to perform some tests when time permits to see if
this is true.

-John


-------------------------------------
OneWorld B733.3 (XE)
SP 19.1_B1, Update 6
Win2k Server SP3
SQL 2000, SP2
Metaframe XPa v1.0/SP3
-------------------------------------




Xe, Update2, SP16
SQL2k, Win2k
Metaframe 1.8a

Re: RE: Row Security

What is the SAR number?

RE: RE: Row Security

The SAR # for the row security issue is: 6740245.

-John

-------------------------------------
OneWorld B733.3 (XE)
SP 19.1_B1, Update 6
Win2k Server SP3
SQL 2000, SP2
Metaframe XPa v1.0/SP3
-------------------------------------




Xe, Update2, SP16
SQL2k, Win2k
Metaframe 1.8a

Re: RE: Row Security

John,

I was not able to have a test on F0902 CO row security ... but for my understanding:

* R09801 is able to insert / update F0902 through B0000122 BF "F0902 Update Account Balances"

* B0000122 is using a JDE API "JDB_UpdateCurrent" that is going to update a F0902 record selected by JDB_FetchKeyedForUpdate API

* I'm really worried if such JDE APIs are able to bypass security setup that should be managed by the appropriate software layer.


Moreover, I'm experiencing a different row security issue on F0911 - CO field:

* some automatic entries (see AE transaction) do have "00000" in KCO field ... thus it's possible to obtain the same F0911 unique key at posting time (!). I mean: with this kind of security setup, B000009 "Get Next JE Line Number" is sometimes not able to retrieve the existing AE (on a different / secured Company). As a consequence this standard BF is going to return a JELN (JE Line Number) that will cause a duplicate key (DB error) in certain circumstances (see 2 receipts on 2 different companies but with the same document number and GL date).

My questions are:
* did someone experience the same issue ?
* how it's possible to manage row security on GLCO field while KCO field could be "00000" ?
* why JDEdwards decided to use "00000" in KCO field for several AE transactions type ?

Thanks,

Carlo

------------------------------
OneWorld B733.3 (XE)
SP 20, Update 5

Re: RE: RE: Row Security

I've attached my name to the SAR which will give it more weight.

Re: RE: RE: Row Security

Please have a look also at SAR "3376361 Row Security - Duplicate Key System09" ... where you can read: "Individuals who submit batches to post must not have any row security defined."

It seems that GL posting procedure is not designed in order to run with secured userId ... thus it should run in the night scheduler with a special userId without security row constraints.

Regards,

Carlo