Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Field level security

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Field level security

    On Wednesday, October 14, 1998, 12:13 PM, Jim Adair wrote: To say that I am disappointed with IBM's version of field level security would be an understatement. I am in an ILE environment running V4R2. I do not use SQL nor do I use CL. I do however use RPG IV programs and API's. Having said that, I would like to know if anyone has found an acceptable way to set up field level security within an RPG program. I would like to block access to a field before a screen is displayed if at all possible. Jim, The update aspect can be handled with triggers. That would not be very hard. You could prevent access to fields by creating your own I/O procedures. Only return data that the user is authorized to. This way you have total control. We do not have your security requiremnts, but we do use I/O procedures in all of our applications. There are quite a few advantages. This would not have to be very complicated to accomplish what you need especially since you are already in an ILE environment. David Morris

  • #2
    Field level security

    It is my understanding, that REAL field level security will be available V4R4. My technique at V3R2 is to use indicators based on group profiles. David Abramowitz

    Comment


    • #3
      Field level security

      The closest to an API that I can think of is using List Users Authorized to an Object (QSYLUSRA) which will tell you, in the Header section, if field authorities exist for the file. Then one could use DSPOBJAUT to an outfile specifying *FIELD to see the various field authorities.

      Comment

      Working...
      X