Prev
Next
Forums S3 Security

Issue with Year to Date links with Employee Self-Service.

Sort:
You are not authorized to post a reply.
Author
Messages
alincoln
Basic Member
Posts: 12
Basic Member
2/24/2009 9:36 PM

    We're running into an issue with our security around the Year to Date pages on Employee Self Service.

    Reading the ESS/MSS Lawson Technical Documentation I see that the following securable objects should be assigned to allow access:

    PR50.1, PAYMASTR, PRTIME, PAYDEDUCTN, QUARTWAGE, QUARTDED, CUCODES, and PRSYSTEM.

    We've assigned all of these objects but users are still not able to access their Year to Date info.  Our other ESS links that we've deployed seem to be working fine (Pay Checks, Pay Rate History for example).  We're also not getting any OBJECT_SECURED error messages on the portal, it simply says that no information exists.

    Our functional resources think that this is a security issue.  Looking at the various LASE logs (after turning on auditing for the user in question), I cannot find any resources that are failing a security check.

    I was wondering what other users might be assigning to their ESS security class(es) to allow access to Year to Date information in case I'm missing something obvious.

    Thanks in advance!

    John Henley
    Senior Member
    Posts: 3348
    Senior Member
    2/25/2009 1:18 PM
      Are you using LAUA security or Lawson 9 security?

      Try adding tables EMPLOYEE, PAYSUMGRP, DEDCODE.
      Thanks for using the LawsonGuru.com forums!
      John
      alincoln
      Basic Member
      Posts: 12
      Basic Member
      2/25/2009 9:21 PM
        We're on LSF9 Security. And we had those tables already assigned to the ESS security class in question; didn't make a difference.

        I did fix the issue though but I'll be damned if I can figure out why.

        Through a process of elimination, I eventually added the securable type table to our ESS security class in an effort to figure out where exactly my issue lie. Sure enough, after doing that one thing, it worked. So I knew my problem was a table somewhere.

        I then went down the list of TABLES assigned to Year to Date in the Technical Document and began removing their conditional access one by one. Eventually I got to QUARTWAGE. Once I removed the conditional access on that table and flipped it to Unconditional for "I", it worked. I applied the exact same conditional rule right back to the table, and it still continued to work (I copied and pasted the rule out and then back in, so no chance of typos).

        For the curious, here's the rule:

        [
        if(isElementGrpAccessible('Coemp','','',lztrim(table.COMPANY),lztrim(table.EMPLOYEE)))
        'I,'
        else
        'NO_ACCESS,'
        ]

        So this module of ESS is now working ok, but my net change in the system was zero. Not sure what caused it or what fixed it, but I can't argue with the result.

        I sure wish there was a Lawson report that could be run that would do authorization checks in the system to help determine on exactly which securable object a security issue lay. I do have auditing turned on in the system, and I'm adding the user I’m doing the testing against in the auditing list, but the garbage I get back from the LASE logs is so convoluted I can tell exactly where the problem is. If anyone is familiar with SAP, Lawson direly needs an SU53 type transaction to make security troubleshooting manageable.

        Thanks for your help!
        You are not authorized to post a reply.