Hi all,

I have created an application (collection of fex files and launch pages) in a domain and now I am trying to figure out how to allow multiple groups of users to access that same application without the need to copy it to another domain.

I know that I can create separate user groups and give them each access to the domain but here is the challenge. Content from one user group must not be visible to any other group. I want to allow my users to create and share their own reports but when they do that the reports are shared across the domain not just the user group.

Is there a way to prevent shared reports from being seen by members of different groups who have access to the same domain?

Thanks,

Dan

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

I don't think so. As you mention, report sharing is by domain so regardless of what you do with the groups, anyone who shares access to a domain can see domain objects shared by any other users of that domain.

One way around this might be to create a domain for each group, but instead of copying and maintaining code in all domains, just create shell fexes that basically -INCLUDE fexes that exist in the original domain.

I have set up a couple domains like this, but just for the purpose of sharing code while limiting access of certain procedures to different groups. I don't know how the report sharing would work since users in these groups are not able to create or share their own reports. In theory, it should work.

Darin, I agree.

We have gone as far as creating a common files domain, and call these from each domain.

The code is

-INCLUDE {domain}/app/{fexname}

The beauty of this is your source is kept separate, single point of change.

Dan

We go multi copy in MRE, but have a procedure that allows you to update MRE independent of ds and thus refresh all copies.

It works by scanning the HTML files within MRE to find out what the true filename of the named item in MRE is and then uses a simple DOS copy to refresh all other copies from the changed copy.

John

All,

The 'common files' domain idea is great and works well. I had first tried doing it by copying the files to an Application Folder on the server but that had it's own set of challenges.

Is there a trick to getting HTML launch pages to work across domains? When my launch page opens up, another browser window opens with the message "ERROR_MR_CANT_OPEN_DOMAIN_FOR_USER". This is what I thought would happen with the -INCLUDE that calls a fex from another domain but it didn't. I must admit that it scares me to know that I can just call a fex from another domain like that.

Anyway, the 'front-end' of my application runs from a launch page so getting this part to work is key for me.

Thanks,

Dan

I inherited an oddity that was set up before I showed up: an MRE domain that contains all the includes is mapped as an application folder. The domain is not added to all the user groups.

This may help or hurt your situation.

Well, now that I have my physical vs. logical file naming set up properly, it's a simple matter of copying from the domain of origin to the domain of destination. Then all I need to do is edit the HTML Launch Pages and replace the IBIMR_domain and IBIMR_folder values with those from the new domain.

It's not too painful from a deployment perspective. The trick will be when we make changes to one of the original procedures.

John - Would you be willing to share the code behind your procedure that does the search and replace of procedure files at the DOS level?

Thanks,

Dan

Dan, are your launch pages a URL or HTM file.

If it is an HTM file, you may be able to get the domain from the call URL.

Run one and have alook at the address. It should have things like IBIMR_action, IBIMR_sub_action, IBIMR_fex, IBIMR_folder, IBIMR_domain.

All you have to do is write a small script to populate the objects on the form onload.

Waz,

I tried creating a URL in the 'client' domain that calls an HTML file in the 'source' domain. I created it by first opening the HTML page from the 'source' domain and copying the URL from the browser address bar.

When the user from the 'client' domain tries to open the HTML file (that is physically in the 'source' domain) the error: "ERROR_MR_CANT_OPEN_DOMAIN_FOR_USER" comes up.

The URL looks like...

http://[servername]:8080/ibi_apps/Controller?WORP_REQUE...&IBIMR_random=30446&

Am I missing something?

Thanks,

Dan

P.S. - How do I get the full URL to display without the forum changing the format? If you right-click it and view the properties you can see the full text.

This message has been edited. Last edited by: Dan Pinault,

re your PS: CODE tags!
and re having your fexes viewable by all...
ah the beauty of a self-serv app

I put the URL in between CODE and /CODE tags but the display still looked the same as it does now. I removed them thinking that the forum woudn't interpret it as code and would include my text verbatim. Oh well!

I agree that a self-service app would be the ultimate way to go but we just don't have the expertise in house. We're just trying to squeeze as much functionality out of the MRE/BID layer as we can.

Dan, sorry, I wasn't clear in my description.

What you need to do is create a new file in MRE with the editor, paste in the HTML document, then when saving, change from Focexec File to Html File.

When the HTML file is run you will see the parms in the address.

Try this code out

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
 <head>
  <title> New Document </title>
  <meta name="Generator" content="EditPlus">
  <meta name="Author" content="">
  <meta name="Keywords" content="">
  <meta name="Description" content="">
  <script language="JavaScript">
  <!--
   function showParms() {
    var _urlsplit = document.location.toString().split('?') ;
    var _parmsplit = _urlsplit[1].split('&') ;
    var _parms = _parmsplit.join('\n') ;
    alert(_parms) ;
   }
  //-->
  </script>
 </head>

 <body onload="showParms()">
  
 </body>
</html>

Waz,

It's been a while since I've had the chance to deal with this again. Here is what I've tried...
-Created a 'common' domain called CommonFiles.
-Put my application procedures and launch pages in the 'common' domain (one of those procedures is the main ad-hoc html page for our application).
-Created a .fex in a 'client' domain with an HTML include that calls the ad-hoc html page from the 'common' domain. It looks like

-HTMLFORM commonfi/app/er1n6qvm.htm

.
-When I run the .fex from the 'client' domain it does launch the html page from the 'common' domain but then I get errors.
-The listboxes on my launch page are populated by procedures. After trying to populate the listboxes I get another browser window with the error: ERROR_MR_CANT_OPEN_DOMAIN_FOR_USER Can't open domain commonfi/commonfi.htm for user dpinault. That is because user dpinault has access to the 'client' domain but not the 'common' domain.

How do you get around that issue? I can't add all my users to the 'common' domain because that will expose the 'common' domain contents to the users of different 'client' domains. It will also expose any shared reports. In short, it will defeat the purpose of having different user Groups/Domains. I wish it was possible for Group-Level security to control what is displayed in the Domain Tree and use Domain-Level security to control what the different users/groups have access to.

Thanks again,

Dan

put your listbox fexes in apps, or "on the backend" as they call it.
i share your pain, and i, too, wish that bid were a better and more flexible app.
You can assign an app path to a domain.
or, you can always make your launch pages from fexes that declare their own absolute app path on line 1

Susannah,

Great suggestion! I modified one of my launch pages and it seems to be working just fine.

Rumor has it that v7.7.x will allow much more control of the BID environment. Let's hope!

Thanks,

Dan

aha! good for you.
lets be hopeful!

I wanted to get some clarification, as we are looking at something similar. I currently have procedures for populating the list boxes which rely on the IBIMR_user to go against the proper rows on the table. This works fine if it is in the same domain, however I am not sure how to make this work if I put those fexes in an application folder instead. I have tried just moving them, but get errors. Can someone give me a simple step by step of what to change, knowing that I need to user id for my procedures to work?

Magic,
/APPS folders aren't in mre, so they can't address the &IBIMR_user. the MR is for Managed Reporting.
so, leave the fexes in MRE.
if you want to make the mechanics in these fexes usable across multiple domains (if that's why you are moving them to apps), then there are a number of options:
eg: let your launch page fex call the backend fex
Like this:
mydrop1.fex (in the domain and in the launch)
-TYPE &IBIMR_user (or whatever you're doing with your userid)
-MRNOEDIT -INCLUDE someapp/mydrop11.fex
-*...
so you can share your logic across your different places.
Any help?
-s.