Cognos Viewer in the Portal - Affect on Javascript 8.2 to 8.4 upgrade

[MMcBride]

I have run in to a slight issue and thought I would toss this out here and see if anyone else has experianced anything like it.

I am prepareing an 8.2 to 8.4 upgrade and use Javascript for several different things in my reports, for the most part I haven't had any issues with the new 8.4 way of doing things.

I used this Knowledge Base article to allow me to Pre-Populate a Date Prompt in 8.2 and it works fine, using the modified 8.3 recommendation these reports still work for me.

http://support.cognos.com/knowledgebase/googlesearch?load_kb_document=1&dr=kb1&uniqueid=140483


For CRN, Cognos 8.1 and cognos 8.2

<script language="javascript">
// Note: This technique uses JavaScript against underlying report objects in a Cognos 8 BI report.
//       For this reason, there is no guarantee that reports created using this technique will
//       migrate or upgrade successfully to future versions without requiring modifications.
//       Any such modifications are the responsibility of the report designer.

if (document.forms["formWarpRequest"].elements["_oLstChoices<fieldname>"].length ==1)
{
document.forms["formWarpRequest"].elements["_oLstChoices<fieldname>"].selectedIndex = 0;
setTimeout('listBox<fieldname>.autoSubmit()', 100); }
</script>

Where <fieldname> is the field name from step 3.

For Cognos 8.3

<script language="javascript">
// Note: This technique uses JavaScript against underlying report objects in a Cognos 8 BI report.
//       For this reason, there is no guarantee that reports created using this technique will
//       migrate or upgrade successfully to future versions without requiring modifications.
//       Any such modifications are the responsibility of the report designer.



if (getFormWarpRequest()._oLstChoices<FieldName>.length ==1)
{
getFormWarpRequest()._oLstChoices<FieldName>.selectedIndex = 0;

// if the report is running from reportStudio or the Portal objects are different

if (getFormWarpRequest().elements["cv.id"].value == "RS")

     setTimeout('oCVRS.promptAction(\'finish\')', 100);

else

    setTimeout('oCV_NS_.promptAction(\'finish\')', 100);

}

</script>

Up to this point everything works.

Here is what I am doing.
We have several reports that have the prompts on the data page, to keep the report clean we hide and show these prompts with some additional javascript (which didn't change in 8.3/8.4).

These are ReportStudio Reports built off of a Cognos Cube.

We want to force the value of the "Current Month" into this prompt - the script above does this wonderfully. We have a prompt page that is basically hidden - we have it display "Please wait while your report is being constructed" the Date Parameter is then populated by the script above. Then once the report has refreshed we have a second Date Parameter on this page (using the same Paremeter name) with a default value of the Parameter.

This allows us to have 5 years of history by month in this Prompt but when the report is opened always defaults to the Current Month and gets us away from having to manually hardcode the Member Unique Name each month.

Once again - this works great even in Cognos 8.4


However, one of the reports is used in the Cognos Viewer on a Portal page as our "Dashboard" for the application.

On this portal page the Script to populate the initial prompt is bypassed due to the new prompt features that have been added to the Cognos Viewer in 8.4

My options at this point are:
1 - Go back to hardcoding the Member Unique Name each month for this Dashboard report
2 - Find some way to force the Cognos Viewer in the portals to work the same way the Default Cognos behaves and process this script - as it does in Cognos 8.2
3 - Call out for help and hope someone else working with the new Cognos 8.4 release has found a way around this.

Any feed back on this would be appreciated.

[MMcBride]

I thought I should update this in case anyone else runs into an issue like this.

After going round and round with Cognos we pulled the (Pre-Populate a Parameter with Last Processed Date) Javascript completely.

It is simply to unstable and there is no direct corrolation to the way it used to work in Cognos 8.2

For a multidimensional source there is a good solution to this problem

That solution is a Prompt Macro, we created a "Current Month" Data Item with the following formula:

#prompt('finishMonth','memberUniqueName','closingPeriod([CBMR].[Accounting Date].[Accounting Date].[Month], item(tail([CBMR].[Accounting Date].[Accounting Date].[Year], 1), 0))')#

We still have the Date prompt on the Report page and if you select a previous date it works perfectly fine.

With our Relational Reports we could not find a solution using the Prompt Macro (These work for relational reports as well, just not the way we needed it to work).

So for our relational reports the only option left was to manually code in a default Value for the Prompt, and hard code each ParamDisplayvalue() on the report.

If you use a proper Prompt page you don't have to worry about these issues, this only affects attempting to pre-populate a parameter where the Prompt resides on the Report page itself. We have an enhancment request in with Cognos to allow us to use something other then a Text value in the Default value section of a Prompt but as Cognos Support made it clear.

If you simply use a prompt page and force the users to select the date you wouldn't have this problem.

Thats fine, but that is not what my customers want, and these reports are Executive reports so these customers are all VIP's
So for these reports

[wallybuz]

Do you have an XML spec that you would share?  I am trying to use a relational db and pre-populate last month, as well as year for last month;  I can populate it with javaScript, however, it accepts a hardvalue when scheduling.

So, I need a pre-populated month prompt, year prompt, that defaults to prior month and it's appropriate year, that is able to be scheduled and untouched.  The report, however, must also be interactive to run in ad hoc fashion.

Thanks,
Wally