Hide parameter for some users

I'm trying to decide whether I can use sql reports for my application, and
the main problem I've run into thus far is that my available parameters need
to change based on the user who is running the report. For instance,
low-level users should only be able to see data about themselves, whereas
managers should be able to select from a drop-down list of all users. Is
there any way to set the user prompt/visibility for a parameter based on the
role of the person running the report?The easiest way I can think of to manage this is to have two versions of the
same report. With the regular version, pass =User!UserID into the query
parameter. In the manager's version, populate the same parameter from a
drop-down list. Then set different permissions when you deploy the reports.
If you need to do it in a single report, you might be able to write some
custom code to pass in flags to the query and work out the difference
between managers and employees in your data source query.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"jgephart" <jgephart@.discussions.microsoft.com> wrote in message
news:36979870-6D83-4C49-B1E6-88D8CBC51678@.microsoft.com...
> I'm trying to decide whether I can use sql reports for my application, and
> the main problem I've run into thus far is that my available parameters
> need
> to change based on the user who is running the report. For instance,
> low-level users should only be able to see data about themselves, whereas
> managers should be able to select from a drop-down list of all users. Is
> there any way to set the user prompt/visibility for a parameter based on
> the
> role of the person running the report?|||Thanks, Jeff. This will affect a whole series of reports, so I don't really
want to maintain separate versions. I think I'm going to be able to go with
passing in User!UserID to the query that builds the drop-down list of users.
I can't hide the drop-down list, but at least I can make sure it's only
populated with a single user if that user doesn't have permission to see
other people's data.
"Jeff A. Stucker" wrote:
> The easiest way I can think of to manage this is to have two versions of the
> same report. With the regular version, pass =User!UserID into the query
> parameter. In the manager's version, populate the same parameter from a
> drop-down list. Then set different permissions when you deploy the reports.
> If you need to do it in a single report, you might be able to write some
> custom code to pass in flags to the query and work out the difference
> between managers and employees in your data source query.
> --
> Cheers,
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---|||To protect it on the back side (from someone simply altering the URL to look
at someone else's data) you could always create a permissions table that
contains all of the usernames that each user is allowed to look at, and have
that table always be in the source query join, with User!UserID passed into
the query. We're doing a variation on this (a join to a parameterized UDF)
for our data security solution.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"jgephart" <jgephart@.discussions.microsoft.com> wrote in message
news:F5C7BDD7-4F0D-488C-80CB-7F81201B08A4@.microsoft.com...
> Thanks, Jeff. This will affect a whole series of reports, so I don't
> really
> want to maintain separate versions. I think I'm going to be able to go
> with
> passing in User!UserID to the query that builds the drop-down list of
> users.
> I can't hide the drop-down list, but at least I can make sure it's only
> populated with a single user if that user doesn't have permission to see
> other people's data.
>
> "Jeff A. Stucker" wrote:
>> The easiest way I can think of to manage this is to have two versions of
>> the
>> same report. With the regular version, pass =User!UserID into the query
>> parameter. In the manager's version, populate the same parameter from a
>> drop-down list. Then set different permissions when you deploy the
>> reports.
>> If you need to do it in a single report, you might be able to write some
>> custom code to pass in flags to the query and work out the difference
>> between managers and employees in your data source query.
>> --
>> Cheers,
>> '(' Jeff A. Stucker
>> \
>> Business Intelligence
>> www.criadvantage.com
>> ---|||You could use linked reports instead, possibly in conjunction with the
My Reports feature. Linked reports are effectively shortcuts to a
report.
But, the nice touch is that you can set the parameters to behave a bit
differently, for instance there is a prompt user check box on each
parameter in the linked reports properties. This doesn't affect the
original report. If you update the original, the linked report will
reflect these changes too. Security can be set completely independantly
too.
Chris
Jeff A. Stucker wrote:
> To protect it on the back side (from someone simply altering the URL
> to look at someone else's data) you could always create a permissions
> table that contains all of the usernames that each user is allowed to
> look at, and have that table always be in the source query join, with
> User!UserID passed into the query. We're doing a variation on this
> (a join to a parameterized UDF) for our data security solution.sql