| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
General kOOL conceptsAccess rightsEach user can have a single module available or not. This can be checked with the function
If the second parameter is not given the module will be checked for the currently logged in user.
Each module can have 4 different access levels numbered from 1 to 4. 0 means no access rights at all. The access rights for a single module for a user can be access through the function
The second parameter may be omitted to get the access rights for the currently logged in user. After calling this function the global array $access will be filled with $access[$module]['ALL'], $access[$module]['MAX'] and $access[$module][$id] for each group (reservation item, event group, account etc). They all will contain a value between 0 and 4 where ALL will contain the ALL rights, MAX the maximum value over all single groups. If you only need the ALL and/or MAX values you may also call
This function may be a little faster as it doesn't apply all the group rights. AJAXAll the AJAX functions are contained in /inc/js-ajax.inc, so you just have to include this in MODULE/index.php. With createRequestObject() an XMLHttpRequest object will be created which can be used to send requests back to the server with the function sendReq():
The functions called via AJAX for the different modules are stored in MODULE/inc/ajax.php. The first thing is to check for a valid session id passed to the server. This session is being restored for the duration of this php script to be able to check access rights, then the demanded action will be executed. Usually this script generates the necessary html code directly which will be passed to the javascript function do_element. This function expects the following string: HTML-ELEMENT@@@HTML-CODE This way the html element with the given id will be replaced with the html code after „@@@“. This makes it possible to refill the main content area „main_content“ with new content e.g. You can also have two or three elements replaced by new html code at once by just appending more of the above elements: HTML-ELEMENT@@@HTML-CODE@@@HTML-ELEMENT@@@HTML-CODE Template for listsAll the list views in kOOL are done by the template ko_list.tpl or ko_list2.tpl. ko_list.tpl is the older version where lists where done mostly manually. This method is now deprecated. The new way is by using ko_list2.tpl which is accessed through the class kOOL_listview. Some of this class' methods are described in the following table. For a full reference check the source file in inc/class.kOOL_listview.php. Example code to render a list is shown just below this table. But it might be best to check the kOOL source to find real life examples.
Example code to render a list with class.kOOL_listview
Template for formsMost of the forms in kOOL are rendered through the template ko_formular.tpl. This can either be done through the function ko_multiedit_formular() which renders the form according to the definitions in KOTA or by manually defining an array with all the necessary information about the form. It is also possible to mix these two methods to manually extend a form defined by KOTA to add other form elements. See the form to enter new reservations for an example.
The following table shows the available form elements:
Settings vs userprefsTwo different kinds of settings exist in kOOL. The settings are globally and the userprefs are only valid for a single user. The settings can usually only be changed by an admin user.
Settings are only updated in the database, new ones have to be added manually. This makes the contents of the table ko_settings the ultimate reference for the available settings. The userprefs are generated on demand for every user that sets them.
In some occasions there are default values stored as a setting that can be overwritten by a userpref. When a new login is created there are some userprefs that are created as well. These values can be defined in /lib/inc/ko.inc or in /web/config/ko-config.php, depending on whether they should be server- or only installation-wide. The submenus play a special role among the userprefs as they are generated automatically on creation of a new login according to the available modules. The available submenus per module are stored in /lib/inc/submenu.inc.
The following table shows the settings from ko_settings:
Session variablesSettings about the current session are stored in session variables. Some of them get stored in userprefs on change so they will be the same when the user logs in again. Obviously their is information about the currently logged in user stored in the session as well.
This table shows the most important session variables:
MultieditingMultiediting allows a user to edit one or more columns of several database entries at once. The necessary form is generated by the function ko_multiedit_formular() and the information about the form elements is taken from KOTA. So if you can't or don't use KOTA for some forms you can still define the columns there, where multiediting should be possible.
In order for the editing icons to appear for a certain column, you must specify them in $KOTA:
For every column in the list view zero, one or several columns from the database may be defined that will be edited in the multiedit form. Several columns might be useful for dates for example to have start and enddate in the same form.
If a user clicks on a multiedit icon the action „multiedit“ is issued. So there must be code to catch this action and to read in the selected rows and columns and pass them to the function ko_multiedit_formular().
On submission of the form the action „submit_multiedit“ is issued which must be caught again in MODULE/index.php. You only have to check the access rights and call the function kota_submit_multiedit() to store the submittted values.
To raise the level of security for the multiedit action, a hash is generated with the columns and rows to be edited, which will be checked against the submitted values.
The same functionality may also be used for normal forms, where ko_multiedit_formular() takes a forth parameter which contains some form_data like the value for the form's title, the submit button's text, the cancel action and the submit action. Installation specific configurations: ko-config.phpFor a new installation of kOOL the default ko-config.php will be copied from /lib/install/default/config where most of the values are still empty. With the webbased installation most of these values can be set graphically but may be edited at any later point in time.
The following table shows the available options:
At the end of ko-config.php the file config/leute_formular.inc is included which defines the layout of the form for addresses. This file can be edited in the tools module. Support for different languagesMost parts of kOOL are ready to be used in different languages. In /inc/ko.inc the file /inc/lang.inc gets included where most of the logic behind this is stored:
The localized strings for the different languages are stored in single files /locallang/locallang.XY.php and can be edited in the tools module. It is possible to add a file locallang.XY_ZZ.php where ZZ is the region code of the country XY (e.g. en_US, or de_CH). This region file will be included after the main file for this language, so you can use this file to override language settings for this region which are different then they are set in the default language file.
To get a localized string in PHP the function getLL() may be used. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|