In IDL Konsis you can delimit authorisations of individual users with the help of the authorisation concept. Below the necessary menu items are described. Maintaining the data mentioned herein is part of the system administration and should only be enabled for users with administrator rights. In the IDL Konsis default scope of delivery only the user groups IDLADMIN and IDLSYS have the required modification rights.
This application serves to maintain all users that are able to work with IDL Konsis. This requires that the system administrator authorizes the user for the IDL Konsis-database or as network user.
Allocating a user group in Menu authorizations you determine which functions a user is allowed to carry out.
Installing IDL Konsis the user IDLADMIN is defined by default, all other users have to be created.
For this purpose you switch to the single record application accessible
Modifications for an existing user can be performed
Here entries in the following fields are necessary/possible:
In case that the authentication check is not performed by the operating system (Windows, Active Directory) or the database system but rather by the IDL.KONSIS.FORECAST database (setting in the configuration programm of the IDL.KONSIS.FORECAST Application Server) the application USE shows additional entry fields. These are described in the documentation "Internal Password".
This overview displays the defined user groups (= authorisation groups). User groups serve to assign authorisations for functions (= menu authorisations, see application BENMEN) and data objects (see application BENDEF).
The installation of meta data in case of release changes provide the following user groups for menu authorisations and menu allocations in IDL Konsis:
User groups whose names start with "IDL" are reserved for maintenance by IDL. Customer-defined groups must not start with "IDL".
The single record application accessible
serves for the entry of new user groups and their modifications.
Each user group has to be classified whether it is a user group for menu authorisations, a user group for data authorisations, or both. Menu authorisations (BENMEN) can be granted only for user groups for menu items. Object authorisations (BENDEF) can be granted only for user groups for data.
Customer defined groups whose menu authorizations only slightly differ from an IDL standard can refer to an IDL group. When referring to an IDL group only the differences to the standard authorisation group have to be maintained. This way usually adaptions due to new or dropped menu items during a release update are saved. Further information please find in chapter Menu authorizations (BENMEN).
You can add a longer explanation to a user group. You can display or change these texts with the options <Display help-text> (book icon) and < Edit help-text> (book icon with pencil).
The overview displays all menu items a user group is authorised to use in alphabetical order. In addition to every menu item currently assigned action rights are displayed. The action rights for display, update, insert, delete and copy are distinguished.
The authorisation for option <Display> is compulsory at least for the user groups beginning with "IDL" as the menu authorisation must at least comprise the display rights; for the customer specific user groups it can be '0', too. The authorisation for the other actions is optional. The following entries are possible in all authorisation attributes:
The differences between standard authorisation and Standard authorisation + specials is application-specific. You should only assign standard authorization + specials in exceptional cases.
With <Copy> you can copy selected lines to modified keys. The following scenarios are possible:
If you enter "L" in the selection field <CopyOption> the authorisations for update, insert, delete and copy are not copied.
Menu authorisations for user groups starting with "IDL" are maintained by IDL and are updated with every new release. Authorisations for client-defined user groups must be maintained by the clients themselves. New menu-IDs, possibly to be authorised, are stated in respective release documentation <Release News>. IDL authorisations may serve as templates.
As this could be very time-consuming, customer-defined user groups can refer to an IDL standard group. Due to the reference all menu authorisations valid for the standard group are adopted by the customer-defined group. Only the differences have to be maintained in the application BENMEN. Further authorisations can as well be maintained as restrictions. Additional rights are defined by authorisations with level '1', restrictions by entries with authorisation level '0'.
You can provide for the maintenance of object authorisations in the application "User group authorisations" (BENDEF) which allows for the definition of the authorisation groups themselves as well as for the grant or withdrawal of authorisations for the different master data objects in one application.
When calling the application BENDEF all defined user groups are displayed in a table. The following standard functions are available in the action menu, the tool bars or in the context menu:
You can also order the table by the values of all columns. For this purpose you have to click on the tiny arrows in the header line which become visible if the cursor is positioned there. You can access the table for menu authorisations (BENMEN) using context menu (right mouse key) for a table line.
After selection of a user group for data objects in the leading table and a double mouse click or the context menu item "Open" (eye icon) tables per object type are displayed as registry tabs where object authorisations can be granted. The title of the registry tabs show the number of respectively authorised objects. The leading table is faded out automatically. The key of the selected user group is displayed in the navigation bar. You can authorise objects of the following types:
As far as IDL.FORECAST is licenced you can authorise
in addition.
Another registry tab "Overview over all object authorisations" comprehends the authorised objects except for periods and the IDL.FORECAST objects and amongst others serves for the export of these data into a file.
The tables per object type display the authorised objects at first followed by all objects not authorised. With the aid of the context menu (right mouse key) the following actions for control of the authorisations can be executed:
With aid of the wizard accessible form the tool bar it is possible to grant the authorisation more differentiated. The following functions can be invoked via the tool bars:
The wizard for granting of authorisations consists of two pages. The first page serves for the entry of the object while the second pages allows for granting the authorisations for the actions
by selecting the check box or for withdrawal of the authorisations by removing the selection of the check box.
As far as IDL.FORECAST is licenced the actions
are offered and for rule templates, in addition, the action
The object authorisation for copying is guaranteed by checks of the authorisation for display of the source key and for insert of the destination key.
The export of the different areas is supported by the export button of the tool bar. The export dialogue determines which area is to be exported. Available are the areas 'User groups', 'Object authorisations' and 'Period authorisations'. You have to select the desired area in the radio button group on the right-hand side. Selections in the table are considered. If lines are selected in only one table they are exported. Tables without selection are only then (completely) exported if no selection at all has been performed.
The navigation between the pages of the wizards is performed using the buttons <Next> and <Back> in the bottom of the wizard pages or via the page directory (navigation bar) displayed on the left-hand side. The page directory displays with an icon whether the entries on the pages are correct (green hook) or faulty (red stop sign). The button <Finish> is contained on every page, however, it is deactivated as long as the data record is inconsistent or incomplete. If the record is correct <Finish> becomes active independent from the actual page. The button <Next> becomes only active if the entries on the respective page are consistent and complete.
You can determine from the entry of the last change whether an authorisation for an object is already present.
The authorisations on rule templates can be granted to the folders defined in the PLAN application, too. The authorisations are inherited by the sub-ordinate sub-folders and rule templates if not specified otherwise for the sub-ordinate levels. Inherited authorisations are represented by a grey hook. The inherited authorisations can be modified individually.
In integrated applications like REPDEF, POP or BENDEF the insert and delete authorisations are applied only to the authorised object itself. The update authorisation is sufficient for insert or deletion of sub-ordinate objects. However, applications like REPZEI or POS apply the authorisations for insert and delete to sub-ordinate objects (e.g. report lines of a report ID, positions of a chart of positions), too.
A correct setting of the authorisation flags per object type per user in the application VORADMIN (Company startup data+authorization, see below) is prerequisite for the object authorisations to become effective. As far as a flag is set to '2' or '3' the applications checks whether corresponding object auhtorisations for treatment are present.
In addition, for display and maintenance of the data authorisations of user groups the applications "Object authorisations" (BENOBJ) and "Perid authorisations" (BENABR) are available preliminarily, too, including the associated single record applications. Basicly these applications are operated like the application "Menu authorisations" (BENMEN, see above).
In comparison to the application BENDEF BENOBJ and BENABR offer the ability to display the authorisations of several user groups in one view and to copy data between them.
The application VORADMIN first and foremost serves to gather new users, who can only work with IDL Konsis after having been entered here.
As we have already mentioned above, the access to certain data objects linked to the applications BENOBJ and BENABR is only enabled if the respective settings are already made in the settings in VORADMIN for the respective user.
The additional parameter fields in the screen below are relevant for the key fields Group/subgroup, Company, Period, Fact, Chart of positions/accounts as well as Report ID.
You access the single record application (VORADMINE) via the actions <Create new data> and <Edit data>. The following entry options for overwrite and authorisation protection are available there (in the entry fields for this purpose after the preselected objects):
| Key | Authorisation |
|---|---|
| '0' for group, company, period and fact | Input according to VOR only |
| '0' for charts of positions and accounts / controlling objects and report ID | No changes permitted |
| '1' | Arbitrary entries and changes are permitted |
| '2' | Authorisation according to application BENDEF |
| '3' for periods | Same as '2' with additional right to create new reports for closed periods once |
| '3' for charts of accounts / controlling objects | Same as '2' without the right to change allocations to the group chart |
| '3' for companies | Same as '2' whereas in company master data only the chart of controlling objects can be changed |
Setting the overwrite option to '0', you can make sure that the applications do not accept entries deviating from the settings in VOR. So you avoid erroneous entries under the wrong key concept during the current session. The overwrite option '1' on the other hand enables quick navigation with changing keys.
The fields Group currency and Parallel currency can only be set and modified in application VORADMIN. They are used as currency codes for new data records, in case no group/subgroup is stated. These fields as well as the group chart are checked against the entries for the group/subgroup stated above.
Every user can administer the other entry fields in the application Startup data (VOR) on his own, too.
If the user language is modified in an application for maintenance of the startup data (VOR, VORADMIN) then it is automatically adapted in the table "User" (USE), too.
After IDL Konsis has been installed for the first time no entries are present in'the table VOR or VORADMIN, respectivley, providing that many of the IDL Konsis applications cannot be started because of missing authorisation definitions. However, the first startup-data record rquires the definition of a set of master data (e.g. company, period, fact) for entry into the startup-data. The definition of these master data is complicated due to several dependencies.
The application "Data for first startup-data" (VORINITE) serves for simplification of this process. This application is started alternately to the regular single record application (VORADMINE) if you call the associated single record application from the list VORADMIN and no entries are present in this table yet.
The map displayed ba VORINITE contains entry fields for all master data required for a first startup data record. In many cases these fields are predefined wit a proposal (e.g. group = 'WELT', company = '001'). These data can be kept or modified on demand. They later can be deleted, too, after the proper data have been provided.
The button <Insert> provides for the generation of the master data thus defined as well as for a startup-data record for the user logged in providing that subsequently all IDL Konsis applications can be called without problems.
The module 'Data change logging' is an additional module by user's expense which you can order on demand.
For documentation and analysis of changes on data described in this guide there are overview functions for the following tables:
The list applications display the log records, allow for a selection by the important attributes (like in the corresponding master data overview) and, in addition, requests for the kind (insert, update, delete) and timestamp of the modification. Thus all modifications after a certain timestamp can be selected as well as the state of the original table at a given timestamp.
For activation of the logging you have to enter the respective table number (or select it from the drop down box) in the application "Control of data change logging" (LOG) and select the action "Activate data change logging". No other users should be connected with the database when activating the logging. Subsequently all modifications on this table are logged in the log table.
Then modifiying the user language in the application VOR or VORADMIN this modification is logged as a modification of the table USE, too, although no active modification has been entered there.