restrict users to their own jobs, print managers, etc. in LS Security

Has anyone created a rule or otherwise been successful in restricting users to their own jobs, print managers, etc.? I think groups will work, but we like to leave the groups open so that any user can send a report to any other user (assuming the user has access to view the report). I think that means I need a rule, but I'm not sure where to put it or where to start building it. I would be grateful if anyone has any advice or recommendations, or if anyone would be willing to share a rule you have written to accomplish that.

0911060553270289.pdf

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

We created another security class under GEN profile that basically said this for the UserName Element

if(UserName==user.getHostServiceId())
'ALL_ACCESS'
else
'NO_ACCESS'

Not sure if that will work for you or not, but one option

Our setup is very similar to Gary's. We have a security class under the GEN profile named BatchUserRestricted with the following setup:

Online:
UN (Grant all access)

Files:
JOB (Grant all access)
JOBSTEP (Grant all access)
QUEUEDJOB (Unconditional access for Action I,A,M) [This rule is setup so users can't delete their queued jobs, which could potentially cause system issues if an update job was deleted while it was running.]

Data Sources:
GEN (Grant all access)

Elements:
UserName ('If Then Else' Conditional Rule shown below.)

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

[Updated on 6/8/2015 1:16 PM]

0911060553270289.pdf

We have various Queues, so we have created separate Security Classess for each, i.e. FNBatch, MMBatch, PRBatch etc. based on 'Batch' all relating to their own corresponding Job Queues

We also use a rule on the UserName Element in Gen
if(UserName==user.getUserName())
'All_Access,'
else
'NoAccess,'
but then we set up a separate role based on a group for the people who want to share their Print Manager files, fortunately this is a small group of HR Administrators.
The rule for thier UserName element is
if(isMemberOf('HR Reports',UserName))

'All_Access,'
else
'NoAccess,'

Attachment_4326.zip

Thank you all, I have been playing with this and have one follow up question. The basic concept works to restrict users to their own print manager and jobs, but it is slightly too restrictive - users can no longer send a report from their print manager to another user. I think NYount addressed this by creating and using groups, but is there a way to set this up so that any user can forward their reports to any other user, while being restricted to view only their own jobs and print manager?

I raised this with Lawson previously, and was told that this function was no longer required in Portal.
Lawson felt it was simpler to create a .pdf - via the Options, and then send the file via Email.
Our users have accepted this now (eventually) as the solution, although originally they did not like having the additional steps!

Thanks Peter, I'm a little surprised Lawson doesn't have an answer for this. I tried changing my rule to this:
if(user.getUserName()==UserName)
'ALL_ACCESS,'
else
'INQUIRE_ACCESS,'

That solves this specific issue, but now the users can see everyone else's print manager and can even go to their job screens and submit other people's jobs. Surely someone out there has figured out a way to restrict users to their own print manager and jobs while still allowing the basic functionality of sending a report to another user...???
I understand the workaround of sending a pdf via email, but many of our reports are too large to send via email, and a few are even too large for pdf to handle.

Somewhat before my time here, the Security Consultant could not get your issue, with regard to everyone being able to see evryone else's print working successfully.
However, they did create a Role which everyone has (apart from those who need to see other User's Print Manager (Role - PrintMgrUserOnly).
Security Class attached:
ELM UserName
if (user.getUserName()==UserName)
'ALL ACCESS'
else
'NO ACCESS'

They were unable to get the opposite working, so that's why everyone has have this Role, apart from the few.

The needs of the few clearly outweigh the needs of the many!

Since we used Distribution Groups in LAUA to route reports so key coworkers could view them in their Print Mgr view we had a need to continue with an approach under LSA that provided a similar result. But, we also needed this secure since there were sensitive reports being routed. Here's what we did:
o Everybody gets the BatchRole which restricts it down to the individual user.
o Then, we setup 3 groups (BatchHR, BatchFin and BatchSCM) which builds on BatchRole and the 4th group will be the default – no group assignment and they only see their own output.
o We paid a consultant from Kinsey to write a User group rule since they had done this at several other locations.
o Each coworker’s LSA record then needs an adjustment to specify what group they get.
o We built the User Groups (HR-USER, SC-USER, GL-USER and MSCM) and assigned a test set of coworkers to each. The user group is simply collections of users. Users can/will belong to multiple groups. For example every user of Lawson will be in the ALL group without exception. These do not grant any access, but are used as part of security.
o In the Role/Security Class combinations: Rules can/will be written to grant access to different user groups based on the roles given to a user. For example every user will get the Batch role to see only their jobs, print files, and print files distributed to them. The role BatchPlusHRS is what gives access to see other users jobs and print files, but only the users that belong to the HR-USER group.

Bear in mind that whenever you allocate individuals to a Distribution Group, then each User will ALSO need at least Inquiry access to the corresponding Program (i.e. PR141 Inquiry, PR295 Inquiry etc. or whatever).

We did something similar with the User groups and we created a security class in the GEN profile with only a UserName element group with this rule:
if(isMemberOf('HR Reports',UserName))
'ALL ACCESS,'
else
'NO ACCESS,'
this security class is added to roles used by the members of the group who want to share print manager reports.
Another option is to create a distribution group that is attached to the output files before running a report but we have been having trouble with distribution groups in Lawson Version 10. the jobs copied from version 9 are working but we haven't been able to add a distribution group to a new job created in Version 10. We have a ticket open with Infor but no solution yet.

Another option is to use structures in Lawson Security instead of groups. With structures, it easy to set up hierarchies and ad-hoc groupings. I was able to restrict user job/print manager access on work team boundaries with a single GEN Batch security class and one structure.

Also, Lawson Security provides a number of rule functions that can be used to restrict user access based on reporting relationships or data assignment (department, etc.). This is always preferable as it eliminates group or structure maintenance.

Thanks Dan, that makes sense. And I like eliminating group/structure maintenance as much as possible. I don't think it solves the issue of users being able to modify other people's jobs though. That is the biggest issue I see right now.

One more question on this for you all to ponder on. Hopefully I'm just missing something easy on this one. With what I have learned this week, I partnered with another user to do some testing...I had User A go out and change parameters on one of MY jobs, then run MY job, then distribute the report. Everything that I can find shows that I ran the job - I am listed as the job owner in the print manager, it is showing up in my completed jobs, etc. Nothing that I can find in the job log shows User A as being the one to change the parameters or run the job or distribute the job.
That seems like a huge risk to me to let any of our users have the ability to do that...too much of a chance for bad stuff. But if I lock it down, then users can't even do something as simple sending one of their own print manager reports to another user. I'm just surprised that I haven't heard about this yet, and I'm dumbfounded that Lawson seemingly doesn't have an answer for this.

Jason - the behavior you describe is so standard that everybody takes it for granted. It's "just the way it is". It hasn't changed since I started using Lawson back in 2000, Lawson 7. All you can do is either to have the other user create the job for themself, or, send them the output.

Thank you MiloTsukroff, but this concept worked "correctly" in the LAUA world, but with the LS Security that we rolled out this year, it appears that we are stuck between 2 terrible alternatives - either not being able to utilize a core function of Lawson (sending something from my print manager to your print manager), or having to live with not being able to restrict users from changing/running jobs for other users in their own group. Maybe I'm wrong about LAUA, but I thought we could lock it down appropriately while still allowing users to send items from their print manager to other users in their group.

Sorry I didn't understand. Where I am we're still mostly in LAUA world. We use Portal only and specifically to create & email PDF's. So we haven't run into the restriction that you're banging into, we're doing it the 'recommended' way.

Bummer.

You've set up the groups so the appropriate users in the groups can see each other's jobs. What happens if you take things the step further and restrict queuedjobs to be inquiry only if user name does not equal job user name? Since portal ended most of the functionality you speak of for us, I have very few users who can see other user jobs so have not tried my suggestion out. It does look like there might be a patch pending KB 1530272

As far as I know you could never send a print job to another user through Portal or through LID, which you can still do today. If the jobs always have to go to other users, you can add a Dist Group to the report so it is always sent to the other users when it is run.

As I mentioned earlier in this Chain, I believe jreese to be correct - you have never been able to send a Print Job in your Print Mgr to another User via Portal - only LID.
The functionality has never been available.
As per an earlier entry the Security Class/Rule I sent does not enable Users to change other User's Jobs, or see their Print Manager output.

I'm sure you are right, we never used Portal...we went straight from LID to Smart Office last year, and we just finished implementing LS Security. The rule you shared does in fact restrict users the way we want, but it also restricts them from sending something from print manager to another user's print manager.

2588_2926_BI-245_ApplicationStudio_Using_Lookups.mp4

We only have a handful of users that even care about sending reports to another user or person. We created shares on those user's print folders, so the users can access all their print files directly, and can save them off to another location or send them via email, as needed. This has been in place for as long as Lawson has been implemented here.

Ah-hah! Great idea! If the Lawson print folders are on a UNIX server, then Samba is the way to share them into Windows.

Quick Links

Popular Tags