However, if the applications become bigger, if more people work with them, or if different tasks are to be performed, then it may be worth arranging the applications on a user-specific basis in terms of content. This is possible with DeltaMaster: by means of an internal rights concept.

You can see how this works by e. g. having a look at the report list of DeltaMaster. The same application is shown each time in the screenshot below, but from the viewpoint of three different user groups: a regional sales representative on the left, the Head of Sales in the middle, and Controlling on the right.

The report list sometimes includes fewer reports, and sometimes more. Another difference is the button with the pencil (at the bottom), which is used to switch from Presentation Mode to Modi-fication Mode. In the example, this button is available to just one user group, Controlling (on the right). The returned values are identical in all three examples.

DeltaMaster and the databases

As a matter of principle, permissions in the overall system of a DeltaMaster solution need to be defined at two levels: in the database and in the DeltaMaster application. The responsibilities are clearly assigned:

• For the database, it is stipulated which data the users are allowed to access. Setting these rights is usually a task for the IT department. The relevant tools are part of database management and are of a technical nature.

• For the DeltaMaster application, it is possible to stipulate which users are allowed to access it – and, if applicable, which parts, namely which reports and folders. Granting these rights is a task for the department that operates DeltaMaster, usually the business department. The relevant tools are part of DeltaMaster and are accordingly easy to use.

The database is decisive when it comes to maximum confidentiality, data protection, and data security. Common database systems provide sophisticated and tried-and-tested protection mecha-nisms for this purpose. These apply to DeltaMaster as well as to all other programs with which the database can be queried. DeltaMaster executes database queries with the rights of the current user or of the user stated at the time of logging in (with the WebClient, if this has been configured; i.e. impersonation). DeltaMaster cannot tell whether there are other users or which data they would see.

The rights concept of DeltaMaster is independent of that of the database. Its task is to control how the users can work in DeltaMaster with the data that they receive from the database in accordance with their database rights. The DeltaMaster concept in this case is geared towards the application. The focal points are efficiency, ergonomics, organization, delegation, guidance, and leadership – it is therefore more about who is and isn’t supposed to see what, and less about who is allowed to see what.

Corresponding to the division of tasks between database and DeltaMaster, rights for different types of object can be assigned with

• the database objects for which permissions can be managed depend on the respective database system. With Microsoft SQL Server Analysis Services (SSAS), for example, permissions can be set for entire cubes, individual key figures (measures), filter properties (dimensions, hierarchies, dimension members), and even for specific cells (combinations of dimension members and measures).

• In DeltaMaster, rights can be maintained for reports, folders, the report list, and applications. In this issue of clicks!, we are concentrating on reports and folders.

I see what you don’t see

In particular, the DeltaMaster rights are used so that the same application has a different appearance and behaves in different ways depending on who is working with it. Here are a few example scenarios in which rights are beneficial:

• Taking account of different tasks in the business department
  The field-sales team uses reports as report recipients without creating them or changing their structure; by contrast, in-house staff must be able to do this. Some reports are only to be processed by Controlling.

• Mapping different operational functions in the same application
  Reports for different tasks are stored in the same DeltaMaster application, e.g. for Purchasing and Sales. Some reports, for instance regarding development of the margin or analysis of price effects, are relevant to both areas, and some are only needed by Purchasing or Sales. It is easier and there is no unnecessary distraction for the other department in question if these reports are hidden on a user-specific basis.

• Assigning administration and operational use
  In planning applications, most reports serve as an input screen for the planners. In addition, project managers, application-support staff, and administrators have access to reports with which they can manage and monitor the process. Only these people are allowed to have access to these reports.

• Synchronizing visibility in DeltaMaster and access in the database
  Different rights apply in the database so that each sales representative can only access the data of their own customer base. By contrast, the Head of Sales can view all areas as well as the aggregated values. There is a report for each region in the report list. If someone opens the report of a region without having rights to this region in the database, the report remains empty, although it is still displayed in the report list. That is why it may be a good idea to reproduce the different rights from the database in the reports. (This situation often occurs if a report list contains a large number of static reports with an identical structure in which various members of the same dimension are applied across the board, for example all regions or branches. In these cases, it is often easier to use just one report but to structure it in such a way that it is dynamically dependent on the current user, instead of managing a large number of rights for a large number of reports.)

• Developing, testing, and approving reports
  A report editor is working on new reports for an existing application, but does not want to make them available to other users until all the finer points have been resolved. Until then, the reports remain in a “working folder”, which is visible to report editors only. To make the report available to pilot users and ultimately the general public, it is sufficient to define correspond-ding rights or simply move the report to a folder to which suitable rights already apply.

