Last release: 8.2 Lerici (released Dec 19, 2017). This documentation
is about the 8.2 Lerici release, if you need the documentation for a
previous release please read the documentation file included in each
downloaded package; the features described in this file refers to DaDaBIK
Enterprise Version, some of these features might be not available for
DaDaBIK Pro. Check the features
comparison for further details.
DaDaBIK is a no-code / low-code development platform and a Web application builder written in PHP. It allows you to easily create
a highly customizable database front-end or a database-based Web application
without coding. You can use it to create in a few minutes a very basic CRUD
(Create, Read, Update, Delete) database front-end or to develop a more
sophisticated database application. DaDaBIK was one of the very first RAD
PHP tools focused on database applications (first version released in 2001)
and it is still one of the most popular.
DaDaBIK uses the PDO
extension in order to support as many DBMSs as possible, at the moment it
officially supports MySQL, PostgreSQL and SQLite.
Features include:
Forms generation/customization
Datagrid generation/customization
Datagrid HTML template customization
Reports generation:
simple reports, generated in a few click (choose chart type, how to
aggregate data, what data to display )
advanced reports, using custom SQL code
15 field types, including lookup fields
Calculated fields
Responsive front-end
File uploading
Master/detail views
Duplication checking
Authentication
Granular permissions
Integration with external user/group/password lists
Record locking
Record ownership authorizations
CSV export
Email alerts
SQL logging
Pre-defined/custom formatting rules
Pre-defined/custom validation rules
Custom pages in PHP or simple HTML
Three graphic themes, two page layouts (left menu, top menu)
Graphic layout customizable through a documented CSS file
DaDaBIK differs from software like PHPMyAdmin: it has not been created to
offer the complete administration of a database, but rather to allow the
creation of a customizable and user friendly database application. The
target of a DaDaBIK application can be the final user instead of a DB
administrator.
DaDaBIK is a Web application written in PHP so you need a Web server
(for example Apache),
the PHP language and a
DBMS (MySQL, PostgreSQL
or SQLite are
supported). If you are building your Web application on-line, your
hosting provider has probably everything you need already set up. If
you want to use DaDaBIK on your local computer and you don't know what
a Web server is or you don't know how to install it you can download
and install an application like MAMP,
which automatically installs on your computer Apache, PHP and MySQL.
Some more details:
PHP
version >= 5.3.11 (PHP 7 is OK!). DaDaBIK can also work
with PHP >= 5.2 but contact us for details.
with the mbstring extension enabled if you need to handle
Multibyte character
with LDAP support enabled if you need LDAP authentication
MySQL
version >= 5.0 (PDO_MYSQL PHP driver required)
PostgreSQL
version >= 7.4 (PDO_PGSQL PHP driver required)
SQLite
version >= 3
A pre-existent database (MySQL,
PostgreSQL
or SQLite)
with AT LEAST ONE table, with DaDaBIK you create database
applications, not the database itself. For MySQL, a great free tool to
crate databases is MySQL
workbench
For MySQL, all the database tables must be InnoDB
if you want to correctly handle transactions; DaDaBIK can also work
with MyISAM tables but it cannot guarantee that transactions are
processed correctly.
To prevent SQL injection vulnerabilities you have to follow these
rules:
for PostgreSQL, standard_conforming_strings must be ON (if you
have a recent PostgreSQL, it should be ON by default)
for SQLite, the database must be in UTF8. UTF8 is the character
set strongly recommended also for MySQL and PostgreSQL.
DaDABIK works with any modern browser, if you use Internet Explorer,
cascade listboxes and custom required features need at least Internet
Explorer 8.
DaDaBIK is not free software, it is released under the DaDaBIK license
(see dadabik_license.txt) and its use requires to purchase a regular
license from the Website www.dadabik.com. It is, however, open source in
the sense that, after buying a license, you get the full source code of
the software.
On our YouTube channel you can find a beginner video tutorial and some more advanced tutorials in the series "How to create a Web Application with DaDaBIK"
Copy all the files contained in the program_files
folder in a directory of your choice under your Web server, e.g.
"my_dadabik_directory"
Open the file /include/config.php with a plain text editor and
edit it (specify at least the REQUIRED parameters)
Run the file http://yoursite.com/my_dadabik_directory/install.php
to install DaDaBIK
Open the file http://yoursite.com/my_dadabik_directory/index.php
in your browser to start using DaDaBIK.
Congratulations, you have just created your fist DaDaBIK application
based on tables and views contained in the database $db_name. You can
customize the application via http://yoursite.com/my_dadabik_directory/admin.php.
Remember that you must set a primary key for each table managed with
DaDaBIK if you want to delete and modify records; other DaDaBIK features
(such as duplication checking and email alerts) also require a primary
key.
You can upgrade to the latest version
without loosing your application's configuration if you are running at
least version 5.0:
Replace all the old files with the new ones
keep your upload folder if you want to save the uploaded files, but
BE SURE the folder is protected, see Security section
keep the custom_functions.php file if you have edited it
keep your custom language files if you have created any
Upgrade the Wordpress plugin in the Wordpress installations where you
have used it (if any)
Update your new /include/config.php file using your old
configuration settings. Don't substitute the new file with the old one
but MANUALLY edit the new file according to your old configuration. A
good practice is to keep note of the few parameters you have changed
respect to the default config.php file.
Run the file http://your_host/your_dir/upgrade.php and follow
the instructions to upgrade DaDaBIK
Please note that, due to SQLite limitations, the upgrade script is
available just for MySQL and PostgreSQL.
Upgrade from BASIC to PRO/ENTERPRISE or from
PRO to ENTERPRISE
It is not possible to upgrade from DaDaBIK BASIC to PRO/ENTERPRISE
keeping your application settings.
You can, instead, upgrade from PRO to ENTERPRISE following the same
instructions of the previous paragraph ("Upgrade from previous version");
this also apply if the version number is the same (e.g. you want to
upgrade from DaDaBIK 7.3 Pro to DaDaBIK 7.3 ENTERPRISE).
How to configure and customize a DaDaBIK
application
The configuration of DaDaBIK can be managed at two different
levels.
Some general configuration parameters can be directly set from the file /include/config.php,
just by opening it with a plain text editor and editing it. The file is
self-explanatory. At that level you can, for example, set the database you
want to manage with DaDaBIK or configure some DaDaBIK features (e.g.
authentication, upload, email notices, language,...).
For a more analytic tuning you are supposed to use the admin area http://your_host/your_dir/admin.php.
At this level you can:
Choose the pages that compose your applications; a page in DaDaBIK
application can consist of:
a set of search/insert/edit forms, results grid and reporting tools
related to a database table or a database view; DaDaBIK automatically
creates this set for each table/view you have in your database, trying
to guess the correct settings according to your schema but you can
customize it (see "Configure your datagrids" and "Configure your
forms" later)
a custom HTML page (you write your custom HTML code)
a custom PHP page (you write your custom PHP code)
a link to an internal or external URL
Configure your data grids, choosing between a classic tabular data
grid view (default) or a custom results page completely customizable
using HTML templates.
Configure your forms: this is the core of a DaDaBIK application
configuration; here, for each field, you can set
if the field must be included or not in search/insert/update forms
and data grids
its label
its content (e.g. numeric, alphabetic, e-mail, url...)
the HTML input type (e.g. textbox, dropdown menu...)
the possible values, also driven from another table ("foreign key"
lookup support)
how the fields are arranged in each form
custom formatting and validation functions
requiredness
search operators
and more...
Set the permissions (see the Permissions
sections for more details)
Synchronize your applications if you change the database schema
The admin area is also self-explanatory, so you can read
most of the instructions on how to configure DaDaBIK by clicking on the help
tooltips available in the
admin area itself. That's the reason why this manual is so short,
you will find everything you need about configuration in the admin section.
Here we will only focus on documenting a few typical use cases:
How to configure a drop-down lookup field
How to hide a field from a form
How to manage uploaded file (images and other files) fields
How to configure a master/details view
How to create a pre-filtered results grid
How to create graphic reports
How to create a completely custom page
What is a hook and how to add some PHP custom codes to the DaDaBIK's
workflow
How to use calculated fields
How to share the same database between two or more DaDaBIK
applications
See the related following paragraphs for further details.
Some graphic customization can be done by changing the files /include/header.php
and /include/footer.php and by editing the CSS file /css/styles_screen.css.
In addition, the datagrid HTML templates feature allows you to deeply
customize the appearance of your item results page.
A lookup field is a field whose value is bound to another value in a
source data table. For example let's say you have a table customers
having, among the others, the fields address and city.
Instead of setting the the field city as textbox, you want to provide the
user a drop-down list which takes its values from a table cities having
as fields ID and name. All you have to do is setting
the following values (in the forms configurator), for the field city in
the table customers:
Field type: select_single
Lookup table name: cities
Lookup table primary key field: ID
Lookup table linked fields: name
Configuring the field in this way, for the field customers.city you save
in your database the ID of the city but you show to your users the name of
the city. Also, you limit the options available to the cities you have in
the table cities. The field customers.city needs to have the same database
type the field cities.ID has, so if the ID is INTEGER, customers.city
needs to be integer as well.
The select_single (drop-down list) is not the only DaDaBIK field
compatible with the lookup approach: you can also use radio buttons, a
list of checkboxes or a drop-down multiple select: all you have to do is
selecting the right DaDaBIK field type: instead of select_single you need,
respectively, select_single_radio, select_multiple_checkbox or
select_multiple_menu.
It's worth mentioning that you are not limited to one linked field, you
can add as many linked fields as you want. Let's say the table cities
contains also the name of the region each city belongs to: cities
(ID, name, region_name); you can add region_name as an
additional linked field so that users will see in the drop-down menu not
only the name of the city but also the name of the relative region.
For additional options related to lookup fields, including cascade
fields, filtered lookup and the possibility
to add a new item to a list on the fly, please refer to
the in-line helps available for each
parameter in forms configurator.
How to hide a field from a form
Hiding a field from a form or from the results grid is very simple: let's
say you have a field salary in a table employees and
you want to show the field only to some of your users, the users belonging
to the group human resources. From the permissions menu of the
admin section, choose employees as a table and, for each group,
set the permissions: you probably want to set, for all groups except from
admin and human resources, the permissions to NO for
all the operations: RESULTS, EDIT, CREATE, DETAILS, QUICK SEARCH and
SEARCH; the effect is that DaDaBIK will never show the field, the field
will be excluded from the results grid, from the edit form, from the
"create new" form, from the details page, from the quick search form (the
boxes on the top of the results grid) and from the search form.
Please note that normally if you have a field which is auto-increment,
you need to hide it form the CREATE form since the value needs to be
assigned automatically from your DBMS (MySQL, PostrgreSQL, SQLite) and not
entered by the user.
The permissions menu is used to set the presence of fields, as explained
above, only if granular permissions are enabled (parameter
$enable_granular_permissions in config.php), which is the default
settings. If granular permissions are disabled, you can choose to hide a
field directly from the forms configurator, in this case you set the
presence of a field globally, for all the users.
How to manage uploaded file (images and other files) fields
DaDaBIK has two file field types, generic_file and image_file; both the
field types generate in insert/edit forms an upload control that allows
users to upload files. The difference between the generic_file and the
image_file lies in how the file is displayed in the results grid and in
the details page: for image_file fields, the actual image is displayed
(using the img html tag), for generic_file fields, a link to the file is
displayed.
To use the upload function you have to set the proper $upload_directory
in config.php, the files uploaded, in fact, are not stored directly in the
database but in the file system, the database stores just a reference to
the file. From config.php you can also set the upload allowed file
extensions and the size of the image thumbnails to show in results grid
and details page. Please note that DaDaBIK automatically assignes a unique file name to the file the user uploads.
How to create a Master/Details view (subforms)
A Master/Details view (also called subform) is an edit form (or a details
page) that shows not only the details of a records but also one or more
result grids displaying related records from other tables.
A typical example is the representation of an invoice (or an order):
Invoice n. 1 date 08/04/2017
Customer Bob Smith
Description
Product
Quantity
Price
iPhone 7
1
700
USB Key 2
20
Total: 740
You probably represent the information using two tables:
invoices
id_invoice
number_invoice
customer_invoice
date_invoice
1
1
Bob Smith
08/04/2017
invoice_items
id_invoice_item
id_invoice
product_invoice_item
quantity_invoice_item
price_invoice_item
1
1
iPhone7
1
700
2
1
USB Key
2
20
(you probably want to store information related to products in a third
table but let's keep the example simple)
The best way to represent this data in a DaDaBIK application is to create a
master/details view with invoices and invoice_items: from the form
configurator select id_invoice (the primary key of the invoices table) and
add invoice_items as master/details, selecting id_invoice as foreign
key: You can add as many details
tables as you want to the same master.
How to create a pre-filtered results grid using VIEWS
Sometimes you want to show to your users a pre-filtered version of your
data. Let's say for example you have a table products containing
a field quantity_product, which stores, for each product, the
quantity you have in your warehouse. If the table products is
installed in DaDaBIK, it can be accessed from a menu item products
and users can also execute search operations over it, for example, through
the search form, they can ask to see only the products having a quantity
value less than 10. If you realize that such query is quite common, you
might want to offer to your users a direct access to the products having a
quantity value less than 10, without forcing them to perform a search
operation every time. You can do this using VIEWS.
A database view, informally, can be defined as a "virtual table" which is
based on a real table; for example we can create a view products_low_stock
based on the table products with this simple SQL statement:
CREATE
VIEW products_low_stock AS SELECT * FROM products where quantity_product
< 10
The view products_low_stock can be installed in DaDaBIK as it was
a normal table and therefore you can assign to it a menu item that allows
users to directly access the products with low stock level in one click,
without performing a search operation. Every time you access the view
products_low_stock, your DBMS implicitly execute the query "SELECT * FROM
products where quantity_product < 10" and provides you with the
up-to-date results.
You can create a database view directly in DaDaBIK, admin section, pages
menu:
For additional information about databaseviews, the Wikipedia entry is
simple and quite informative: https://en.wikipedia.org/wiki/View_(SQL).
A creative use of database views can help you in the process of creating
very complex DaDaBIK applications.
How to create graphic reports
Starting from the results grid of any page based on tables/views you can
create a graphic report; several chart types are available, including bar
charts, line charts, pie charts and doughnut charts.
DaDaBIK provides two types of reports: simple reports and advanced SQL
reports. You can create a simple report in a couple of clicks by selecting
the field you want to put on your X-axis and the field you want to put on
your Y-axis. Normally you want to aggregate data according to a field,
show each group of data on your X-axis and and show some information
related to each group on your Y-axis.
For example you might want to see the age composition of your customers:
in this case you would choose to aggregate data by age and to show, for
each group, the number of customers having that age (selecting the count
option).
A slightly more complicated example: you have a table sales containing,
among the other information, the date of the order and the amount. You
want to see your revenues, month by month. In this case you need to choose
month month - date_order for the X-axis and sum -
amount for the Y-axis.
If you need more freedom, you can use the advanced SQL reports: you can
specify your own SQL query, include a where clause, joining several tables
and so on. The only constraints you have is: the query must be a SELECT
statement where the first element you select will be used for the
X-axis of the graph, the second element for the Y-axis.
Here is an example: let's say we have the following tables:
sales (id_sale, date_sale, customer_sale) - each sale can have several
sale items:
sale_items (id_sale_item, id_sale (FK), id_product FK),
quantity_sale_item) - each sale item refers a sale and a product
we want to show, for each month, the total revenues; here is an example
of custom SQL report for MySQL:
select
date_format(date_sale, "%b"), round(sum(quantity_sale_item*price_product))
from sales inner join sale_items on sales.id_sale = sale_items.id_sale
inner join products on sale_items.id_product = products.id_product group
by month(date_sale)
If you have created a report and you want to easy access it later from the
menu in one click, you can simply copy the URL you see in your browser when
the report is displayed and create a custom page (having type = link) that
points to this URL. Please note that, if the report has been generated after
a search, the search filter is not saved together with the link. If you need
to store a report based on a stable search filter, the best way is to create
a VIEW and generate the report starting from that view.
Hooks
A DaDaBIK hook is a feature that allows you to write some PHP code to be
called under certain circumstances.
DaDaBIK currently supports after insert, before
update, after update and after
delete hooks for each table installed in a DaDaBIK application,
which means that for each table you can enrich the DaDaBIK workflow with
your own code functions, that can be executed:
after an insert operation (after insert hook)
before an update operation (before update hook)
after an update operation (after update hook)
after a delete operation (after delete hook)
Let's say for example that, when a new order is inserted into your orders
management application, you want to automatically update your stock: you
can do it by using a hook; in particular if you store your orders in the orders
table and your products information and quantity available in the products
table, you can add an after insert hook on the table orders
and write the code needed to update the records of the table products.
All your hooks functions must be written in the
/include/custom_functions.php file
Let's say we want to send an email to a specific address when a new
account is inserted in our system: this is a built-in DaDaBIK feature (see
parameter $enable_insert_notice_email_sending in config.php) but let's say
we don't to use the built-in feature and we want to implement it using our
custom code. We could, as in the following example, define an after
insert hook on the table accounts, setting the function that has to
be executed (dadabik_send_notice_after_accounts_insert) and after we can
write the code of the function, that retrieves the name of the account
just inserted and send it via email to a specific address.
mail ('john@mysite.com', 'New account inserted', 'A
new account ('.$row['name_account'].') has been added.');
}
Please note that:
you can use any name for hook functions, but the name MUST start with
dadabik_
if you need to execute operations on the database, you have to add the
global $conn; code line (as in the above example)
the after insert, update and delete hook functions receive as
parameter the value of the primary key field of the record just inserted
(if it is an autoincrement field), updated or deleted; the before update
hook function receives as input the value of the PK of the field in
update and (second parameter of the function) an associative array
containing all the values the user filled in the update form (where the
array element's key is the name of the field). Please note that on
PostgreSQL the after insert hook doesn't fully work (it doesn't receive
the value of the primary key of the record just inserted).
the delete hook doesn't work after a "delete all" operation.
You don't have to worry about transactions in your code: the after
insert, update and delete hook functions are executed inside a
transaction that starts before the insert, update and delete operations
are executed and ends after the hook functions execution; the before
update hook is also inside the same transaction which starts before its
execution.
How to use calculated fields
A calculated field is a form field whose value is not directly
entered by the user but is calculated according to a function.
For example you might have a table products containing the
fields price, tax, total_price and you want the field total_price
to be computed as price + tax. To get this results,
you just need to fill - for the field total_price in forms
configurator - the parameter "Calculated field function", setting the name
of a custom function that will handle the calculation, for example
dadabik_get_total_price. Then you need to write the function's code in
/include/custom_functions.php. Here is an example of the simple
dadabik_get_total_price:
function
dadabik_get_total_price ($params){
// first, check if price and tax are not empty and not
null
if ( $params['price'] !== '' &&
!is_null($params['price']) && $params['tax'] !== '' &&
!is_null($params['tax'])){
return ($params['price'] +
$params['tax']);
}
else{
return NULL;
}
}
The /include/custom_functions.php contains all the instructions to write
these functions correctly.
How to share the same database between two or more DaDaBIK applications
Sometimes you want to build two (or more) different DaDaBIK applications
which works on the same data (i.e. on the same database).
For example you want to build:
A backend/data-entry application, from which you modify/enter data,
accessible only to some people and
A simpler, read-only, publicly available application that users can
access without logging in.
You can do it very easily following these simple rules:
the database name (parameter $db_name) must be the same in all the
config.php files
the $prefix_internal_table parameter needs to be different and UNIQUE
for each application
use the $prefixes_to_exclude parameter to state, for each application,
the prefixes (see previous rule) you have used in the other applications
sharing the same database.
For example, if we have two applications sharing the same database, here
is an example of config.php files
DaDaBIK provides a feature which allows to create in a DaDaBIK
application custom pages running completely custom PHP code, with the only
limitation of some variable naming rules. The feature needs to be enabled
from config.php, setting $enable_custom_php_pages = 1.
DaDaBIK is released together with a Wordpress plug-in which allows to
integrate a DaDaBIK application into a Wordpress site's page.
Furthermore, users authenticated through Wordpress can also be
(optionally) automatically authenticated into DaDaBIK too, without
logging-in again. The Wordpress authentication feature requires that the
DaDABIK application is installed in a subdirectory of the Wordpress site
and that the same users (same username) is available both in Wordpress and
DaDaBIK.
Follow the instruction included in the wordpress_plugin folder to
install and configure the plugin.
Authentication is enabled by default, which means that, in order to use
an application created with DaDaBIK, you have to login. You can disable
authentication by setting $enable_authentication = 0 in /include/config.php;
while this is not recommended, it can be useful if you want to use DaDaBIK
to create a public Web site.
DaDaBIK is released with the following default users:
username: root; password: letizia (this is a user belonging to the
admin group)
username: alfonso; password: letizia (this is a user belonging to the
normal group)
It is strongly recommended to change the default passwords for security
reasons.
Admin users can not only use a DaDaBIK application but also configure it
through the admin area; furthermore, they can add new users/groups and
edit/delete existing ones.
Optionally, you can authenticate your users against an LDAP server.
DaDaBIK has been tested with both Open LDAP and Microsoft Active
Directory.
From /include/config.php you have to enable $ldap_authentication
and specify all the parameters required for the connection. Users who
authenticate using LDAP are then copied into the DaDaBIK users table and
get assigned to a default (configurable) group. The aim of the copy is to
allow the permissions setting, LDAP users authentication is always
performed through the LDAP server.
Mixed authentication (some users authenticate against DaDaBIK, others
against an LDAP server) is also possible: during the log-in procedure, a
user can check/uncheck the LDAP checkbox in order to specify if he is
going to authenticate through LDAP or not.
If DaDaBIK is integrated into a Wordpress site, users authenticated
through Wordpress can also be (optionally) automatically authenticated
into DaDaBIK too, without doing the log-in again. See DaDaBIK
Wordpress Integration for further details.
For each table (each form and field), through the permissions manager,
you can set which operations (Read, Create, Edit, Delete and Details) are
allowed.
If you disable the read permission for a table, the related item won't be
displayed in the menu of the application. Remember, however, that users
can still read its records if the table is used as source of a
select_single/select_multiple field or as items table in a master/details
view.
Granular permissions:
If $enable_granular_permissions is set to 1 (this is the default
settings) in /include/config.php you can set, through the
permissions manager, which operations (Read, Create, Edit, Delete and
Details) are allowed for each users group on each form and field.
For example you can configure your application to allow the group
"Managers" to read and modify all the forms while the group "Employees" to
read all the forms and modify just some of them, or just some fields of
them.
As we said for the basic permissions, ff you disable the read permission
for a table, the related item won't be displayed in the menu of the
application. Remember, however, that users can still read its records if
the table is used as source of a select_single/select_multiple field or as
items table in a master/details view.
Integration with existing user and group lists
DaDaBIK uses by default the table dadabik_users and dadabik_groups to
store users information, but you can also use existing user and group
tables. This help the integration of DaDaBIK with existing applications,
for example with a CMS.
To set DaDaBIK to use your own users and groups table, you have to
configure the parameters starting with $users_table_ and $groups_table_ in
/include/config.php; the integration is also possible if your users
table doesn't use the same password encryption which DaDaBIK uses, in this
case you have to customize the hashing functions as explained in /include/config.php
Owner permissions:
An owner permissions model is also available, it allows to set-up the
application in a way such as users can:
Delete only their own records
Modify only their own records
View only their own records
The owner of a record is the user who inserted it.
You can enable this feature from the permissions manager; to enable it,
authentication must be enabled and each table you want to protect must
have a field whose DaDaBIK field type is set to ID_user. When a field is
set to ID_user, the username of the current user will be automatically
inserted by DaDaBIK into this field when you insert a new record. If you
want to base the ownership on the group instead of the user, change
$use_id_group_for_ownership in /include/config.php
Please note that you can enable the owner permissions also for
VIEWS, but also for VIEWS (as for TABLES) you need a working ID_user
field, VIEWS don't automatically inherit form settings from the underlying
tables. In some cases, however, you cannot directly insert records into a
view (the DBMS won't allow you to do it, to read some more details related
to MySQL see https://dev.mysql.com/doc/refman/5.7/en/view-updatability.html)
so the correct ID_user value must come from the underlying tables.
Adding a new language translation and fix
existing ones
Some of the language translations are incomplete. If you open your
language file (e.g. include/languages/spanish.php ) you can find the
sentences not translated looking at the // to change comments at
the end of each file row. You can complete the translation if you want.
You are more than welcome to contribute to the localization sending back to
info at dadabik dot org your improved translation.
A better way to modify a translation if you don't like the original one,
however, is to use, instead of the original file (e.g. english.php) the
corresponding custom file (english_custom.php); this is very useful to
avoid loosing your custom translations during the upgrade of DaDaBIK. It
is also possible to differentiate your custom translations according to
the table the user is using. Open the file
include/languages/english_custom.php to read the simple instructions you
need to override an original translation.
Adding a new language translation is also pretty straightforward. For
example, imagine you want to add Hindi: you just need to create a
copy of the file /include/languages/english.php, rename it as hindi.php,
and edit all the sentences of the file (for each row, the quoted part
after the arrow). You can then add the language to the list of available
choices adding 'hindi' to the parameter $languages_ar is /include/config.php.
Here is some security-related information which you must
know:
If your DaDaBIK instance is public and you have disabled
authentication (by default IS enabled), please consider disabling the
export to CSV feature from /include/config.php because robots,
accessing the CSV export link, could consume an inordinate amount of
processor time.
You should protect the upload directory from public access, otherwise
anyone who knows the URL of a file you have uploaded via DaDaBIK can
access the file itself, even without logging-in. By default, the
/uploads folder contains an .htaccess file which should prevent public
access on Apache, please test it because it might not work in your
environment; if you change the default upload directory or use a
different Web server than Apache you should provide the needed security
by yourself.
After having installed and configured a DaDaBIK application, it's a
good practice to remove the files install.php and upgrade.php, since
they could be used by malicious users in order to change or even
re-install your DaDaBIK installation.
The files admin.php, datagrid_configurator.php, db_synchro.php,
internal_table_manager.php, permissions_manager.php and
tables_inclusion.php can also be used to modify your application. If
authentication is enabled, the access to the files will be protected,
otherwise you should remove those files. For additional security, you
can however remove the files even if authentication is enabled.
The HTML content type and the rich_editor field type can lead to high
security risks: DaDaBIK uses the popular htmLawed
library to prevent displaying of dangerous HTML/Javascript code but, as
the authors state, (http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawed_README.htm),
there
are some minor cases in which htmLawed can fail. If a malicious user
insert some arbitrary javascript code and the library fails in
recognizing it, the code can be then executed by other users just by
using the application. Among other problems, this can lead to XSS attack
(http://en.wikipedia.org/wiki/Cross-site_scripting),
which
in turn can allow an unauthorized access to the application (http://en.wikipedia.org/wiki/Session_hijacking)
and, if the Internet browser of the user contains security holes, even
the execution of arbitrary code in the client machine.
DaDaBIK supports UTF-8; however, malformed UTF-8 characters can lead
to unexpected results such as content corruption. The use of the HTML
content type or of the rich text editor, in combination with UTF-8
content, is another factor that could lead, theoretically, to
unexpected results.
Security/data-integrity related:
Malicious users can exploit a field with content type set to HTML or
field type set to rich_edit to insert arbitrary javascript code, this
can lead to security risks if the htmLawed library doesn't filter this
content properly (see above, security section, for all the details).
Searching values containing % or _ using the "contains", "starts
with" or "ends with" conditions could lead to wrong search results.
Table and field names related:
Insert/search/update and some other operations fail if one or more
field or table names contain blank spaces or dots (e.g. "my field" or
"my.field" are not allowed, use "my_field" instead).
Quote characters and characters which need to be esacped such as ' `
" \, can lead to problems if used in table and field names.
Using field names containing the value set for $alias_prefix,
$null_checkbox_prefix, $select_type_select_suffix, $year_field_suffix,
$month_field_suffix, $day_field_suffix, $hours_field_suffix,
$minutes_field_suffix, $seconds_field_suffix could lead to unexpected
results; you can change the value of the above variables editing
/include/config.php
User interface related:
Some language translations are not completed. If you open your
language file (e.g. include/languages/spanish.php ) you can find the
sentences not translated looking at the // to change comments
at the end of each file row. You can complete the translation if you
want.
The rich editor interface (TinyMCE) is displayed in english only.
PosgreSQL related:
DaDaBIK needs table names in lower case to work on PostgreSQL.
You can't use, for a DaDaBIK application, tables/views coming from different schemas, they need to be in the same database/schema.
The insert e-mail notice doesn't work on PostgreSQL.
Insert/update don't work correctly on PostgreSQL if the user choose
"Other...." from a select_single field menu and the field has some
linked fields.
The after-insert hook doesn't fully work (it doesn't receive
the value of the primary key of the record just inserted).
MySQL related:
DaDaBIK doesn't support the BIT MySQL field type.
Admin section related:
The field renaming feature of the administration page doesn't work
as expected if the renamed field is used in one of the following
properties: "Primary key field", "Linked fields", "Order by", "Where
clause" in the forms configurator related to any of the tables. In
particular, after the renaming, you will get "[08] Error: during query
execution" messages from the DaDaBIK front end; you should edit the
above properties by hand, renaming the field in the forms
configurator.
The "refresh installation" admin operation doesn't work correctly
and could lead to a forms configurator settings loss if the
installation is the result of an upgrade from a DaDaBIK version <
4.1 rc2; the "refresh installation" bug is considered fixed only for
tables installed (DaDaBIK installation from scratch or single table
installation from the admin interface) using a DaDaBIK version >=
4.1 rc2.
Others:
The "previous" and "next" buttons don't work correctly after this
sequence of operations: - perform a search based on a field A - change
the value the field A for a record of the resultset
Primary keys composed by multiple columns are not handled.
Nested Master/Details views (a master/details view on a table which
is already in a master/details view as details table) don't work
correctly.
Upload and deletion of multiple files during the same
insert/update/delete operation are not considered as a unique atomic
operation: e.g. if you are uploading multiple files from the same form
and one of the uploads fails, other files already uploaded will result
available in the file system.
The "check for duplicated" feature doesn't work with file field
types: DaDaBIK doesn't warn about similarity when two files have a
similar name; furthermore, the "check for duplicated" feature causes
uploads to fail during insert, in particular the files are not
uploaded if some possible duplicated records are found and the user
decides to insert it anyway. The "check for duplicated" feature also
doesn't work with date, date_time, insert_date and update_date field
typed and with all fields which are hidden in the insert form.
HTML content is not set correctly as "Default value" (form
configurator).
When a new option of a select_single field with linked fields is
inserted through the "other..." option, the current user is not
inserted in the ID_user field of the linked table. This means that the
new record in the linked table won't get an owner and the owner
permissions won't work as expected.
If, while editing a record, you change the value of the primary key,
DaDaBIK is not able to show you the updated record after saving.
If an insert/edit form needs to be re-displayed because an error
occurred (e.g. a missing required field), FILE fields (only file fields) don't preserve
the values set by the user before submitting the form
If an image_file or generic_file field is used as a linked field for a lookup field, the file is not showed if the user doesn't have read permissions on the corresponding linked table.
Unexpected behaviors (not really DaDaBIK bugs but behaviors which the
average user doesn't expect)
DaDaBIK relies on the $timezone parameter for date functions (e.g.
to produce the current date), which can be different from the client's
(user) one.
The value actually inserted in the database during an insert/update,
if the value typed in the form is not part of the domain specified
during table creation (e.g. integer, varchar,...), depends on the DBMS
settings and on the domain itself. For example if an integer field is
left blank during insert/update (not NULL, blank), MySQL could insert
0 as value, because an empty string is not part of the integer domain
and very often the default value for integers is set to 0.
Formatting tags automatically inserted in a field through the HTML
editor are not filtered during search so if you search "hey good" and
you have "<b>hey</b> good morning" in your field you won't
find it.
If you set a master/details view between table A (master) and table
B (details) and you perform a search on B and then access (in edit or
details mode) a record of the table A, you will then lose the search
filter you had in B.
The Wordpress and DaDaBIK session expirations are not synchronized:
if your session expires in Wordpress it doesn't mean it automatically
expires in DaDaBIK. Use the logout button in Wordpress to be sure to
disconnect to both Wordpress and DaDaBIK
If you have enabled the Wordpress authentication, you should
login/logout through Wordpress without using DaDaBIK login/lougout;
mixing Wordpress and DaDaBIK login/logout can lead to unexpected
behaviours.
If an error occurs during installation or upgrade, the installation
of DaDaBIK can ends up in a inconsistent state due to implicit commit
policies of the DBMS.
Old versions of Microsoft Excel for Mac can't correctly represent
UTF-8 characters for CSV files produced by DaDaBIK