Prev
Next
Forums Infor / Lawson Platforms S3 Security

getDBField question

 2 Replies
 0 Subscribed to this topic
 15 Subscribed to this forum
Sort:
Author
Messages
Al
Basic Member
Posts: 17
Basic Member
4/1/2011 4:44 PM

    We have some user fields in the Billing and AP modules where staff is entering numeric client ID’s for one of our divisions. Problem is we have run into a data quality issue where users are entering invalid ID’s. I want security to allow form change action only if the user field is blank or if the value in the user field matches a valid client ID.

     

    The data entered into those user fields should match a valid client ID in a custom Lawson table we have created called SCCLIENTS2. The primary key on that custom table is an integer field called SCMID and the user fields are alphanumeric. I want to allow form change if the user field value matches one of the SCMID values. I am getting security violations and wonder if it has something to do with the integer in the custom table comparing to the alpha user field. I have tried trim(), lztrim() and strToNum() with no success. Any ideas?

     

    Here’s the rule I currently have written on form BL20.4:

     

    if(form.OIL_USER_FLD3==''||(strToNum(form.OIL_USER_FLD3)==trim(getDBField('SCCLIENTS2','SCMID',form.OIL_USER_FLD3))

       'ALL_ACCESS,'

    else

       'NO_ACCESS,'

    Al
    Dave Amen
    Veteran Member
    Posts: 75
    Veteran Member
    4/3/2011 4:37 PM
      Al,
      A suggestion for debugging this type of thing - take it apart and test each piece by itself.

      First (you may have already done this), put in ...FLDe=='' by itself and make sure that works.

      Then set that aside and focus on the rest.
      Hard-code the value on one side, such as:
      strToNum(form.OIL_USER_FLD3)==12345
      If that doesn't work, go back another step:
      form.OIL_USER_FLD3=='12345'
      Or also
      trim(form.OIL_USER_FLD3=='12345'

      Once that's working, swap your focus and hard-code the left side while adjusting the right side. Once you know exactly what each side is returning then it's much easier to match the two sides appropriately (with whatever combination of trims and ToNums you have found to work).

      One thing that helps a lot is to turn on logging and watch the LASE logs while you're testing. Those will show you definitively whether your latest rule change is in place (you probably know about cache refreshing every which way and still not really knowing if your rule is in effect yet).

      If you're not familiar with using the logs, that takes a bit more explanation, which I'd be glad to go through with you over the phone if you'd like.

      Let us know how it works out!

      Best regards,
      Dave
      (303) 773-3535
      Al
      Basic Member
      Posts: 17
      Basic Member
      4/4/2011 11:45 AM
        Thanks for the suggestion Dave. I did use the lase.logs and found an issue where it mentioned the custom table does not exist in the data source. I need to do some checking on that and will try what you suggested as well.
        Al