Re: field level security - (Was Use of a trigger...? ....) -- MIDRANGE-L

But booth, on a *BEFORE you cannot change the buffer to hide certain
fields.  You cannot change the buffer to reflect a computed field.  You
could always modify the trigger that if Allah/Budda/God/Yourdeityofchoice
is the user then don't mess with the buffer.  If you could do this - then
you could display field level security exactly as you wanted - with all the
flexibility that you wanted.

The only use of a *READ *AFTER trigger is to say - "Joe blow has read the
record xyz."  I can't think of any other reason for a read after - can you?


Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    "Booth Martin"
                    <booth@MartinVT.com       To:     <midrange-l@midrange.com>
                    >                         cc:
                    Sent by:                  Fax to:
                    midrange-l-admin@mi       Subject:     Re: field level 
security - (Was Use of a trigger...? ....)
                    drange.com


                    01/25/2002 01:18 PM
                    Please respond to
                    midrange-l






The idea of a *READ *BEFORE has been bugging me.  What good is a
read-before?  I have to see the record to know if it has what I want in it.
It has to be read after.

--------------------------------------------
Booth Martin
MartinB@Goddard.edu
802-454-8315 x235
--------------------------------------------
-------Original Message-------

From: midrange-l@midrange.com
Date: Friday, January 25, 2002 12:43:26 PM
To: midrange-l@midrange.com
Subject: Re: field level security - (Was Use of a trigger...? ....)

Crash on the trigger idea. IBM must have been reefing on a bad one. The
*read is only *after. Must be for audit purposes only and not security and
other cool stuff. You cannot change the data buffer or you get a nasty
CPF501B.

What a stupid limitation!

Not only does this thwart security, but let's say you have this erp package
which stores price in the file. Well, rather than change all of the erp
programs to use an interactive pricing mod you could just put a read
trigger on the file to calculate price on the fly.

I will say the triggers are called even when you do DSPPFM - as well they
should be. Would anyone out there have a problem if you could put a
trigger on your data to do either; a-security or b-calculated fields and
not see the actual data that is in the file? I wouldn't.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



rob@dekko.com
Sent by: To: midrange-l@midrange.com
midrange-l-admin@mi cc:
drange.com Fax to:
Subject: Re: field level security - (Was Use of a trigger...? ....)

01/25/2002 11:59 AM
Please respond to
midrange-l







As others have stated... Judging by the SQL grant and revoke statements it
looks like you can only mess with update and references. And it's not an
Op's Nav limitation. (References is a referential integrity thing and
AS/400 developers don't care about that <but they should>.)

Maybe at lunch time I'll play with the trigger method of replacing the
field with *loval.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



"Richard B Baird"
<rbaird@esourceconsu To:
midrange-l@midrange.com
lting.com> cc:
Sent by: Fax to:
midrange-l-admin@mid Subject: Re: field level
security - (Was Use of a trigger...? ....)
range.com


01/25/2002 11:13 AM
Please respond to
midrange-l







Rob,

Really!? Did you try query? SQL?

Is there another way to implement FLS other than opsnav? I've not had a
lot of experience with opsnav. can you limit read authority first, before
the box is greyed out?

If this limitation is "working as designed", what's the point? it seems to
me, the whole implementation is flawed. what good does it do you if you
can't secure read authority? Maybe this is why I've never seen or heard of
FLS being used. too many limitations and quirks.

Has anyone on the list used field level security?
what are your experiences?

rick

--- original message ---
<snip>

Then I went into Operations Navigator and changed the security on FLD3 to
exclude the public. When it came up I right clicked on the database and
selected permissions, clicked on details, clicked on columns. There are
the following columns and there status:
Management - off
Alter - off - greyed out
Reference - off
Read - on - greyed out!
Add - on - greyed out!
Update - on
On FLD3 I turned update off.
Signed on as a peon. They can see FLD3. If they do UPDDTA then they can
see FLD3, they can change it but if they try to enter and save they get a
few messages, one of them being Not authorized to field FLD3 of file
RICHARD. They can change other fields.

How do I secure read when the SOB is greyed out?

_______________________________________________
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.