I am trying to figure out what determines which data sources will be in the selection list that an InfoAssist user sees.

MR is aware of the groups the user belongs to, and hence the MR domains he can access; but the datasource synonyms reside in folders on the back-end server, not in the MR repository. What determines which folders will be searched for a particular user; and what ensures that the folder containing the selected datasource's synonym will be part of APP PATH when the report is executed?

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

quote:

APP PATH

Site profile (site.wfs)
sytem profile (edasprof.prf)
user profile (user.prf)

If that's all there is ... it's a noticable gap in the architecture.

(a) it saddles the admin with crafting and maintaining the user profile to reflect each user's MR scope (essentialy, one's set of group memberships) -- hit-or-miss manual maintenance at the user level. The architecture should enable one's access to the WFRS's folders to self-adjust, as one's set of group memberships evolves (or the set of domains associated with the groups themselves evolves).

(b) the list of data sources should adjust down to the run-time context: if I am adding a report (or reporting object) to a particular domain, the list shown should reflect the data which that domain is "designed" to access, so that the object created can be safely "shared" within that context.

Anyone out there who has worked out a modus operandi?
NFR?
-- Or did I miss something?

Then don't use server profiles. Each domain can have a list server application folders that are used when fetching list of master files.

quote:

Originally posted by Brian Suter:
Then don't use server profiles. Each domain can have a list [of] server application folders that are used when fetching list of master files.

Thanks for chiming in. That sounds more like what I am looking for, with regard to edit-time behavior. How does one set that up? Where will I find it documented (for 7.7.x)?

But there's also the run-time side of the coin. Can MR be configured so that execution of any report stored under a given domain will initialize the app path to include the domain's associated list of app folders?

Found it.

WF MR Admin manual, 7.7 (http://documentation.informationbuilders.com/masterindex/html/html_iway77/wf77mradmin/wf77mradmin.pdf)

Chapter 2. Creating Domains, Groups, Roles, and Users

Working With the Server and Application Path Properties
How to:
Specify the Application Path

(Pages 45-47)

-- addresses both edit-time and run-time behavior.

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

Frequently the app folders include synonyms that are needed behind the scenes but are not appropriate as data sources for end-users composing a report.

IMHO it would be a useful enhancement to provide for two APP PATH strings associated with the domain
-- one for use at edit-time, when retrieving the list of available data sources.
-- another (supplementing the first) used at run-time.

That would allow the admin to designate which synonyms are visible to the user at edit-time, and which kept invisible but still available at run-time -- storing the former in a folder in the first path, and the latter in a separate folder included in the second path.

[And, since the second supplements the first, it would be backwards compatible.]

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

user profiles don't work, unless security is opsys (which brings in way too much overhead), so that leaves a problem with excel queries... They only see baseapp, unless you have all your business views on the path as well.
i put the business views for info assist into separate domains. that way i can keep the viewable list nice & clean