Question:
We're planning to provide adhoc query development (according to naming convention) in the production environment; curious what options exist for publishing the report once created.
Obvious option is to provide limited access in PFCG to maintain role menu of a particular role(s) for this purpose. Of course, this has audit written all over it - is there another way to provide a power user the ability to publish adhoc BW reports (workbooks/queries) to other users without providing PFCG?
Thanks,
Vincent
Answer:
You cn give access to PFCG but you don't need to give access to any of the S_USER* objects and you don't have to give generate authority for S_USER_AGR. You can also limit the workbook roles to a name range.
_________________
bwSecurity
Answer:
Thanks for the feedback.
We apparently also need to provide S_USER_TCD for RRMX.
Another couple follow-up questions
1) The BW report is inserted into the role menu based on the GUID value, how do you prevent them from adding a report other than the one's they've created directly in production - the concern being with confidential reports; I'm anticipating that you wouldn't be able to, but would depend on Infocube limitations/authorization relevant fields, etc.?
2) Do you ever run into an issue with leaving the role ungenerated?
Answer:
Generating roles generates authorizations.
I really don't know how you can keep them from inserting another report. I'll be logging in to a BW system tomorrow and I'll check it out.
_________________
bwSecurity
Answer:
Why should you want to give access to PFCG to anyone???
If i understand correctly you mean by ad-hoc reporting: reports created by endusers on production??
What i do:
Create 4 kinds of roles for every area:
a Report menu role, Only contains the workbooks, Queries for users to run
b Report Reader role, can ONLY run reports. from role type a
c Report Writer role, can create queries/workbooks on any Infoprovider in the Area, but is restricted in naming convention when saving the Queires/workbooks. Can ONLY Change queries OWNED by the User. As of BW 3.0
d Report Publisher role. This person can Publish Queires/workbooks in roles of a. But only to the roles as specified in this role!!
All users who have the roles above can do ALL these tasks in the BEX so no need to allow them into the PFCG. Besides as a matter of safety. Do not teach them to use the GUI for BW, instead learn them to access the BEX directly!!!
Answer:
auke_visser,
What you're describing sounds exactly like what we're looking for, but I'm not sure how to achieve - do have any links to documentation on the publishing or could you provide some tips on what we would need to do to use this functionality in Bex - particularly, what access is necessary in BW roles that allows this functionality.
Thank you,
Vincent
Answer:
We contolled the access to roles via a stict role naming convention and then providing a value in S_USER_AGR (no PFCG) with the appropriate role name to which the user (publisher) needed to publish reports to.
In "auke_visser" example, "d" Report Publisher role would have the name of role "a" in S_USER_AGR that would allow person with role "d" to Publish Queires/workbooks in roles of "a" and only to the roles as specified in this "d" role!!
Regards,
m.r.
Answer:
You may want to look at this link. Security people don't often use the bEx tools so they think PFCG (which works) but you can actually publish a role from the query developer interface.
http://help.sap.com/saphelp_nw04/helpdata/en/19/2615407e145c0ce10000000a1550b0/content.htm
I have thought about my previous comment on controlling which reports can be published. I haven't fully tested this but if you control the name range of reports a user can change in production, then he'll only be able to publish those reports to the workbook.
_________________
bwSecurity
Answer:
ps. You can't publish a role (this way) to a workbook role that you haven't been assigned.
_________________
bwSecurity
Answer:
if you send me an e-mail to auke@vis-bv.eu i will send you a set of example roles that work this way