Users and Authorisations
Table of Contents
- 1 Introduction
- 2 User (USE)
- 3 User groups (BEN)
- 4 Menu authorisations (BENMEN)
- 5 User Group Authorisations (BENDEF)
- 5.1 Maintenance of User Groups
- 5.2 Maintenance of the Authorisations per User Group
- 5.3 Export
- 5.4 Granting Authorisations with the Wizard
- 5.5 Assurance of the Efficiency of the Authorisation Settings
- 6 Object and Period Authorisations (BENOBJ, BENABR)
- 7 Company Startup Data+Authorization (VORADMIN)
- 8 Change Logs (LOG)
1 Introduction
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.
2 User (USE)
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
- by mouse click on the star icon in the tool bar or
- by double mouse click in the (empty) list.
Modifications for an existing user can be performed
- by selection of the line and mouse click on the pencil icon in the context menu or
- by double mouse click on the respective line.
Here entries in the following fields are necessary/possible:
- User:
- User name that is used in the program, e.g. to enter the modification user.
- User name for login (Logon ID):
- User name to log-on to IDL Konsis. The logon-ID may differ from the name, especially if the name is longer than 8 characters.
- Last name / First name / Telephone No / e-mail:
- Serve for further documentation and specification; these data are not used in IDL Konsis.
- Language:
- In this field you determine in which language application-specific objects (e.g. account descriptions) are to be displayed preferentially. Unlike the user interface language (for menus, prompt texts and column headers) customer-specific languages are possible here.
- Template:
- A user with this attribute does not ohn a Logon ID and must not be used for login, too. Template users and their start-up data serve as a template for automatically created users in IDL.KONSIS who had been defined in the Active Directory only before.
- User group for menu authorisations:
- Specifies a user group to define menu authorisations (authorisations for functions) for users. Without this specification the user can log-on but cannot start any application.
- User group for data objects:
- Specifies a user group to control the access to certain data objects. This specification only takes effect in combination with the definition of object authorisations (see below) as well as the user-defined authorisation control within the startup data (see below).
- User ID for Datamart:
- For users of the interface IDL Datamart to IDL.DESIGNER here on demand a deviating login ID can be specified.
- Valid from / valid until:
- The validity of a user login can be limited in time by entries in these fields.
- Licence user type KONSIS:
- 'A' = Admin user (administration user only); 'F' = Full user (full functionality); 'L' = Light user (company fincancial statements only); 'V' = Viewer user (display / reporting)
- Licence user type FORECAST:
- 'F' = Full user (full functionality); 'L' = Light user (data entry / reporting)
- Licence user type XLSLINK:
- 'F' = Full user (full functionality)
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".
3 User groups (BEN)
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:
- IDLADMIN / IDLWINAD
- All rights in the projects IDL Konsis
- IDLEA / IDLWINEA
- All rights in the applications for company financial statements (EA incl. all related applications)
- IDLEE / IDLWINEE
- Rights for release (lock) of company financial statements
- IDLKON / IDLWIN
- All standard rights in IDL Konsis (master data, company and group statement); read authorisation for system administration
- IDLKON1 / IDLWIN1
- All rights in IDL Konsis (company and group statement); read authorisation for master data and system administration
- IDLVIEW / IDLWINVW
- All rights in IDL Konsis read only, e.g. for auditors
- IDLSYS / IDLWINSA
- System administrator in IDL Konsis; full rights for system administration but no rights for master data, company and group statements
- IDLNOAUUT
- No rights in IDL Konsis, but usage of web services for ad-hoc and web reporting (IDL.DESIGNER)
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
- by mouse click on the star icon in the tool bar or the pencil icon in the context menu, respectively, or
- by double mouse click on the selected object or the (empty) table, respectively,
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).
4 Menu authorisations (BENMEN)
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:
- 0 only for customer specific user groups: Withdrawal of the authorisations granted for the reference group
- 1 Standard authorisation
- 2 Standard authorisation + specials
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:
- Selection according to an unambiguous user group and copying to another user group
- Selection according to an unambiguous menu ID and copying to another menu ID
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'.
5 User Group Authorisations (BENDEF)
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.
5.1 Maintenance of User Groups
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:
- [Insert new user group]: When clicking on the star icon a wizard opens for definition of a new user group.
- [Change user group]: When clicking on the pencil icon a wizard opens for modification of the selected user group.
- [Save]: When clicking on the disc icon all performed changes are stored.
- [Close]: You can close the user group currently opened by a click on the X icon.
- [Print] and [Print preview] incl. pdf export by a mouse click on the printer icon in the tool bar
- [Export to Excel] by a click on the "xls" icon
- [Help]: Display of the help text by a mouse click on the "?" icon
- [Refresh]: Refresh of the user group table (icon with two opposite arrows)
- [Display]: When clicking on the eye icon or a double clicking on a table line the authorisation tables for data objects for the selected user group are displayed in registry tabs.
- [Edit help text]: On demand you can supplement comments on the user group here (page icon with "i" and pencil).
- [View help text]: Here you can display comments on the user group defined before (page icon with "i").
- [Filter]: The filter line can be activated or deactivated (funnel icon).
- [Delete all filter entries]: Here all entries in the filter line are removed (stroked funnel).
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.
5.2 Maintenance of the Authorisations per User Group
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:
- Groups (KTK)
- Companies (GES)
- Periods (ABR)
- Facts (FAC)
- Charts of accounts / controlling objects (KTP)
- Charts of positions (POP)
- Report idents (RID)
As far as IDL.FORECAST is licensed you can authorise
- scenarios
- rule templates
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:
- Grant only read authorisation for the object
- Withdraw all authorisations from the object
- Grant all authorisations for the object
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:
- [Insert new object authorisation] (star icon): The wizard opens for definition of a new object authorisation.
- [Modify object authorisation] (pencil icon): The wizard opens for modification of the authorisation of the selected object.
- [Filter]: The filter line can be activated or deactivated (funnel icon).
- [Delete all filter entries]: Here all entries in the filter line are removed (stroked funnel).
The wizard for granting of authorisations consists of two pages. The first page serves for the entry of the object while the second page allows for granting the authorisations for the actions
- Display
- Update
- Insert
- Delete
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 licensed the actions
- Display
- Update
- Delete
are offered and for rule templates, in addition, the action
- Execute.
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.
5.3 Export
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.
5.4 Granting Authorisations with the Wizard
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.
5.5 Assurance of the Efficiency of the Authorisation Settings
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.
6 Object and Period Authorisations (BENOBJ, BENABR)
In addition, for display and maintenance of the data authorisations of user groups the applications "Object authorisations" (BENOBJ) and "Period 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.
7 Company Startup Data+Authorization (VORADMIN)
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.
7.1 Data for First Startup-Data
After IDL Konsis has been installed for the first time no entries are present in the table VOR or VORADMIN, respectively, providing that many of the IDL Konsis applications cannot be started because of missing authorisation definitions. However, the first startup-data record requires 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.
8 Change Logs (LOG)
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:
- User: USELOG
- Startup data: VORLOG
- Menu authorisations: BENMENLOG
- Data object authorisations (except for periods): BENOBJLOG
- Period authorisations: BENABRLOG
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 modifying 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.