Simple protection against unwanted queries can also be achieved through the resources in Delta-Master alone: Presentation Mode is the only mode available to users who are classified as report recipients. In turn, this mode can be restricted by the filter context in such a way that only highly specific data can be retrieved. However, this obviously only applies to DeltaMaster, not to other query tools. There¬fore, when it comes to insurmountable access control that also protects against malicious and technically adept users, the database is the first line of defense.

Streamlined management apparatus

Two tools are available for managing DeltaMaster rights: DeltaMaster Role Management and DeltaMaster itself. The respective tasks are clearly delimited and facilitate the division of work between the IT department and the business department, as well as within the specialist department.

Rights for applications

DeltaMaster Role Management (DeltaMaster 5: Repository GUI) relates to applications and user groups. This tool is used to assign users to groups, activate the applications that are meant to be available to a user group, and stipulate the role in which the group can work with this application, i.e. the scope of functions that DeltaMaster offers them.

Report Recipients can use the application in Presentation Mode only, while Report Editors can also use it in Modification Mode; Application Administrators manage access rights. The screenshot shows that the “Gross Margin” application is activated for the “Sales” user group and that this group can access the application as Report Recipients. Other (or no) roles can be set for the “Administrator” and “Controlling” user groups.

If DeltaMaster is to apply rights within an application as well, activate the corresponding check box in the Files section. This makes it possible also to set rights for the reports and folders in this application. If the option is not activated, a simplified rights concept comes into effect for this application: User groups can be associated with the entire application in predefined roles (Report Recipient, Report Editor, Application Administrator, etc.).

If rights are to be changed and saved in an application, open the application via the options dialog box (context menu of a tile on the dashboard) and additionally with exclusive write access. In DeltaMaster 6, this access is also granted subsequently if you switch to Modification Mode in the already open application and no-one else already has exclusive write access. If you are a member of multiple groups, go to the Options dialog box and select the group you intend to work as a member of.

Rights in applications

Directly in DeltaMaster, in the Windows client, set the rights that apply “within” the application, mainly for reports and folders. To do this, it is necessary to grant rights, as described above, and to have sufficient rights, for example because you are opening the application as the Application Administrator or have been given appropriate permission as a Report Editor.

When you edit in Modification Mode, you reach the rights via the context menu of the respective object: Report rights in the context menu of reports, Folder rights in the context menu of folders, and rights for the entire report list in the context menu of the Reports heading. In addition, the rights can be defined for the application in the application menu (top left, ).

The rights for the selected report or folder are displayed in a dialog box (see the following screenshot), separated according to user group, and can be edited there if you have the corresponding permission.

Entries in brackets arise from inheritance (passing on), and those without brackets are set directly for the relevant object. Entries written in gray cannot be changed. This is always the case when there is no permission to grant rights, and when there are user groups with the role of Application Administrator (no rights can be taken away from them).

The following Rights can be set:

• All: Groups together all other rights.

• Display: Relates to the display in the report list. If this right is denied, DeltaMaster does not display the report or folder to these users. The report does not exist for the search function either, and links to this report are not available.

• Editing: Relates to the behavior of DeltaMaster in Modification Mode. If this right is denied but display is permitted, DeltaMaster behaves in Modification Mode in the same way as in Presentation Mode. For example, the structure and properties of Graphical Tables cannot be changed, and saving of the report is not possible.

• Right Management: Relates to the setting of these particular rights. This allows delegation of the administrative tasks.

If you pass on the Assignment Mode, the settings are also applied to the contained reports and to (sub)folders. Passing on is not possible for reports.

Essential condition: Repository

To manage rights in DeltaMaster applications, it is necessary to have a central authority that checks which user is working with the system and, on this basis, decides which information and functions are to be offered to the user. This authority is the DeltaMaster Repository, a component for database-supported provision and management of DeltaMaster applications, rather than in the form of the familiar DAS files. No permission management is possible with these; only the Repository can do this. A general overview of the properties and tasks of the Repository can be found in DeltaMaster clicks! 01/2015.

Know what you’re doing before you do it

Many issues of clicks! end with an invitation simply to try it out yourself. Rights are an exception – there are reasons why only a few people in the company are entrusted with rights management. Although you cannot lock yourself out (DeltaMaster would warn against this), many and diverse interactions have to be borne in mind, and the more detailed the concept, the more interactions there are. As is so often the case, the simple solutions are the best. Just think of the database. In DeltaMaster, rights at application level are often enough – who is a Report Recipient in which application, who is a Report Editor, who doesn’t need to see them at all? If more detail is required, use a top-down approach. And this last tip is always useful: If there’s anything we can do for you, get in touch with us!