Hello,

I am very new to working with WebFOCUS and the MRE. I'd like to know how to limit the selections available in the WebFOCUS Masters List that appears when first launching the Report Assistant.

It would appear that this list is accessing all master files available in the edasprof app path definition. If this is true can I remove all entries from the path except the one I want users to access? What are the implications of doing that? Is it possible to set up additional profiles and cause the user/group to access that profile info when logging on?

Any assistance you can provide is much appreciated!

Thanks,

Dan

Dan,

Welcome to the WebFOCUS world.

Yes, you can create User Profiles on the reporting server and use:

APP PATH folder1 folder2 for User1
APP PATH folder3 folder4 for User2

This will override EDASPROF.prf

Hope this helps

Good Luck!

Tom,

That is good info. Does this require a separate profile for each user? Also, can you point me in the direction of documentation or some other resource to learn about creating these user profiles?

Thanks!

Dan

Dan,

Documentation is in:

WebFOCUS Managed Reporting Developer's Manual > Working With Domains and Standard Reports > Customizing Managed Reporting

Also in Developer Studio, Help, Search, type in User profiles, select Using Domains in Managed Reporting, then Customizing Managed Reporting link in the Profile Component box...


EDIT: Yes, a separate Profile for each user will be required, a bit of an ADMIN nightmare, but....

In 76, if you have this capability turned on, individual users (basic user to the reporting server) can update their own profiles using the web console without getting an admin involved.

This is a wonderful thing, as I am an admin. Makes my life a lot easier.

Ginny,

It's interesting that you say, "if you have this capability turned on" because I'm not finding the places in the documentation where it says I can add and adjust profiles. Where do you 'turn on' this capability?

Also, it appears that profiles can be set at the group level. Have you done this? If so, it would surely simplify things for us. We don't adjust access for individual users in our current applications. Instead we have groups of users that all share the same application, row and column permissions.

Thanks,

Dan

Dan,

From my experience, profiles aren't "Turned On". They must be 'Present" or 'Absent'. Profiles are *.prf files named for the userid and containing plain text. They are kept in the "Profiles" folder which is at the root of your 'apps' directory. (e.g. Mine would be '...\apps\profile\cburtt.prf'.)

When a user logs in, or a *.fex is run for a user, the Reporting Server searches the 'profiles' library for the user's *.prf. If it finds one, it uses it. If not, then the user's pathing is constructed from whatever sources the server has already found (or will find later).

Profiles may be created for users that do not exist. I use this 'feature' to create profile templates whose content I copy-n-paste into new profiles or old ones being modified.

Profiles can be maintained directly with any text editor, or with the DevStudio's 'WebFOCUS Reporting Server Console' (button) or the URL 'http://:8121/cgiatt.exe'. There is a nice profile creation and maintenance tool at 'My Console > Application Paths'.

Experiment! Use the fact that you can, with no harm whatsoever, code an APP statement containing name of a library that does not exist (WF will simply skip that lib when searching). Begin a profile's (or EDASPROF's) APP statement with a 'fake' name that identifies the profile (e.g. for mine: 'APP PREPENDPATH CBsprof ...'). Then when you view the whole path by with a *.fex containing 'APP SHOWPATH', the 'fake' name will identify the source of the path specification or, if you build paths piece-by-piece with APP PREPENDPATH and APP APPENDPATH, the source and placement of each piece in the final construction.

PS:
If anyone can post an insight on how Group Profiles are placed and used, I'd like to read about that, too.

Chris

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

WIN/2K running WF 7.6.4
Development via DevStudio 7.6.4, MRE, TextEditor.
Data is Oracle, MS-SQL.

Dan,

Information about the family of "APP" statements is found in the "Accessing Application Files" chapter of the "iWay Server Administration for UNIX, Windows, ..." manual appropriate for your installed release of WebFOCUS.

Experimentally I have found that the path in effect when a *.fex begins to run is constructed from a number of sources and varies with whether the *.fex is running under MRE or RCaster. I don't use DevStudio Localhost, so I don't know what happens there.

First, 'baseapp' is always added by the system as the last library in the default search path, so there is never a need to mention it in any APP command unless you replace the default sequence or want 'baseapp' earlier in the sequence.

Otherwise, the sources of pathing information and the sequence in which they are used is as follows. Depending upon the APP statement(s) and the sequence in which they are encountered, each successive source either modifies or replaces what has been specified earlier:
1) The default path sequence is from 'edasprof.cfg' (with 'baseapp' appended at the end).
2) Next the UserID Group/Profile is applied. [I've never experimented with Group profiles, but I presume they would be applied BEFORE the userid.prf specification.] As stated, these specifications either replace or modify edasprof's pathing, #1, above.
3) Then the name of the Domain (for MRE) or AppLib (for RCaster) containing the *.fex being executed is prepended to the combined results of #1 and #2, above. If no other specification is given, the system generates this Domain or ApLib name as the first entry in the composite APP PATH.
In MRE only, libraries named in the "Application Path" field of the Domain's or *.fex's 'Properties' window may be used for this 'prepending' in place of the *.fex's own domain. (Either Application Path field is used if specified without the other; the Report's is used if both are specified). The Application Path Property boxes can name multiple libraries: separate them with spaces and list them in first-to-last order.
4) Lastly, any APP command(s) found in the executing *.fex are considered in the order, and at the time, in which they are encountered. This allows for dynamically changing the search path for finding FOCUS code objects to accommodate the needs of different parts of the whole FocExec procedure.


There is also an entirely different schema available to specify which Applications, Files, and Field Descriptions appear in the development tools (DevStudio, Report Painter, etc). I suggest you look at this more complicated method if the APP PATHing methods I've discussed don't do what you want them to do. This other method is given in Technical Memo #TM4550 which is for 5.2.6 and higher.

The technique involves setting, in edasprof.cfg, full filepath ('C:\...\*.fex') values into four system variables (&&IBI_IF_*). The *.fex files so referenced contain WHERE and IF statements testing APPNAME to conditionally -INCLUDE other *.fex files containing WHEREs that test for values that will display in the columns of the Developer Tool's windows and tell which rows to display. Exclusions are specified via -INCLUDEing a differently named *.fex; so you specify included Applications/Files/Fields separately from those excluded.

Chris Burtt

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

I learned a very simple solution yesterday that allows me to limit the items in the Masters List. In the MRE administration tool I specified the application path in the Domain Properties window. By limiting the path to one specific directory the user now only sees those Master Files in that directory.

In relation to this I learned that dropping the users privilege level from Power User to Analytical User only lets them work with Reporting Objects and they can not see the Masters List at all.

quote:

In 76, if you have this capability turned on, individual users (basic user to the reporting server) can update their own profiles using the web console without getting an admin involved.

Note to Chris: The part about being 'turned on' referenced the users being able to update their own profiles. That option must be checked under Basic User Privileges (Change Own Application Path (No applock)) in order for users to be able to use the Web Console to change their profiles. Otherwise, an admin has to do it. We have a self-service shop and prior to 76 I had to update a user profile everytime wanted a new directory available to Report Caster. Now they do it themselves.

BTW, what we do is put global directories in edasprof with an APP PATH then have the users use APP PREPENDPATH in their profiles to customize them for their business unit.

GJ,

Thanks for the advise about 'Turn On'. I'll check to confirm that we've got ours turned OFF. Unlike you, we don't want our MRE user's tampering with the console stuff or their profiles. (We've only a handfull of MRE user's and RC Schedule creaters so there's no management headache.)

CB

The option is new to 76. They had to put back something they took away in 71.

And you are correct that it doesn't make sense for MRE users. But most all of ours our self-service.