Report Level Scripts

Report Level scripts comprise:

• Code Library scripts
• Permission script

Click the links for further details.

Code Library Script

Editor: Report Menu > Codelibrary Script	Main purpose: Write common script classes available from any other scripts in the report. Multiple Codelibrary scripts can be added to a report, stored in the Codelibrary Script folder node in the Report toolbox. Many classes can be added to each script.
Description: In this script you can write your own classes. These classes will typically be used as follows: When you have some common logic that should be used from several of the other scripts in the report. When the logic in a hide script is too complex to be expressed in an expression, you can implement this logic in a common class and just call this method from the hide script. If you want to use any of the objects available in other scripts, you must pass them as parameters to the code library script. To add a new script, in the Report toolbox right-click on the Codelibrary Script folder node and select Add Codelibrary Script.
Example - Codelibrary: class MyLib { __function MultiplyBy100(value : Decimal) : Decimal __{ ____return value * 100; __} }
Example - Use the library in a Text component: if(!state.Parameters.IsNull("p_decimal")) { var lib : ReportCommon.MyLib = new ReportCommon.MyLib(); var val : Decimal = state.Parameters.GetDecimal("p_decimal"); output.Append(lib.MultiplyBy100(val)); }

All Codelibrary scripts will be stored in the Codelibrary Script folder node in the Report toolbox.

Permission Script

Editor : Permissions > Permission Script	Main purpose: Validate that the current user really has permission to all current values of all parameters. Can also be used to initialize required values for report parameters.
Description: This script is always called first for each page in the report and before exporting any object to MS Office or other format for that report. Even though you for example mask content of a parameter used in a dropdown to limit the user’s access to specific values, you should also write a permission script taking care of the permission control, for the following reasons: Even though input controls are masked, hostile users may try to hack the report using a tool to post other values to the input controls. If a report user for example has access to a specific parameter value on a certain point of time, he can save a page with the given value to one of his private folders (Viewer Presentation component). As report designer, you may want to revoke this access at some point of time. If so, the permission script will deny this user access to the previously saved page. In some cases you may want to design a report using projects that are not in the report data source. This may be the case if you are continuously making new projects available to a report and do not want to modify the report and re-publish it each time. Two steps are required to achieve this: Go to the Viewer Project Permission page and grant access to projects outside data source. Explicitly grant access to required projects in this script. If you like to initialize or change parameter values based on other parameter values, this can also be done in this script. Alternatively use the page script for this. These two scripts are the only scripts where you are allowed to change parameter values.
Example - Allow access to project not in datasource : // Authorizes project outside datasource state.AuthorizeProjectAccess("p0559090");
Example – Raise permission denied : var unit : String = state.Parameters.GetString("p_unit"); if(user.UserId == "someuser" && unit != "someunit") HasPermission = false;
Example – Derive a parameter from another if(state.Parameters.IsNull("p_project")) state.Parameters["p_question"] = null;