Removing/Disabling unwanted options from Export functionality in OBIEE12c

Tiwari

Dear Guru's,

We are using the OBIEE12c for the our client. We have proper Development, UAT and Production environment on exalytics machine where OBIEE12c is hosted.

Client is very much strict to provide only four export options like, PDF, PPT, XLS & CSV. Apart from these four they wanted to remove/hide other options like Web Archive (.mht), Data --> Tab delimited Format and Data --> XML Formats.

We have tried convince them these are additional options provided where the action is completed depended on user to use or not but they are not agreed.

our UAT sign off is on hold because of this.

We have workaround to apply the changes in the server file but this will affect the entire dashboard. The request is only specific to one set of users.

Kindly provide the solution/workaround to achieve this. I believe there must be some java script which will resolve this issue.

Best Regards,

Ritesh

[Deleted User]

3610897 wroteKindly provide the solution/workaround to achieve this. I believe there must be some java script which will resolve this issue.

You may believe so if you choose, but making this security-dependent will require changes which will make the solution no longer supported.

You choice. Respectively "your client's choice". I doubt that an consultant worth his money or reputation would ever counsel something like this to go ahead.

Thomas Dodds

I second @Christian Berg's comments ... the real issue is that you are at the point of implementation when this requirement should never have made it past the wish list.  It's an non-vetted requirement leading to an runaway expectation ... your best action (as a consultant) is to get it documented and signed off on as such (make your case to your consultancy leadership who can help come up with a better method of convincing the client)... then work toward project completion (deliver everything else).  Personally, I'd also be guarded about even providing a work-around solution -- in the event that something unsupported is implemented you don't want that reputation. 

Reserve the right to spend time on vetting 'unconventional' requirements and deeming them out-of-scope/not implementable for "just cause".  You aren't only being paid to DO, you are also being paid to GUIDE.   The latter duty being the much, much, harder of the two.

You are indeed in a sticky spot ...

Charles M

Hi,

In addition to the replies you have received (which I agree with), you should also consider/have them consider future upgrades. Stuff like this always comes back to bite you during an upgrade. It will take a bunch of time to figure why something isn't working ... then, after hours or days of digging around, someone will figure out what happened. Its likely you'd need to revert it back during the upgrade, or it gets overwritten altogether.

My opinion is that is isn't worth it to make unsupported changes (especially for very little benefit). Plus, you loose some options/flexibility of the application. Who knows, someday there may be a need for those options.

Regards,

Charles

[Deleted User]

Yes. Support, patching, upgrade...or the inability to do so. Perfect approach to destroy a solution in the long-term.