As described in Understanding Context, reports are placed in specific folders according to type of context, the report is designed for - and these folders may contain an arbitrary number of subfolders in several levels.

You may use folders on your local hard disc for setting up security on your local computer. In this way you can control, which users get access to the files in the folders.

Reports are displayed using the TOPICA Explorer, which allows the configurator to set up security on folder level.

In much the same way you may use the reports folders and subfolders in the Configuration Folder Structure to setting up security (access rights) in a TOPICA application. This controls which TOPICA users get access to reports stored in these folder.

Note that since security is set up on folder level, it handles all report formats: TOPICA Reports XML format, Custom Reports ASPX format, Reporting Services Reports

This is done using TOPICA Basic:

• As the TOPICA framework displays the hierarchy of accessible reports, it checks each folder for a file with the name Access.tb (extension "tb" means "TOPICA basic").

• If Access.tb does not exist, access to the folder is granted per default.

• If Access.tb exists, it is read, and the entire content is evaluated as a TOPICA basic expression.

• The result of this expression must be a boolean value. If this value is true, access to the actual folder is granted. If this value is false, access to the actual folder is denied (this shows in the user interface as a disabled / "dimmed" folder icon).

• If Access.tb exist, but the content is not syntactically correct TOPICA basic, or the expression does not evaluate to a boolean value, access to the folder is denied.

  Note that no error message is given in this case (to be fixed later...).

Just as you may set up security for individual files on your local PC, you may set up security for indivual reports.

For TOPICA Reports XML format (which is also used for "stubs" to integrate Reporting Services Reports), this is also done using TOPICA Basic:

Write a TOPICA basic expression in the Condition attribute of the ReportDefinition element.

If the contents of the Condition attribute is an empty string, access to the report is granted per default.

If the contents of the Condition attribute is a TOPICA basic expression, and it evaluates to the boolean value true, access to the report is granted.

If the contents of the Condition attribute is not a TOPICA basic expression, or it does not evaluate to a boolean value, and error message is shown - access to the report is granted.

Custom Reports ASPX format do not use XML files for TOPICA Reports XML format. It is entirily up to the developer of this ASPX to implement any security.

As described above, you may choose to implement security on the folder or the report level. Whenever possible, you should choose to implement security on the folder level - for the following reasons:

Folder level security shows up directly in user interface. When a folder is inaccessible, the folder icon is dimmed and inactive. Thus inactive reports never show up in the user interface. Report level security, on the other hand, only has effect after the user has has selected (and stareted) the report - so user sees reports that cannot be run.

Typically, several reports share the same "security profile" (= rules for which users may run specified reports). Using folder level security, you only have to write the TOPICA Basic expression for access once. Using Report level security, you would have to copy/paste this TOPICA Basic expression into every report.

In short, the only reason for using report level security is, that if you have only one report with a specific security profile, you might find it silly to create a folder containing only one report.

Row level security is the process of ensuring, that reports do not show data that the user should not have access to

As discussed elsewhere, data is pulled from the database using ordinary SQL queries in ALL report formats. These SQL queries are sent directly to the database. The framework cannot analyze the SQL - and it can neither modify the SQL before it is sent to the database, nor can it "filter" the returned data.

Therefore, it must be streesed that it is the responsibility of the report designer to construct SQL queries (based of context information and other parameters sent to the report), so that row level security is not compromised.

When designing a report that displays data for a selected organizational unit (e.g. a hospital department), it would be an error to use an SQL query SELECT * FROM SomeTable (without a WHERE-clause). This query would return data from ALL organisation units (e.g. a hospital departments) in the database. When the report is started with an organizational unit in context, the query must have a WHERE-clause that selects only the data that belongs to the organizational unit in context.

Because row level security is the responsibility of the report designer, it IS possible give user access to data, that should normally be inaccessible to the user.

Other Resources