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?

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.