Child pages
  • Colon authorization during query execution
Skip to end of metadata
Go to start of metadata

Purpose

The description of the aggregation authorization logic ("colon authorization") applies to all releases of BW. The possible problem solving measures also apply to all releases.
However, the description of the log applies to BI 7.0 Support Package Stack 14 (Support Package 16) and higher releases.

Overview

Below is the description of what is meant by the colon authorization and examples how problems should be investigated.

Description of the authorization check

You require aggregation authorization ("colon authorization") to view the values of an authorization-relevant characteristic in aggregated form. What does this mean exactly?

Example:
The calendar year (0CALYEAR) characteristic is authorization-relevant and is contained in the InfoProvider that is in use. You defined a query as follows:

1. 0CALYEAR is in the free characteristics (not in the drilldown) without any selections

2. 0CALYEAR does not exist in the query at all.

In both cases, no 0CALYEAR values are displayed in the query. Also, the query is not restricted to any 0CALYEAR values. A colon is required for the authorization check in this situation.

Note the following in particular about case two:
The query does not contain the authorization-relevant characteristic. However, this does not mean that an authorization check does not take place on this characteristic. This is because the characteristic is contained in the InfoProvider. What relationship do the displayed key figures have to the calendar year? The displayed data does have a relationship to the year. The described query displays data from all years that are posted in the InfoProvider. Each individual figure that is displayed represents the sum (aggregation) of the corresponding data from all years.
This form of display must be authorized by colon authorization.

Special case: Structural components (restricted key figures):
Many queries contain several structural components that contain a separate local filter. These could be columns (for example) with local restrictions on the last three years 2008, 2007 and 2006. In this situation, note the following: If the query contains another structural component (another column) which does not contain a characteristic restriction (0CALYEAR in our example), the colon is required during authorization. This is because aggregated values are displayed in this column.

The display in the authorization log

The colon authorization check is displayed as follows in the authorization log:

Section/subsection:
Authorization check  (orange header)
sub-selection (technical name SUBNR <n>) (n: Counter of sub-selection)

Addition to the selection for aggregated characteristics
A check of the aggregation authorization is added: <characteristic name>
Step one: All characteristics that (according to the above logic) require colon authorization are listed.

List of authorizations that authorize the selection with ":" (aggregation)
Step two: The following table lists the authorizations that contain a suitable authorization. Suitable is, of course, the colon ":" itself.
Full authorization "*" and variable authorization "+" are also suitable.
The table contains the characteristics in the rows and the authorizations in the columns. A maximum of 10 authorizations are displayed.

Note: The authorizations that are displayed do not necessarily correspond with the assigned authorizations. An optimization step of the authorizations (for simplification and summarization purposes) is carried out beforehand. The numbers of the optimized authorizations are then displayed (1,2,3 and so on). Activate the "Buffering the Authorization Data" display to see how these numbered authorizations are generated.

Only those authorizations that contain a green entry in all rows are used to authorize the query selection. All other authorizations are rejected during this step.

The check for characteristics that require colon authorization is also ended during this step. These characteristics are no longer taken into account in the following detailed check.

In the next stage, the other characteristics are checked in detail.
This text signifies the end of the colon authorization check. A detailed check of the remaining characteristics is performed which involves individual values, intervals, hierarchy nodes and so on.

The authorization check stops here because this sub-selection can no longer be authorized.
This text is displayed if none of the optimized authorizations that has all of the required colon authorizations. It is therefore the case that each authorization is insufficient for at least one characteristic in the selection. The check of the entire sub-selection must subsequently fail. A further, more detailed check is not required.

Problem solving

If the colon check means that the query leads to the display of message EYE 007 "You do not have sufficient authorization", you have two options:

  1. Grant colon authorization to the user.
  2. If you do not want to grant the user colon authorization: Restrict the characteristic in the query to a certain selection (single value, interval, hierarchy node, and so on) and authorize this selection explicitly. In the case of structural components (described above), all structural components must have an explicit restriction.

You must perform one of the above actions if the characteristic is authorization-relevant.

Note

Star authorization ('*') authorizes everything (of course, this also includes selections that require a colon).

Colon authorization is not taken into account when you use a variable of the type "Fill from authorization" since it is not known whether the affected characteristic is in the drilldown during variable processing.

Related Content

Related Documents

Related Notes

  • No labels