LBI - Schedule a report with a parameter

In the LBI schedule you can put in a parameter value. The user themselves can not, but you can.

The other option you might look into is having the report pull the Lawson user ID for the person running the report and use that as criteria in your report.

The report needs to get distributed to over 1000 managers, which is why we went down the bursting route, but issues are cropping up with scheduling this report with multiple subreports (The subreports seem to be the culprit). So my hope was that we could schedule this report to run, but when the manager opened the scheduled report, a parameter would pop up asking for their User ID and it would give them just the records tied to their User ID.

Is that possible?

There is an LBI param called @CurrentUser. Create an LBI param, set it to hidden and do not prompt user, then plug in @CurrentUser as the default value. It will pull in the authenticated user's ID.

If you are trying to display the report from a link on a dashboard, the current user logged in will be stored in a variable called LAWSONRS_CurrentUser so you could just build that into your report....
I've never tried scheduling this report though, as that variable will not be filled in when the schedule runs....

@Carl: We must have been working on our responses at the very same time... I try not to respond with the exact same stuff as found earlier.... ha.

Carl, your solution:

"There is an LBI param called @CurrentUser. Create an LBI param, set it to hidden and do not prompt user, then plug in @CurrentUser as the default value. It will pull in the authenticated user's ID."

seems to be working! I was able to scheduled this report with this parameter built in. I had a manager run the scheduled repert and it returned just the records that tied to their User ID!

So, does this mean that this is an alternative way to get a single report to managers (or to anyone where the User ID is in the LBI parameter) in lieu of bursting? If so, this is great information.

I am wondering if you can explain how this is working (e.g. LBI report goes out and looks at the end-users login and matches that up against the User ID in the Crystal report) and how this may operate differently than if we were to schedule a report ot burst (what would be the pros and cons of doing one or the other)?

Thank you!

Sorry, as I read this again, I don't think it fits your original question. This param grabs the user ID that is currently logged into LBI. So it works great for reports that are added to an LBI dashboard, where the user can log into LBI and click the report to run it. This would not work for scheduling or bursting a report, since it requires the user to be logged in. If you want the data e-mailed to each user, without having them log into Lawson, I believe you would have to use LBI bursting (structure and elements).

Maybe you could publish the report to a dashboard temporarily, until the bursting issues are resolved? This would mean the report being generated each time, which you stated earlier you did not want. I don't think an instance of the report would work, since you need to filter by the User ID.

Hi Carl,

Actually, adding this to a dashboard would be something we would likley do with this. I'm not sure if you saw my prior response, but, I did schedule this report and i was able to get it to generate the records I expected for each individual manager who opened it. I even transferred myself into a manager position and was able to get the results I expected. So this would seem like it's a great fit for what I need.

I'm just curious if there are security implications with going this route? No one as of yet has used LBI parameters in our reports, so I want to make sure we've vetted all the potential concerns with this type of set up.

Tania

Tania;

The only problem with the hidden parameter trick, and using the @CurrentUser value is that the parameter does NOT stay hidden on a refresh. We use this method to plug in the @CurrentUser into the SQL for the report. The report returns only those AU's for the manager based on Attributes for each Accounting Unit. It works the first time fine, but if the user decides to select the refresh button, the parameter displays again where someone can use another managers ID. Wish I could fine a way around this.

To get around that issue, you can edit the Crystal Reports param: Add a value X, Set Prompt = Do not show, set default value = X, Allow custom values = False. Then if the manager refreshes, all they can select is "X", which returns no records.

But the default value is already set to @CurrentUser. Are you setting the "Use Crystal Reports Parameter Page" on, in LBI?

I don't have access to the system, but yes I believe we did have to select Use Crystal Reports Parameter Page. Does it still use @CurrentUser, and not allow the user to change it?

I set the Promt to Do Not Show and the default parameter to @CurrentUser. When the report runs, the other two Params (Year, Period) are visible. The user enters those and the report runs using all three. The @CurrentUser is used in the SQL Command file to retrive records (Accounting Units) assigned to the current log-in (user). But if the user select the refresh button the parameter shows up as blank and they can type into it. I can go back and try setting the "Use Crystal Reports Parameter page" and the Not allow custom values as you mentioned. But where would the default @CurrentUser get picked up?