Securing User Jobs using LS Security

Sort:
You are not authorized to post a reply.
Author
Messages
Roger French
Veteran Member
Posts: 545
Veteran Member
    Has anyone successfully put in a security rule or process to allow a user to see his/her own jobs ONLY (and no one else's) in Job Scheduler? This is using LS Security, NOT LAUA.

    This is for v 10.0.x and also v9.0.1

    I've put in the rule in the UserName element in the Batch class which is part of the GEN security profile:

    if(UserName==user.getHostServiceId()||isMemberOf('BatchUsers',UserName))
       'ALL_ACCESS,'
    else
       'NO_ACCESS,'


    CheckLS=Yes for all users; security is turned ON. Users are all part of the user group definition 'ALL' (using usergrpdef - this is not an RM group). Remember this is using LS Security, NOT LAUA.

    Example: I've given the 'lawson' user membership as part of 'BatchUsers' RM group; also all of the security roles have been granted (Batch, SuperAdmin, etc.)

    The end result is that when 'lawson' logs in to Portal, NONE of the 'lawson' jobs are visiable; also on the user name drop down in job scheduler, NONE of the users appear, not even 'lawson', which really, 'lawson' should appear.

    This security rule is the security rule put out in a Critical Notification a few years ago, but I don't know if it actually worked.

    Thank you for your time,
    Roger
    Kwane McNeal
    Veteran Member
    Posts: 479
    Veteran Member
      Roger,
      I have a number of times. Call and I'll explain exactly how this works.

      Kwane
      505-433-7744
      Al
      Basic Member
      Posts: 17
      Basic Member
        This rule on the UserName element has always worked for me. We use LS security.

        if(user.getUserName()==UserName)
        'ALL_ACCESS,'
        else
        'NO_ACCESS,'

        Al Ceplecha
        Scott County
        Al
        Roger French
        Veteran Member
        Posts: 545
        Veteran Member
          Thanks Al, that worked perfectly for v9 and v10 systems. 
          I knew it was some variation of the rule I had.
          -Roger
          Kwane McNeal
          Veteran Member
          Posts: 479
          Veteran Member
            Roger, I looked at your original rule, and the only thing I could see *potentially* tricky is where you have the parenthesis.

            If I recall correctly, the || is higher on the order of precedence than ==, so I think your rule would have worked if you had it this way:

            if((UserName==user.getHostServiceId())||(isMemberOf('BatchUsers',UserName)))

            Kwane
            You are not authorized to post a reply.