APEX

The new Interactive Reports are a great feature that will be extremely helpful for both our development team and our users. However, currently when a user saves an interactive report, there's no way to share it with other users or to make it a public report that can be viewed by everyone. This is because the report is saved with the user's name and can only be viewed by that particular user. This really limits the usefulness of the interactive reports. For example, we would like to enable our power users, administrative users, and even regular end users to be able to create and modify reports and share them with others. In addition, our company has several hundred Crystal reports that we would like to replace with interactive reports. However, if our development team creates all of these as interactive reports (using the “Save Report” feature, not as separate pages), there is no way to make them public so that all of our users can then access them. I've read several requests in this forum for this type of enhancement. I've also read that the apex team intends to implement this sharing feature soon. In the meantime, I've figured out a work-around. This work-around saves and retrieves all interactive reports using a generic, fictitious user name. Using the Page Sentry Function under the Authentication Scheme, we switch the APP_USER to a generic, fictitious user only for the interactive report pages, and set APP_USER back to the original, correct user on the other pages. Here's the code I'm using in the Page Sentry function:


declare
c owa_cookie.cookie;
begin
if :app_page_id in (1,51,52) then
APEX_CUSTOM_AUTH.SET_USER('REPORT_USER');
else
c := owa_cookie.get('LOGIN_USERNAME_COOKIE');
APEX_CUSTOM_AUTH.SET_USER(c.vals(1));
end if;
return true;
end;


This code will set the APP_USER to "REPORT_USER" on pages 1, 51, and 52. Therefore, when interactive reports are saved or retrieved on these pages, they will use the user named "REPORT_USER" regardless of the user that actually logged into the application. This concept can also be expanded to limit certain reports to certain users (or groups of users) by calling a custom function in the database.

I tried using the SET_USER code within a page process (PL/SQL anonymous block), and although it changed the APP_USER, it did not affect the interactive report. I assume this is because the interactive report “does its thing” prior to the firing of the processes on a page. However, the Page Sentry function apparently fires earlier in the sequence (before the interactive report processing).

This will make the interactive reports much more useful for our company and I hope it will be useful to some of you as well.

Darrin