Lawson Portal - Manager Self Service

Sort:
You are not authorized to post a reply.
Author
Messages
Kevin Stuck
New Member
Posts: 3
New Member
    I am kind of new to Lawson, however, we have Employee Self Service up and running and I am very close with Manager Self Service.  Currently in MSS I can see Absence Plan Setup and if the manager drills down on this he can see every employees absence plan but I don't want this.  If I modify the rules so he can't see it, it also takes away the ability for the manager to see his/her Leave Balances under ESS.  I have it narrowed down to three tables:TAPLAN, PGEMPLOYEE, and PERSGROUP.  Ultimately what I would like is that they could see their Leave Balances under ESS and only their Absence Plan under MSS, or turn off the Absence Plan all together.  It has been driving me crazy for a while because I can't get it.  I'm guessing it may take a conditional rule, but I can't figure it out.  Anyone out there have any ideas for me or can help me?
    Jimmy Chiu
    Veteran Member
    Posts: 641
    Veteran Member
      I would add this to restrict the data to only the user's employee id (which is your prodline_employee identity in LSA).

      if(user.getEmployeeId()==lztrim(table.TAPLAN))
      'ALL_ACCESS'
      else
      'NO_ACCESS'

      do that for table.TAPLAN, table.PGEMPLOYEE, and table.PERSGROUP
      BeckyB
      Basic Member
      Posts: 7
      Basic Member
        Dear Mr. Chiu, I found your response to this post and when implemting this conditional rule, the expression builder throws the following message:

        1. rule evaluation: table.TAPLAN is not in the scope
        2. Also, when the table category object "table.TAPLAN" is not available for use in this rule
        3. I have reviewed the possibilities, but the employee nor table is available for use in this rule.
        4. Could you expand on your thought here, please
        Greg Moeller
        Veteran Member
        Posts: 1498
        Veteran Member
          When you get the error 'not in scope' you need to use the getDBField(tableName,fieldName,key...) utility.
          I wish I had an example of what you are trying to do, but perhaps one that is used to restrict fields by Process-Level will suffice?
          trim(getDBField('EMPLOYEE','PROCESS-LEVEL',table.COMPANY,table.EMPLOYEE))=='900'
          This will grab the PROCESS-LEVEL field from the EMPLOYEE table and if it is equal to '900' will evaluate to true.

          Hope this helps you.
          BeckyB
          Basic Member
          Posts: 7
          Basic Member
            Thank you Greg,

            I am attempting to lock down the drill down for "Absence Plan Setup" which allows the HR11.1 login to access all employees under the plan(i.e., ESL). I have been successful in locking down all other drill downs with the exception of this one. I believe the LP table TAEMPSERV or TAENROLL may be the issue. This class is setup for HR employees acting as proxies for multiple physician sites. Also, the class is locked down to specific Company/Process-Level/Department relationships in an ELEMENT GROUP.
            On the other hand, the ESS class that I developed is locked to the employee logging in, this is working.
            Do you have any experience locking down the Absence Plan Setup drill down for logins other than ESS?
            Jimmy Chiu
            Veteran Member
            Posts: 641
            Veteran Member
              There was a mistake from my original post back in 2011. To limit the drill down Absence Plan listing, I believe the table is TAEEMASTER. Use the following condition rules would restrict to logon employee_id.

              ::: TAEEMASTER table:::

              if(user.getEmployeeId()==lztrim(table.EMPLOYEE))
              'ALL_ACCESS,'
              else
              'NO_ACCESS,'

              So if the logon employee_id doesn't match the record in the table, no access... in this case, drill down in HR11 > absence plan >
              BeckyB
              Basic Member
              Posts: 7
              Basic Member
                Role Base Security HR11.1 drill down Absence Plan Setup

                I am developing an HR11.1 inquiry class for a Physician Services Group. Security rules are working for drill down for ELEMENT GROUP Company/Process Level/Department relationship with the exception of "Absence Plan Setup". When drilling down on Absence Plan Setup, we can see all company employees. Is it possible to secure drill down at this level? I have reviewed all tables for the HR11.1 and written appropriate rules for each and still have not been successful securing this drill down. The rule that you have shared is an EMSS rule and does work as you have indicated in your last post, but the security class that I am developing in an HR11.1 inquiry only class and is not related to EMSS.
                Jimmy Chiu
                Veteran Member
                Posts: 641
                Veteran Member
                  I see what you are getting at. I tried a few tables and I dont think they have a security check routine built-in for "Absence Plan Setup".
                  BeckyB
                  Basic Member
                  Posts: 7
                  Basic Member
                    Hi Jimmy,

                    I wanted you to have this, it locks down Absence Plan Setup to the Element Group based on the Company/Process-Level/Department relationship. UAT revealed that PAEMPLOYEE items can be drilled down on for an employee not in the above relationship. I am working on a new rule to lock down the benefits drill downs. This is some tough stuff. Wanted you to have the rule below.....

                    isElementGrpAccessible('PROCDEPT','','LP',table.COMPANY,table.HM_PROC_LEVEL,getDBField('EMPLOYEE','DEPARTMENT',table.COMPANY,table.EMPLOYEE))
                    BeckyB
                    Basic Member
                    Posts: 7
                    Basic Member
                      Hi Jimmy,

                      I did figure out the issue with the benefits drill downs. I have attached the rule on the PAEMPLOYEE table. This rule worked famously! I am playing around with the custom ELEMENT GROUP that I created to attempt making the calls there, but for now, it works just like this.

                      trim(getDBField('EMPLOYEE','PROCESS-LEVEL',table.COMPANY,table.EMPLOYEE))== '19' && trim(getDBField('EMPLOYEE','DEPARTMENT',table.COMPANY,table.EMPLOYEE))== '6081'
                      BeckyB
                      Basic Member
                      Posts: 7
                      Basic Member
                        Also, notice the field name for the call to the EMPLOYEE table, PROCESS-LEVEL uses a - not an _.
                        Jimmy Chiu
                        Veteran Member
                        Posts: 641
                        Veteran Member
                          Nice one! Thanks for the info.
                          BeckyB
                          Basic Member
                          Posts: 7
                          Basic Member
                            I completed the class with CO/PL/DEPT relationship a few weeks ago, I wanted you to have the final rule. Thanks for all of your help.

                            PAEMPLOYEE table: (user.attributeContains('CompanyControl',lztrim(table.COMPANY))&&user.attributeContains('ProcessLevelControl',trim(getDBField('EMPLOYEE','PROCESS-LEVEL',table.COMPANY,table.EMPLOYEE)))&&SystemCode=='HR')&& (user.attributeContains('CompanyControl',lztrim(table.COMPANY))&&user.attributeContains('AccountingUnitControl',trim(getDBField('EMPLOYEE','DEPARTMENT',table.COMPANY,table.EMPLOYEE)))&&SystemCode=='HR')
                            You are not authorized to post a reply.