I'm new to the Managed Reporting/BI Dashboard world...

I have the following scenario. I would like to create a domain for my application. Access to different things (such as reports, HTML pages etc.) in the domain will be determined by the role of the user logged in.

I know I can create a dashboard view based on a group and then add content just for the users in that group. That would work well except that for one of my reports, for some of my users, I would like them to have the ability to save the parameters of the reports, or run previously saved reports or shared reports etc. This means they need to see the domain tree. Which means they will see things in the domain that don't pertain to them. I realize the role tree would limit what a user sees, but again, I don't see how they could then access the "My Reports" and "Shared Reports" of the domain in the role tree (and/or the dashboard).

I don't want to create multiple domains as some of the reports, HTML's etc. are used by more than one group of users and I don't want to be maintaining more than one version of each component.

Can someone tell me how best to approach this scenario?

This message has been edited. Last edited by: Kerry,

Go ahead and create your dashboard views like you describe and for those that need additional capabilites, just have them log in to the Managed Reporting environment. It's a little bit of a pain to have them in separate places, but the separation of functionality you describe is going to require a little different approach.

Thanks for the response - I think I'm not understanding, though. They will log in to Managed Reporting even for the dashboard (but I was thinking of not showing the domain tree). And if I do show them the domain tree for those who need to see "My Reports" and "Shared Reports", they will see stuff that doesn't pertain to them - that is what I am trying to avoid.

There are a couple of different environments we're talking about. The first is the Dashboard where you can add your reports, links, and the domain tree, if you wish. The second is the standard Managed Reporting Environment, where all you see are your domains, reporting objects, My Reports, etc. you get there by going to the link http://servername/ibi_html/workbnch/mrlogon.htm

Actually, I think the "official" one now is http://servername/ibi_apps/login/mr/mr-login.jsp

This puts you in the environment you describe for your "advanced" users who will create some reports, save parameters, use "My Reports", etc. but you won't need to have the domain tree on your Dashboard for the remainder of your users.

Thanks for the reply.

The link you gave for just MRE is the Java Applet environment - I think we will be staying away from that. What I am ideally trying to achieve is only showing each user what he/she should see and still providing the My Reports and Shared Reports for those who I'd like to give that access to - all from one place.

Well, take your pick. That solution provides for the least amount of work and management. Is there a problem with using that reporting environment?

About your only other option is to create two separate dashboards that look the same except one shows the tree and the other does not. One group uses the basic and the advanced users use the other with the tree. then you've got to manage two groups and two dashboards.

What I'd like to see is the ability to add Reporting Objects to blocks or pages just like they were a standard report. That way the user never sees stuff we don't explicitly show them.

That's precisely what I'm trying to accomplish. I'm still trying to think of other ways of doing this.

quote:

What I'd like to see is the ability to add Reporting Objects to blocks or pages just like they were a standard report

Did anyone figure out if this is possible?

Channy,

Let's see if I understand you correctly:

You want an application in which users can have access to various reports (fexes) and HTML pages (URLs) depending upon their User-ID.

Do you also want them to create their own reports and save them? Would these reports be shared or personal?

My application has the typical assortment of "stuff" - procedures, includes, SQL pass throughs, synonyms, HTML launch pages, etc.

The groups overlap a bit in that some people may have access to Reports 1, 2, and 3 while others may have access to Reports 3 and 4.

I obviously would like to only have one copy of everything but be able to share common stuff across domains.

For one group of users they are supposed to be able to have the ability to save and share reports.

Thanks.

Have you considered hiding report types from the domain tree based on the user roles?

You can customize the Domain Tree to display or hide any or all of the available report types
(Standard Reports, Shared Reports, My Reports, and Reporting Objects) for specific role
types in all views. If you do not want to hide report types for all users of an existing role
type, you can create a new role for specific users. Note that if you choose to hide My Reports from displaying in the Domain Tree, users will not have the option to save parameter reports since parameter reports are a type of My Report.

The View Builder's Edit Settings feature provides an admin/group admin an interface to enable and disable features, display or hide types of reports in the Domain Tree, change the appearance of the view, and perform other customizations on a per view basis.

Yes I thought of that but I still would need standard reports to always show - no matter who the user is - it's just a matter of which reports they can see in the standard reports.

quote:

The groups overlap a bit in that some people may have access to Reports 1, 2, and 3 while others may have access to Reports 3 and 4.

I obviously would like to only have one copy of everything but be able to share common stuff across domains.

See if this works. Set up domains for each group, containing stub fexes that simply -INCLUDE the same fexname from a 'central library' domain. That way their domain trees will only show 'their' assigned list of reports, and there will be just one central copy of the real report (complete and executable by itself) to maintain.

I don't think you can -INCLUDE a fex from another domain.

Apparently you can:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WebFOCUS Managed Reporting End User's Manual (7.6.1):

Syntax: How to Incorporate a Standard Report With -INCLUDE
-INCLUDE [domain/]app/filename
where:

domain
Is the domain where the Standard Report resides. This value is only required if the Standard Report resides in a different domain.

filename
Is the file name of the Standard Report, including the extension. This value is prefaced by app/, for example,

app/yrsales.fex
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I presume it will fail if the user has no access to the referenced domain; you need to arrange your configuration so that they have sufficient access to the common domain so that the -include is honored, without being able to browse the common domain.

This message has been edited. Last edited by: j.gross,

Jack is correct (well, obviously since he cited the source from the manuals!). We use this technique in a couple different applications - not necessarily to accomplish the same thing. In one app we have three domains - one for Imaging and one each for two subdepartments in Imaging. The subdepts -INCLUDE code from the main domain using the syntax Jack has included.
Simplifies things because we only have to maintain code in one place.

A little non-sequitor but useful nonetheless...

I use cross domain -included fexes a great deal, and they are a pain due to the IBI random naming convention (don't get me started).

I find the easiest way to -include files is to right-click in the DS text editor, and choose the "new include" menu option. This will allow you to browse for the fex you need even over in a different domain.

One caveat. If the included fex is in the same domain as your includer fex, the path will not have the domain explicitly stated.

EG:

-INCLUDE app/included.fex
rather than
-INCLUDE otherdomain/app/included.fex

This will be a problem if you copy the includer fex elsewhere.

Charlottesville...
let me see if i can ease your pain re random naming...
When creating a new domain,
what we do is create the 8-character directory name FIRST in the name box, and always start with the letter d.
eg
'duvachar'
and go head and create the domain, the directory for which will be duvachar and the index will be duvachar.html
then
we go back and right click on the domain name and edit the PROPERTIES box to create a lovely, presentable name;
eg
'Univ of Virginia Charlottesville'
and now that domain will appear to have a nice name in mRE and in Dashboard and devstu, but the real domain name will be according to our naming conventions.

In addition to Susannah's suggestion, I would put the duvarchar in parens after the "readable" name so that a developer looking for "duvarchar" later will be able to find it at a glance.

pb, if you're using the TREE in Dashboard, that would look icky, imho. the developer can right click on a domain name in domain builder and look at properties to see the 'actual' directory name.

Susannah and PB,

Good suggestions and I did come up with something similar myself. Unfortunately I have a huge number of domains and reports created in 5.x that are truly random (gurk862s, zzgkt56a.fex) and the time it would take to recreate the files with rational names and rebuild the dashboards... *sigh*

I've asked the IBI folks some time ago to determine if it is possible to present Reporting Objects on the dash as a Standard Report, but have yet to receive a definitive response.

If I knew back then what I know now, I would have done things quite differently

Charlottesville, a reporting object is really a master file, with some bells and whistles optionally added...so its not a complete report..so wouldn't really 'fit' on the db....
at least i can't see a way

btw..do you use Banner at uva?

Hmm.. I looked in the MRV folder and Reporting Objects looked like a specialized type of standard fex to me. There are a few GOTOs etc that rely on the runtime environment etc, but nothing I saw looked like it precluded its inclusion on a dash. If the correct initialization can happen on the tree, why not the dash?

As for Banner, to the best of my knowledge the School of Medicine here at UVA doesn't use it. I've no idea about other areas within the university.

but the fex is empty
a reporting object is just a shell, starting with the setup of a master.
the user puts the elements in, clicking and dragging.

Indeed it is empty, and the user does all the work. However I still don't understand how invoking the applet is possible from the tree pane in the dash, but not a block. Ignorance is bliss I know, but I just can't see why it would be such a big deal to accomplish with a little effort. The win for the poor MRE admin (that means me natch) would be great!

Just wondering if you resolved this issue. I'm dealing with the something similar.

My first two tabs list reports, my third tab list reporting objects for the users to execute. You can only do this by providing the domain tree, which lists the same reports I provided on tabs 1 and 2 under the standard reports folder....

Thanks,
Imani

This message has been edited. Last edited by: kupa,

oh that one is easy
you can 'edit settings' in view builder on that view to hide 'standard reports' from 'all users'
and you'll see more stuff you can do, when you 'edit settings'

Thanks for responding Susannah!

If I hide 'standard reports' from the users...the users will not be able to see the reports on tabs 1 and 2...that is my issue..

ChannyS -

If I understand your original question correctly you want to do something like this...

1)Create a 'common' domain where your applications reside
2)Allow users from other domains to run these applications while giving them the ability to create Saved Parameter reports in their domain rather than the 'common' domain.
3)Maintain proper security so users from, say, Frodo's domain do not see Saved Parameter reports from Boromir's domain and vice-versa (especially since Boromir would really like to get access to Frodo's domain!)

If this is the case there is hope. As of v7.6.10 you have the ability to HIDE a domain. This gives you the ability to create a 'common' domain to house your applications without the users actually seeing the domain. To make use of this you need to give each user group access to their domain and the common domain. Then, when you create content blocks in their dashboard views you simply point them to the applications in the common domain.

Now, the aforementioned will allow you to keep all your apps in one domain and make them available to other domains BUT there is a glitch. When the user creates a Saved Parameter report it is also saved to the common domain which, of course, they can not see. The result is that it appears as though their Saved Parameter reports are lost in the fires of Mount Doom.

The good news is that in v7.7 this has been fixed. That bad news is that you'd have to upgrade to v7.7. You may want to check with support to see if that functionality has been added to any of the 7.6.x hotfixes.

I hope this helps,

Dan