DaDaBIK Change Log

Please note that in the "Fixed bugs" sections, the bugs are not just related to the previous version, most of the time they also affect other, older, releases. Please also note that some new features or changes could be related just to DaDaBIK Enterprise or Platinum.

August 26, 2026
V. 13.6 Levanto

NEW FEATURES AND CHANGES

Added support for PHP 8.5, dropped support for PHP 7. The minimum PHP version required to run DaDaBIK is now PHP 8.1.
External Login via Identity Providers (OAuth2 SSO) / Google Authentication is no longer considered beta.
A new prepackage app, the Inventory Management app Dada Inventory, is now available. You can install it and use it as a starting point for your own inventory and sales management application, replacing the sample data and adapting the structure and workflows to your needs. You can see the application in action in this YouTube video
Calendar views now load only the events required for the currently displayed date range. Previously, DaDaBIK loaded every event in the table, which could cause significant delays or crashes when working with very large datasets.
Formula fields are now treated as calculated fields in terms of allowing live edit.
The size of the DaDaBIK package has been reduced by about 12.5% .

FIXED BUGS

The DELETE ALL operation produced an error. Fixed.
The configuration parameter $menu_hidden_tables stopped working in v13.5 unless you used DaDaBIK Platinum. Fixed.
DaDaBIK could assign to the dadabik_errors table a menu order already assigned to other tables, this generated a message in Dev Area > Menu Preview, suggesting to fix the order. Fixed. The dadabik_erorrs table is now placed afater all the other menu items, its alias is now just 'Errors' and has an icon.
Fixed an issue where typos in the SQL files for the three pre-packaged apps prevented them from being imported correctly during installation. Users who already imported a pre-packaged app should clear their database and import it again. **
For non-Platinum versions, under particular circumstances, the form configurator could generate an erorr when an admin users clicked on "VIEW THIS APP" they could get this error "Feature only available for DaDaBIK Platinum". Fixed. **
The up/up2 procedure produced warnings and did not work if output buffering was disabled or the buffer was not large enough. Fixed.
If a field has Custom JS formatting code set, live editing is now disabled for all fields in the table. This prevents temporarily incorrect formatted values when the formatting depends on other fields. It can still be explicitly enabled for specific fields by setting $allowed_fields_live_edit, for such field, to 2.
Documentation about iCal URL feature now clearly says that HTTP API must be enabled and the user generating the iCal URL must have privileges to use HTTP API.
Fixed the documentation in config.php: the previous text was accidentally truncated after "unless you are using PostgreSQL as DBMS, the". It now correctly states that, unless you are using PostgreSQL as DBMS, the $enable_lookup_insert_popup = 1 feature only works if the "linked table" has an auto-increment primary key that is also set as the unique field in DaDaBIK -> Admin -> Pages.
Modern UI ($ui_style set to 'modern'): the menu item separators were not visible. Fixed. For conditional fields, labels for hidden fields were displayed. Fixed. Furthermore, the config documentation related to $ui_style now mentions some of the known bugs related to the 'modern' UI and refers to the forum for futher discussion.
If $treat_blank_as_null was set to 0, a warning could be generated by before insert and before update operational hooks in case you had file fields in your form. Fixed.
Some libraries used by DaDaBIK have been upgraded: BaconQrCode upgraded to v3.1.1. PHP Barcode Generator upgraded to v3.3.0. Guzzle upgraded to v7.15.3. Guzzle PSR-7 upgraded to v2.13.0. Guzzle Promises upgraded to v2.5.2. Symfony Deprecation Contracts upgraded to v3.7.1. codemirror upgraded to v5.65.21. TwoFactorAuth upgraded to v3.0.3. htmLawed upgraded to v1.2.17. This fixes bugs and security issues that the version previously used by DaDaBIK could have, check the changelog of each library for the details.
The DBMS version could fail the requirement check even if it meets the requirements. Fixed.
The installation from prepackaged app now clarifies that DaDaBIK assigns the same installation password to all the users available in the prepackaged application.
Typo in a message produced by the up/up2 procedure: in case the developer tries to upgrade to a version < 13.5, the error message said "This upgrade script can only be used to upgrade to the latest version, at the moment 13.4-Levanto" (instead of 13.5-Levanto). Fixed.

*** Depending on when you downloaded DaDaBIK, you may have this fixes already available in your V 13.5

July 7, 2026
V. 13.5 Levanto

NEW FEATURES AND CHANGES

NEW Graphical User Interface

This version introduces a new, beautiful, modern, experimental UI, quite different from the classic DaDaBIK UI. It is disabled by default, you can enable it by setting the config parameter $ui_style to 'modern'.
A much faster engine

DaDaBIK v13.5 introduces a new, much faster version of the internal permission-checking engine, a core component that DaDaBIK runs frequently behind the scenes while end users browse and use the application. If your application has a huge number of tables/fields, this can considerably improve performance (even 5x faster when you open a data grid page).
Advanced error handler

DaDaBIK now includes an advanced, optional error handling system. If enabled, PHP errors, warnings, uncaught exceptions and fatal errors are handled by DaDaBIK. Error details include, among other things, file and line, URL, logged user, table, function, browser, IP address and, when available and enabled, the latest known SQL query. Errors can be written to the PHP error log, to a custom text file and they can also be sent by email, with optional throttling to avoid repeated notifications for the same error. You can enable the new error handling system by setting $error_enable_reporting to 1, please check all the related configuration parameters in the configuration file.
For DaDaBIK Platinum, errors can also be written to the DaDaBIK errors table, and administrators can review handled errors from the DaDaBIK interface, mark them as resolved or unresolved, and see related summary charts.
A generic error message can be displayed to users while full technical details are kept in the configured logs/notifications.
Improved Calendar view
- In addition to the grid month view, the calendar now has additional views: week, day and list. A configuration parameter $fullcalendar_initial_view allows to set the default initial view.
- Added support for a category field in calendar events. The field is used to choose the color used to represent the event in the calendar (each category is displayed using a different color). Category colors can be set using the $fullcalendar_category_colors configuration parameter. An additional configuration parameter, $fullcalendar_text_color, can be used to set the text color.
- Added support for a tooltip field in calendar events. The field is exposed in the FullCalendar event data and can be used to display additional information when hovering over an event.
- Added the $fullcalendar_additional_code configuration parameter, allowing administrators to inject custom FullCalendar configuration code directly into the new FullCalendar.Calendar(calendarEl, { ... }) initialization object, making it easier to customize code, settings and other FullCalendar features without modifying core files.
KPI Dashboard on the top of your results grid

The TinyMCE instances in Dev Area > Layout > Record List Layout, differently from the one in "Pages", were sandboxed and did not embed the bootstrap CSS. Sandboxing have been removed and bootstrap CSS added, allowing to add content containing Javascript and to use bootstrap, for example for adding small KPI dashboard on the top of each table page. Furthermore it is now available, as already available for Custom pages, a Dashboard Template to use as a starting template if you want to add a small KPI dashboard on the top of a datagrid.
Improved logo rendering on high-density displays

The default DaDaBIK logo has been replaced with a higher-resolution version and is now displayed at a fixed height via CSS (#dadabik_logo { height: 90px; width: auto; }). This prevents the logo from appearing blurry on modern high-density / Retina displays while keeping its visual size unchanged.

The same CSS rule also applies to custom uploaded logos: users no longer need to resize the logo file to the exact display height before uploading it. A larger logo can now be uploaded, and DaDaBIK will display it at the correct height automatically, preserving the aspect ratio.

If your custom logo looks blurry, we recommend uploading a higher-resolution version of the logo. You can also customize the displayed logo size by adding your own CSS rule for #dadabik_logo in styles_screen_custom.php.

To see the new sharper default logo, you may need to clear your browser cache.
A new config paramter $always_show_datagrid_heading_after_title allows you to set whether the Datagrid Heading after title must be displayed even if the display mode is "list" (display mode typically used with mobile devices). By default, it's set to 1.
A new config parameter $always_hide_show_revisions_button allows to hide the "show revisions" button.
The main HTML tables used only for layout purposes (not data tables) have now the role="presentation" attribute. This should help screen readers.
The new configuration parameter $barchart_bin_colors allows to set a color (or a palette of colors) to use for the bins of bar charts.
The page main h1 heading (displayed in data grids and CRUD forms) has now its own ID: main_page_heading, this is useful for applying custom CSS.
New permissions and installation defaults:
- By default and only for new installations the "Install & enable tables on creation" setting is now set to YES (instead of NO); you can change the setting from DEV AREA > DATA > Settings.
- The configuration parameter $grant_permissions_after_table_installation is now set by default to 2 (instead of 0), both for new and old installations, meaning that when you install a new table or add a new field to your DaDaBIK applications, all the related permissions are set to YES, but only for the administrator user group. Remember that if you are not using granular permissions ($enable_granular_permissions = 0), options 2 set all the related permissions to YES for everybody.
New theme: Midnight Blue.
The custom email function, in addition to the existing $header parameter, may have threee additional parameters, in this order: $from_email, $from_name, $to_name. $from_email is only used (and needed) by the error email notifications; $from_name and $to_name are currently not used by DaDaBIK.
The Custom Code API method count_record() returned a string, now it returns an integer. Consider to modify your custom code in case you used count_record() and assumed it was a string (e.g. "15" instead of 15) or set the new config parameter $api_method_count_records_return_string to 1 if, for backward compatibility, you prefer the old behaviour.
You can now set in your custom language file the variable $dadabrain_answer_footer, a text that will always be displayed at the end of the DadaBrain AI output.

FIXED BUGS

Some libraries used by DaDaBIK have been upgraded: tagify upgraded to v4.37.1, guzzlehttp/guzzle to v7.12.1, guzzlehttp/psr7 to v2.12.1, guzzlehttp/promises to v2.5.0, symfony/deprecation-contracts to v3.7.0. This fixes bugs and security issues that the version previously used by DaDaBIK could have, check the changelog of each library for the details.
An inline edit on a field whose value was NULL generated an error. Fixed. ***
With user entities enabled ($enable_user_entities = 1, as it is by default), adding or deleting a record from a table that is not defined as user entity table generated a PHP warning message. Fixed. ***
v13.4: the up/up2 upgrade procedure did not work on PostgreSQL. Fixed. ***
v13.4: After upgrading with the up/up2 procedure, the "push to live" and "pull to beta" actions generated an error. Fixed. ***
This bug was fixed in v13.4 but not added to the change log file distributed with DaDaBIK: The insert_record custom code API method, when used with PostgreSQL, did not work. It could fail and not create the record (and the corresponding revisions / logs) or it could create the record but not register the corresponding revision or register the revision without the correct reference to the record inserted. ***
In v13.4 the custom code API method insert_record did not work and failed to insert a record when no transaction was active when it was called. Whether a transaction was active depended on the context where the method was called. Fixed.
The $enable_download_ical and $enable_ical_url config parameters did not have effect, the related features were always enabled. Fixed.
If $prefix_internal_table was not set to the default ('dadabik_') or you were using a custom groups table or a custom name for the id_group field of the groups table, the upgrade procedure to v13.4 failed and generated an error. Furthermore, during installation, the field dadabik_user_entities.id_group_user_entity was set as foreign key referencing the field dadabik_groups.id_group (which might not be correct). Fixed. ***
Row-level permissions: when multiple user entities were available and a user entity type was selected as "Type of Value" (current_user_...ENTITY...), the "value" dropdown in the row-level permissions section could display an incorrect or empty selection compared to the actual value stored in the database. This could lead to misinterpreting how a rule was configured, and to unintended overwrites if the form was saved. Fixed. ****
config.php documentation stated that default max upload size for log is 10Kb, however, it is actually 100Kb. Fixed.
If $treat_blank_as_null was set to 0 and the user did not check any option and did not check the NULL checkbox, INSERT and UPDATE operations could generate warnings / dropdown validation errors with certain field types, for example radio buttons. Fixed.
When $treat_blank_as_null was set to 0, insert and update of users did not work as expected and this led to several related issues including the inability for a user created in DaDaBIK to login. Fixed. Also, the config documentation about $treat_blank_as_null now states that "when you insert into or edit users and groups tables, DaDaBIK works as if $treat_blank_as_null was set to 1, even if you set this to 0".
Upgrading from a vewrsion <= 12.2-Aveto generated undefined array key errors when DaDaBIK was used in BETA Dev Mode or during LIVE > BETA pull. Fixed.
Dev Area > Pages > Custom pages: the link to open a custom page was wrong and always tried to open the page having id 3. Fixed.
DaDaBrain AI did not work correctly when a user was in Beta development mode: the generated views were not displayed under the "Questions" folder, their user-friendly aliases were not set, and permissions for generated views were incorrectly granted to all AI reports created by the user, regardless of whether the views were created in Live or Beta mode. Fixed.
The online version of the manual did not mention, for the insert_record API method, what the method returns. Fixed.
Documentation about formula fields now points out that Formula fields involving decimal values may display floating-point precision artifacts in the form, e.g. 85.39999999999999 instead of 85.40; read the manual ("Formula Fields and Calculated fields" chapter) to read all the details about possible consequences.
A chart generation on an empty dataset produced an error. Fixed.
Dev Area > Export App: the inline instructions did not point out that views created by DaDaBrain AI were not exported (unless "include all tables" was checked). Inline documentation updated.
Dev Area > Export App: the DaDaBIK tables that store information about user entities (by default, dadabik_user_entities and dadabik_user_entities_beta) were not exported (unless "include all tables" was checked). Fixed.
Form configurator maxlength for MS SQL Server TEXT fields was set by default to -1. Fixed, it is now set to 1000.
Prepackaged apps could produce charset mismatch errors when installed into an empty database using certain database character sets. Fixed.
If DaDaBrain was enabled, a warning was generated when revisions were displayed. Fixed.
The requirements check could sometimes incorrectly report that the DBMS version did not meet the minimum requirements, even when it did. Fixed.

*** Depending on when you downloaded DaDaBIK, you may have this fixes already available in your V 13.4

March 18, 2026
V. 13.4 Levanto

NEW FEATURES AND CHANGES

User entities are now supported: from Dev Area > Users you can set tables whose records can automatically create and synchronize corresponding user account.
Row-level permissions have been improved: support for IN operator, support for SQL queries as filter values, support for using User Entity fields in addition to Users fields.
Custom code API: insert_record method now returns the ID of the last generated autoincrement field value.
Custom code API: get_record_details method has now an additional parameter $return_false_if_no_results: if set to TRUE, the method return FALSE in case no records is found. Default is FALSE and in case no record is found an error is generated the execution is stopped (which is the previous behaviour).
DaDaBrain AI: Added configurable tooltip (check the language entry "ask_questions_data_read_only") to the ASK AI button.

FIXED BUGS

Security fix: escaped four occurrences where values were inserted into HTML without proper encoding.
Unescaped values could break the page layout, display truncated data (e.g. when inline editing values containing double quotes), potentially causing accidental data loss if the truncated value is saved and allow XSS attacks.

Affected areas:

1. select_multiple / select_multiple_checkbox (non-lookup fields)
The option label displayed in the form was not escaped.

2. Items (master/detail) table form
The hidden input value used to pass the reference to the master record was not escaped.

3. Results grid
The unique field value used in the 'data-row' attribute was not escaped.

4. Results grid
The value that appears when a user double-clicks a cell to "live edit" was not escaped.

Security impact: in case (1) exploitation requires access to the dev area or the dadabik_forms table to inject malicious values, in cases (2) and (3) the issue could potentially be exploited by standard application users if a table contains a unique field that is not strictly numeric (e.g. a VARCHAR unique field), in case (4) the issue could potentially be exploited by standard application users if live edit is enabled ($enable_live_edit 1).

The application users mentioned in (2), (3) and (4) are users who have access to the application after authentication. The vulnerabilities cannot be exploited without logging in, unless authentication is disabled (public user) or an attacker can access the related database through other means.
The insert_record custom code API method, when used with PostgreSQL, did not work. It could fail and not create the record (and the corresponding revisions / logs) or it could create the record but not register the corresponding revision or register the revision without the correct reference to the record inserted.
If you upgraded DaDaBIK from a version < 13, using the up/up2 procedure, you got a "Call to undefined function" error. Fixed.
Change status buttons created via AppifyText.ai and imported in a DaDaBIK installation did not check / requested record lock before changing a status. This could lead to inconsistent record states in multi-user environments. Fixed.
Some libraries used by DaDaBIK have been upgraded: tagify updated to v4.36.0, codemirror upgraded to v5.65.20, TCPDF upgraded to v6.11.2, SortableJs updated to v1.15.17, oauth2-google upgraded to v4.2.0, guzzlehttp/psr7 updated to v2.9.0. This fixes bugs and security issues that the version previously used by DaDaBIK could have, check the change log of each library for the details.
When you pushed / pulled (Dev Mode) you got an "Unexpected table" error. Fixed.
Dev Area > Permissions > Copy permissions: the page did not mention that only table-level and field-level permissions are copied, not the row-level permissions. Page instructions fixed.
The examples for $working_dir in the config documentation were misleading. Fixed.
The config documentation stated that $upload_relative_url was not used anymore, but it is still used if $file_access_mode is set to 'public_url'. Documentation fixed. The config documentation did not mention that if you change $upload_relative_url you must change $upload_directory accordingly. Documentation fixed.
When $upload_relative_url contained characters that need to be escaped (e.g. quotes), files might not display. Fixed.
When an uploaded file name contained characters that needed to be URL encoded and you used $file_access_mode = 'public_url', files might not display. Fixed.
If you set $button_confirm_messages and your message contained certain characters that need to be escaped (such as single quote), the confirmation message did not correctly work and could generate a Javascript error. Fixed.
Documentation, The Audit/Revision chapter now points out that Database Operations executed by Automations added via AppifyTextai are not audited.
Form Configurator, inline help for cascade parameter said it only works in INSERT and EDIT forms, but it also works in ADVANCED SEARCH forms if $enable_cascade_advanced_search_form = 1. Fixed.
If you used the BETA DATABASE ($use_db_name_beta = 1, Platinum only), status change buttons created wtih AppifyText.ai were not synchronized during Push/Pull. Fixed.
A semicolumn as last character in the SQL for an advanced SQL report genrated an error message and terminated the script. Fixed.
v13.3 enterprise generated a Call to undefined function is_ai_select_sql_safe() error when Advanced SQL Report were used. Fixed.
Better messaging for form_config_security_check error messages.
When a view installed in DaDaBIK referenced invalid columns, the form configurator became blank. Fixed.

January 20, 2026
V. 13.3 Levanto

NEW FEATURES AND CHANGES

DaDaBrain AI is now available (Platinum edition only).
DaDaBrain AI is an experimental feature that allows users to ask natural language questions about the data displayed in a DaDaBIK application.

For example, users can ask questions such as:

“How many customers do we have?”
“Which customer generated the highest revenue?”
“Show all orders placed in the last month.”
“What is the total revenue by product category?”
Based on the user’s question, DaDaBrain AI generates an SQL query, executes it, and returns the result directly in the interface. Further info in the manual in the dedicated "DaDaBrain AI" chapter.
You can now set a custom validation rule for a field without specifying a custom error message; a default error message ("The entered value is not valid") will be displayed.
A new configuration parameter, $enable_advanced_sql_report_user_ids, allows restricting the Advanced SQL reports feature to specific users only.

FIXED BUGS

SQL queries used to build Advanced SQL reports are now subject to a basic sanity check based on keyword matching, aimed at preventing the execution of dangerous SQL instructions and the explicit reference to particularly sensitive fields. A new configuration parameter, $disable_advanced_sql_report_sanity_check, has been introduced to disable the sanity check for backward compatibility with existing installations relying on unrestricted SQL queries; by default the sanity check is enabled, so if you have stored (for example in a dashboard) any advanced SQL Reports, those reports could not work if they are considered unsafe, unless you set $disable_advanced_sql_report_sanity_check = 1.
The configuration documentation has been updated to more clearly point out that, despite the sanity check, when Advanced SQL reports are enabled users may still be able to access sensitive data (including the dadabik_users table) if the database user used by the application has the required privileges.
Some libraries used by DaDaBIK have been upgraded: TCPDF upgraded to 6.10.1, Chart.js upgraded to v4.5.1, tagify updated to v4.35.6, bacon/bacon-qr-code, league/oauth2-google, picqer/php-barcode-generator and their dependent libraries have been upgraded to the latest version available on Jan 12 2026. This fixes bugs and security issues that the version previously used by DaDaBIK could have, check the change log of each library for the details.
The documentation about the configuration parameter $enable_advanced_sql_report still mentioned $username_public_user, which is not available anymore; the related security comment has been changed to "Enabling this feature for a public user can be particularly dangerous".
If you upgraded DaDaBIK using the up/up2 procedure starting from a version prior to v11.4, you got an Undefined variable $results_grid_fixed_header warning message. Fixed.
The VIEWS chapter of the manual now points out that VIEWS do not inherit table, field, or row-level permissions or form configuration settings from the underlying tables.
DaDaBIK now generates an error if from Dev Area > Data a user tries to create a table or view containing the string "dadabik_" (or a different, custom, $prefix_internal_table ).
When a view is created from Dev Area > Data, for security reasons blank spaces and dots in the name are converted to underscore (_), as already happened with table names.
When German was selected as language, after a search the "Remove search filter" button did not appear and a warning was generated. Fixed.
Wehn Italian was set as language, the inline help tooltip for advanced SQL report did not work and generated a Javascript error. Fixed.
Documentation about formula fields: one example was wrong (missing curly brackets). Fixed.
A new "Privacy and logging" chapter has been added to the documentation, stating that regarding the various optional loggin mechanisms that DaDaBIK offers, when logging is enabled, administrators are responsible for informing users according to applicable laws, policies, and organizational requirements.
Fixed malformed HTML in results grid page
The Spanish language has been updated

October 29, 2025
V. 13.2 Levanto

NEW FEATURES AND CHANGES

The new iCalendar export and synch feature
For each of your calendar views, two additional buttons now appear: iCal (Enterprise and Platinum edition only) and Generate iCal URL (Platinum edition only).

The iCal button exports, for the current table, an iCalendar file (.ics) containing the events. The generated file can be imported into any calendar application that supports the iCalendar format (e.g., Google Calendar, Apple Calendar, Outlook, Home Assistant, etc.).

The Generate iCal URL button creates a unique URL that provides the same iCalendar feed but can be subscribed to by external calendar clients. This means that other applications can stay synchronized with the DaDaBIK calendar view (including any filters applied when the URL was generated).
More details in the manual's dedicated chapter
It is now possible to use greater than, less than, greater or equal to, less or equal to search operators with select_single and select_single_radio fields, if they are not lookup fields.

FIXED BUGS

If, in DEV Area > Layout > Record List Layout > Calendar layout you did not fill all the event fields, DaDaBIK used, for a missing field, the value of another event field, possibly generating wrong content in the calendar. Fixed.
The up/up2 upgrade procedure did not work if you upgraded a DaDaBIK v <= 11.12 directly to DaDaBIK 13.0 or 13.1. Fixed.
Calendar view: if the title field of an event contained a double quotes character ("), its value in the calendar view was displayed with an extra double-quote. Fixed.
A deprecation warning was generated if one of the field values of a calendar view was NULL, this could break the Calendar view, which resulted empty
The default homepage of an AppifyText.ai imported app did not correctly render the tooltips. Fixed.
The omnisearch button tooltip, which lists all searchable fields, now removes any HTML tags present in field labels.

September 10, 2025
V. 13.1 Levanto

NEW FEATURES AND CHANGES

DaDaBIK now officially supports PHP 8.4. To use it, you need ioncube loader v14.4.x (we recommend the latest version, currently v14.4.1)
It is now possible to assign a specific PDF template (or more than one) to each table/view to use it by default when users click the PDF button, also assigning a specific button label. Further info in the manual, chapter "Assign a specific template to a table/view".
If no custom PDF templates are available in the templates folder, the PDF button now immediately generates a PDF using the default template instead of opening the template menu.
The folder name of the users and groups menu items is now "Users" (replacing "Admin").
If, for the current table, a prepopulated search field callback funciton is set, a "set default search filter" button is now displayed to allow users restoring their default filter. A new config parameter, $show_set_default_filter_button (default 1), allows to show/hide the button.
A new config parameters allow to set a number of seconds before deletion of CSV/XLS/ODS files after import: $seconds_before_delete_imported_csv_file
The Google authentication now stores in the dadabik_users table also first and last name of the user; the first name (instead of the email) is now displayed in the top right corner when the logged user is a Google authenticated user.

FIXED BUGS

Google authentication now identifies users by their Google account ID ("sub") instead of their email address. While Gmail addresses are unique and not reused, Google accounts can also be created with non-Gmail addresses. These external addresses may change or even be reassigned to other users. Relying on email alone could therefore break the link with the original user and introduce security risks, as someone inheriting a reused email might gain access to the previous user’s account. Using the stable sub claim ensures that each Google user is reliably and securely recognized. If you want to migrate existing Google users please contact us before upgrading.
The calendar view did not correctly display lookup fields (the PK value was displayed instead of the linked field values) and select multiple fields. Fixed.
Calendar layout settings: the description field has been removed, it was not actually used. Furthermore, if you did not fill all the event fields (even the ones that are not required), DaDaBIK generated a warning and the calendar data were not displayed in the calendar page. Fixed.
Calendar view: The form configurator inline help now clearly states that custom formatting functions do not apply to calendar views.
Starting from v11.4 Elba, DaDaBIK stored an empty password in the dadabik_users table for LDAP users. Beginning with this release, a securely generated random password (hashed) is stored instead. This change improves security by preventing unintended access in case of a bug or an unwanted switch of the authentication type from LDAP to DaDaBIK. The same approach now also applies to Google-authenticated users (introduced in v13.0). For existing LDAP and Google user, the upgrade procedure replaces the password.
After insertion in an items table (master/detail form), DaDaBIK produced an "Unexpected master table name" error message, despite the record was correctly inserted. Fixed. This issue has been introduced with v13.0 and silently fixed the day after, so depending on when you downloaded v13.0, this could not apply to you.
Users form: Fixed the German translation for a message related to LDAP/Google users — it now explicitly indicates that Group is the only field that should be modified.
Import or instal from XLS/CSV/ODS files produced deprecated error messages with PHP 8.4. Fixed.
Fixed typo in the Italian transaltion.
Users form: the hint message close to the password and the force password change fields were hard-coded in English. Fixed, the translation is now in each language file. Furthermore, this message "This is an imported LDAP user: his/her group is the only information you should change, if needed." is now "This is an imported user (LDAP, Google, ... ) because it applied not only for LDAP users.
Groups page: the warning about group deletion was hard-coded in English. Fixed, the translation is now in each language file.
The documentation related to custom users and groups tables in config.php was outdated and still mentioned the PHPASS library, which is not used anymore. Fixed. Furthermore, it now mentions the fact that if you overwrite the default hashing function, you must do it again at every DaDaBIK upgrade.
Form configurator inline help: now all the links to the online documentation show a warning before showing the manual if the version installed is not the latest one, to avoid reading content that does not apply to your installation. + Small improvements.

July 29, 2025
V. 13.0 Levanto

NEW FEATURES AND CHANGES

Barcode and QR code generation
DaDaBIK now supports native generation of barcodes and QR codes. You can define a field with type "barcode/qrcode" to automatically generate a visual code representation of each record. The codes are displayed on-the-fly in the results grid, details page, and exported PDFs.

Multiple symbologies are supported (e.g., Code 128, EAN-13, QR Code), and you're free to customize the encoded value—by default, DaDaBIK uses a unique string like table_primarykey (e.g., products_45), but this can be adapted to suit your needs.

This feature is ideal for inventory management, logistics, ticketing, asset tracking, and more.

See the manual for futher details.
No-code row-level permissions
A new no-code row-level permissions feature is now available in the permissions section of the Dev Area. This allows admins to define simple, field-based visibility conditions for each user group without writing PHP code. Conditions can compare a field of the current table with a custom value, a field from the current user, or a field from the current user’s group.

Some examples:
1) order_status = 'approved' (for the selected group, only show the approved orders)
2) order_assigned_to = current user's username (for each user of the selected group, only show the orders assigned to them).

You can also use this feature to implement a multi-tenant application, restricting users to records from their department or organization.
New Calendar Layout
The new Calendar Layout allows you to display records as calendar events—ideal for scheduling, booking systems, or any application where time-based data matters. Instead of the standard Grid view, you can now visualize entries by day, week, or month, providing a more intuitive and interactive experience. For each table, you can choose your preferred layout by navigating to Dev Area > Layout > Record List Layout (formerly "Datagrid Templates").
External Login (OAuth2 SSO) / Google Authentication
Google auhtentication via OAuth2 is now available: users can now register and login to a DaDaBIK application using their Google account (see the config paramater $enable_google_authentication, by default set to 0). This feature, at the moment, is in beta, we do not recommned the use in production.
Prepopulated search fields
Added support for prepopulated search fields: you can now define default search criteria for each table and field. These parameters are automatically applied after user login, affecting both the displayed recordset and the quick search form. Users can override these default filters by executing a manual search or clicking on "Remove search filter". See the manual for futher details.
Non-admin users can manage users
Non-admin users can now see and manage users and groups through the DaDaBIK interface (depending on the permissions on the dadabik_users and dadabik_groups table and if $enable_granular_permissions = 1, as it is by default). However, they are restricted from editing or deleting admin users or the admin group, and from assigning the admin group to any user. Note: These restrictions apply only when using the DaDaBIK interface and do not apply when managing users and groups via custom code.
For unblocking users after too many failed login, an admin account is still needed.
JavaScript-based custom formatting functions
You can now format field values in both the results grid and details page by specifying a JavaScript formatting function directly in the Form Configurator. This complements the existing PHP-based custom formatting feature. JavaScript formatting is executed client-side.

The JavaScript function has access to all the field values of the current record, allowing you to create dynamic output based on multiple fields — not just the one being formatted. Useful for: displaying emojis or icons based on conditions, showing badges or colored labels using HTML, formatting numbers or dates according to locale, changing the background color of a value. Here is a simple example:

return record['available'] === 'yes' ? '✅ ' + value : '❌ ' + value;

This function adds a ✅ if the item is available, or a ❌ if it's not. For example, "MacBook Air" becomes "✅ MacBook Air" if available, or "❌ MacBook Air" if not.

See the manual for futher details.
Revamped Admin Area UI
Introduced a fresh new color scheme, a cleaner layout, and refined wording for better usability. The update also includes integrated code editors with syntax highlighting for JavaScript, CSS, and HTML, enhancing the editing experience for advanced users.
NoCode layout hooks: It is now possible to add custom HTML content before and after a table's datagrid title without using Layout Hooks, via Dev Area > Layout > Record List Layout.
From the edit form you can now delete the current record by clicking the new DELETE button. You can set the configuration parameter $show_delete_button_in_edit to 0 if you don't want to show the button (delete permissions are needed to execute the deletion).
Added support for additional custom DB connection parameters; this can be useful, for example, to establish an SSL DB connection. See the new config parameter $additional_db_connection_parameters for details
Added support for additional custom PDO connection strings (config param $additional_db_connection_string).
A new configuration parameter, $defult_2fa_self_registration, allows to enable by default Two-factor authentication for self-registered user.
The configuration paramter $dont_use_admin_config, if set to 1, generated errors. It is now no longer supported.
$enable_authentication = 0 in config_custom.php generated several error messages, now setting this parameter to 0 in config_custom.php does not have any effect, if you need public access you must set your public user from Dev Area > Permissions > Public Access.
After login, DaDaBIK redirects to the homepage of the app only if the current user is allowed to view it. Before, an error ('Unexpected error, this page is not enabled or the current user....') was generated if the user was not allowed.
Datagrid templates: if you edit the template and then disable the use of templates then save, the edit is now saved (in the previous version it did not).
The configuration parameter $show_edit_button_in_details is now, by default, set to 1.

FIXED BUGS

Some libraries used by DaDaBIK have been upgraded: TCPDF to v6.10.0 (also fixing a vulnerability), TinyMCE to v6.8.6 (also fixing an XSS vulnerability), Chart.JS to v4.5.0, Sortable to v1.15.6, tagify to v.4.35.3. This fixes bugs and security issues that the version previously used by DaDaBIK could have, check the change log of each library for the details.
If access logging was enabled ($enable_access_logging = 1), DaDaBIK tracked the logins in the daddabik_logs table without the username_user and if 2FA was enabled, a standard login was tracked (again, without useername_user) after having submitted a correct user+password, before entering the verifcation (second factor) code. Fixed.
When using multiple file fields in a single form with $upload_field_type set to 'ajax' (the default), only the first field displayed upload progress indicators and confirmation/error messages near the field. Although uploads worked for all fields, the lack of visual feedback on the others could mislead users into thinking the upload failed—or succeeded when it didn't. Fixed.
The manual now mentions that despite DaDaBIK may suggest to edit config.php, the file to edit is always config_custom.php
Documentation now points out that auto-generated values (such as barcodes) cannot be used as calculated fields parameters.
The offline and online documentation of v12.7 referred to itself as 'manual about v. 12.6 Aveto' instead of 'v. 12.7 Aveto'.

May 21, 2025
V. 12.7 Aveto

NEW FEATURES AND CHANGES

Public facing features
It is now possible to set the public user from DEV Area > Permissions > Public access (without editing config_custom.php). From the same page, it is also possible to hide the left menu, the top bar and the advanced features for public users; this makes easier to customize the public face of a DaDaBIK application without the need of writing code.
New Chart Type
Added support for a new chart type: Stat Cards: display key metrics like totals and averages at a glance, without data aggregation by group, for example show (even in a dashboard) the total number of your customers, the average age of your users, the revenues in the current year.
A new, improved example of HTML datagrid template is available in the inline help (Dev Area > Layout > Datagrid Templates). The whole inline help has been rewritten, also pointing out that dadabik_hide ... dadabik_hide blocks must be on a single line (no line breaks).
When a new custom page is added, the confirmation message now explains you need to enable the page and assign permissions to use it.
If you access a DaDaBIK application from a small screen, now by default the list view (instead of the grid view) is used.
DaDaBIK now automatically interprets field names 'file' or containing 'attachment' as indicators to set the field type to 'generic_file' during installation and creation of new tables or fields. You can change this behaviour by overriding the parameters $autoconf['file_words_exact_match'] and $autoconf['file_words'] in /include/config_custom.php
The Admin Area is now called DEV Area.
The form config parameter "User-friendly searchable" is now called "Search-as-you-type".

FIXED BUGS

Security Update

characters

extremely

forgotten password

The following item was in the 12.6 fixed bugs change log online, but not in the change log file distributed, it has been added:

"This item in the v12.5 change log contained an error. Incorrect: "Chart and pivot generation: if you aggregated data by Quarter or Month, the data items in the resulting report were not correctly chronologically ordered.". Correct: "Chart and pivot generation: if you aggregated data by Quarter or Week, the data items in the resulting report were not correctly chronologically ordered.". Fixed."
When upgrading to v12.6 from v11.12 or earlier using the up/up2 procedure, DaDaBIK generated an "Unexpected table name dadabik_forms" error. Fixed.
Installation requirements check: sometimes the comparison between the DBMS version and the minimum version required was not correctly performed. Fixed.
The CSS file for the dark mode was (almost) always reloaded even if $force_reload_css_js was set to 0.
When characters were unintentionally added outside PHP tags (e.g. a blank line added to custom_functions.php), displaying uploaded images and generic files and producing PDF, CSV and JSON files generated errors. Fixed.
Small fix to the dark theme.
Sometimes, apparently randon, the installation of DaDaBIK or the creation of a new user failed with an "Uninitialized string offset 15" error. Fixed.
In v12.6, the logo uplaod feature stopped working. Fixed.
When the delete multiple feature is used, the confirmation message now refers to 'record(S)' and not 'record'.
DaDaBIK generated some Javascript errors in some of the Dev Area > Layout tabs. Fixed.

March 20, 2025
V. 12.6 Aveto

NEW FEATURES AND CHANGES

A new theme, Dark, is now available, providing a dark mode experience. The Dark Light-Top variant is identical to the Dark theme, but with a white top bar. This option is ideal if your logo requires a white background.
A dashboard template is now available. You can use it as a starting template for your custom HTML pages, it's a responsive, multi rows and multi columns template with some example charts and reports. You can access it from admin > pages > custom pages > show/hide content.
Added two new settings in Admin > Layout > "Basic settings" to hide the left menu entirely and/or hide the top bar, including the logo. This provides more space and enables an ultra-minimalistic design.
Added four new color parameters that you can set in Admin > Layout > "Basic settings": Top Bar Bgcolor, Edit icon, Delete icon, Details icon.
New Cache Management: Previously, after an upgrade, users were advised to clear their browser cache to ensure the latest versions of CSS, JS files, and images were loaded—otherwise, the application's layout and functionality might not work as expected. This is no longer necessary for JavaScript and CSS files: DaDaBIK now ensures the updated versions are loaded even if the old files are cached. Images and fonts may still be cached, potentially affecting only the graphical layout. Your custom files (e.g., styles_screen_custom.css and custom_functions.js) remain unaffected by this change.
The omnisearch box is now displayed even on small screens.
Confirmation, error and alert messages have been restyled
In DaDaBIK, during installation and table creation, the system automatically detects potential relationships and lookup fields based on field names. Prior to v12.6, this detection failed if field names had different letter casing. This issue has now been resolved, ensuring case-insensitive relationship detection.
Documentation Update: utf8mb4 (not UTF8) is now the recommended character encoding for MySQL.
Minor layout improvements

FIXED BUGS

There was an issue in chart and pivot table reports where data values were misaligned when the dataset contained NULL values. For example, if you have a projects table, group by month(starting_date), and display the average hours spent, but January has no recorded hours, the February average would incorrectly shift to January. Fixed.
If PHP session.cache_limiter was set as nocache (default), DaDaBIK pages were not cached. However, results of HTTP API calls could be cached, returing old (wrong) results. Now, for all the DaDaBIK pages, cache is disabled.
If you dropped a table/view from outside DaDaBIK, without properly uninstall it before, the form configurator showed a blank screen. Fixed.
The documentation about the old upgrade procedure (upgrade.php/upgrade2.php) is now clearer, emphasizing that files and folders must be replaced and, in particular, folders should not be mergeed i.e. old files that are not included in the new package should be removed.
Form configurator: the rearrangement of the list of options for a select field did not correctly save. Fixed.
Some libraries used by DaDaBIK have been upgraded (TCPDF to v6.8.2, Chart.js to v4.4.8, TwoFactorAuth to v3.0.2, jquery UI to v1.14.1, Tafigy to v4.33.2). This fixes bugs and security issues that the version previously used by DaDaBIK could have, check the change log of each library for the details.
This item in the v12.5 change log contained an error. Incorrect: "Chart and pivot generation: if you aggregated data by Quarter or Month, the data items in the resulting report were not correctly chronologically ordered.". Correct: "Chart and pivot generation: if you aggregated data by Quarter or Week, the data items in the resulting report were not correctly chronologically ordered.". Fixed.
Live/Beta mode switch disappeared if sreen width < 991px, now only disappears if screen width < 768px.
Between screen-width of 768px to 991px, for non-admin-users, the language and user (with logout link) buttons disappeared. Fixed.
If, after having executed a search via omnisearch, in a table having lookup fields, you generated a chart or pivot table, DaDaBIK produced an SQL error. At the moment, omnisearch is not compatible with simple chart and pivot generation so starting from v12.6, the related buttons disappear if an omnisearch filter is active for the table.
Previously, DaDaBIK communicated with MySQL using UTF8, which only supports up to 3-byte characters. This caused certain characters, such as some emojis, to display incorrectly. Fixed: DaDaBIK now uses utf8mb4, which fully supports all Unicode characters, including emojis.
DaDaBIK sent a wrong header when exporting the app/db and producing the ZIP file. This, with some browsers, could lead to a broken download or a corrupted ZIP file. Fixed
Reports and grids you embedded in a page missed some of the styles and settings used by the main application: custom CSS styles were not applied, the graphic theme and the custom font were not applied, boxicons and fontawesome were not available and the charset was not correct set as UTF-8. The $force_reload_css_js = 1 setting also did not apply. Fixed.
Admin > Pages > Custom pages: the Rich Editor that appears when you click on hide/show HTML is now full width and it correctly renders bootstrap code.
Starting with v12.5, when you installed DaDaBIK (or install a table/view), by default none of the fields were included in the quick search form, so the OmniSearch field was displayed by default, however, during installation, this was true only for the admin group, now it is also true for the default group.
If you upgraded, using the standard up/up2 procedure, form a version < 12.4 and used MS SQL Server, the upgrade failed ("cannot find data type mediumtext") and your application could end up in an inconsistent state. Fixed.
Several typos fixed in config.php
The HTML plus button close to lookup fields always had ID "plus_btn"; this was not correct because we can have multiple buttons in the same form, therefore if you used this ID in your custom code you could experience unexpected behaviour. The name of the button is now "plus_btn_" plus the name of the field, e.g. "plus_btn_id_customer".
The pwd.php file (used to open the encrypter, not officially used anymore by DaDaBIK but could be still in use in some applications) was still using the Bootstrap CSS v3.x instead of the version currently used by DaDaBIK (5.3.2).

January 14, 2025
V. 12.5 Aveto

NEW FEATURES AND CHANGES

New OmniSearch feature: If Quick Search is disabled for all fields in a table, the OmniSearch form (a single-field, search-all textbox) will appear instead, allowing you to search across all compatible fields. Some new, related, config parameters ($enable_omnisearch_feature, $omnisearch_fields_to_include, $include_date_fields_omnisearch, $include_file_fields_omnisearch) are now available.

When you install DaDaBIK (or install a table/view), now by default none of the fields are included in the quick search form, so the OmniSearch field is displayed by default.
Two-Factor Authentication: the new config parameter $show_2fa_secret_code_text allows to set wheather to display the secret key as text in addition to the QR code during the user's first login. By default, it's disabled (0).
Simple pivot generation improved: for SUM(), AVG() and other functions, the name between parenthesis used in the resulting table header is now the field label, not the field name. The "add column" and "remove this column" textual links are now buttons.
The Admin > Data page has been improved for better readability.

FIXED BUGS

This bug "If, on an insert form, the user clicks multiple times the save button (and/or the enter button), multiple records could be inserted" was fixed with v12.0, however, it was still present for the "possible duplication" form in case users clicked multiple time the "insert anyway" button. Fixed.
When DaDaBIK was used with MariaDB, if for a table you enabled MariaDB's System Versioning, the table was not recognied by DaDaBIK anymore. Fixed.
Chart and pivot generation: if you aggregated data by Quarter or Week, the data items in the resulting report were not correctly chronologically ordered. Fixed.
Documentation about custom formatting function erroneously referred to custom validaton functions. Fixed.
New, search-related, unexpected behaviour has been added to the documentation: When you apply a custom formatting function to a field, the formatted display value is not considered during searches (including advanced search, quick search, or omnisearch). Instead, the search functionality relies solely on the raw value stored in the database.
For example, if a field's stored value in the database is "test", and your custom formatting function modifies how this value is displayed (e.g., showing "TEST FORMATTED"), searches will still use "test" for matching purposes.
This limitation does not apply to the formatting automatically applied by DaDaBIK for date fields using the $date_format setting. In such cases, the formatted date is fully compatible with the search functionality.
When, after a quick search, a search operator error occurred, the filter triggering the error was still stored and displayed in the quick search form, even if it had no effect on the results. Fixed.
When a "possible duplication" screen was displayed, the "insert anyway" button was not correctly displayed; futhermore, DaDaBIK produced a warning if one or more fields of the insert form were disabled (e.g. because they were calculated fields). Fixed
For date and timestamp fields, if the "ISO_8601" date_format was set, in some parts of the application the date was not correctly displayed and DaDaBIK produced a PHP warning. Fixed.
The datetime picker did not work and produced a Javascript error if the language set was traditionalChinese. Fixed.
The multilanguage support for labels, hints and tooltips did not work for traditionalChinese. Fixed. The language code to use for traditionalChinese is zz.
When traditionalChinese was set as language, DaDaBIK produced a warning message and the "collapse toolbar" tooltip was not displayed. Fixed.

December 14, 2024
V. 12.4.1 Aveto

FIXED BUGS AND CHANGES

When you added a new field to a table/view (from the DATA page or from the DB Synchronization page), the form configurator settings for these two parameters: 1) Show ONLY if (conditional) 2) Formula Field were lost. What you had as formula field for a field became the value of Show ONLY if (conditional) (third textbox) and viceversa. This means that after adding a field, for the related table/view, the conditional no-code rules and formulas stopped working as expected. Fixed.
When you created a view from the ADMIN > DATA page and "Install & enable tables on creation" was set to YES, if the view name contained uppercase letters, you could get an error (depending on your settings and Operating System) and the view was created but not installed. To avoid these problems, now VIEW names are always converted to lowercase before creation.
Documentation about formula fields now points out that, for aggregate functions, when you add/delete/edit records in a detail table, the formula field in the master table is updated only if you perfrom the add/delete/edit operation in the master/detail form. If you open the detail table as "standard" table (from the left menu or calling it by its URL), the formula field in the master table is not updated.
With v12.4, in form configurator, links to add/remove additional linked fields and items table were broken. Fixed. ***
Now formula fields, in case at least one of the placeholder is empty or the formula contains an aggregate function and we are executing an insert operation, returns NULL (before, it returned an empty string). ***
The value of a formula field whose formula contained an aggregate function (e.g. SUM()) was updated, after Create/Update/Delete operations on the related items table, only if the aggregate function was at the beginning of the formula. Fixed. ***
In form configurator, you could create formulas up to 500 characters, however, the corresponding field where the formula is stored was a varchar(255). this means that, depending on your DBMS, you could save without error a formula having length > 255 and get the formula truncated without noticing it. Fixed. ***
If a field having a formula field was set as required, DaDaBIK produced a required validation error during insert/update procedures. Fixed. ***
When you install DaDaBIK starting from an Excel/CSV file, for columns detected as integer, if "force string import" is not selected, an INT field is created in the database (before, a BIGINT field was created). Furthemore, now, if you use MySQL, "force string import" is not selected and an integer field has value > 2147483647 or < -2147483647, an error is generated and the installation stopped; before, depending on the MySQL version and settings, you could complete the installation without errors and got the imported integer values truncated (if higher than the max bigint number). ***
When you install DaDaBIK from a Excel/CSV file, the default data type mode is now "simple" (it was "advanced"). ***
During the installation from Excel/CSV, the fieelds automatic created by DaDaBIK for alphanumeric content having length <= 100 are now varchar(255) instead of varchar(500). ***
The upgrade to v12.4 using the up/up2 procedure did not delete the (not necessary anymore) include/fonts/manrope.woff2 file. Fixed. ***
Depending on the Operating System, the default font (Manrope) could not be used until the developer saved the Admin > Layout > Baisc at least once. Fixed. ***
Dropdown validation error typo fixed.

*** Depending on when you downloaded DaDaBIK, you may have this fix/change/new feature already available in your V 12.4

November 21, 2024
V. 12.4 Aveto

NEW FEATURES AND CHANGES

Formula fields
Formula fields are now available. They are simplified alternative to calculated fields, allowing dynamic field values without custom coding. Within the form configurator, each field can now optionally include a formula. For instance a final_price field could be set up with this formula:

({price}-{discount}) * 1.05

All the details in the documentation, chapter "Formula Fields and Calculated fields".
Related forum post.

The code that implements the new Formula feature is available in the new class /include/classes/Formula.php
Improved layout settings
The Admin > Layout > Basic settings page has been redesigned:
- It is now possbile to upload a custom Logo
- It is now possible to choose the text Font
- it is now possible to choose a theme from a list of twelve themes, each theme providing a collection of colors that define the look and feel of your application, alternatively, it is possible to choose your own custom colors.
Related forum post.
Improved Form Configurator
Form configurator: for the hard-coded list of options (now called cusotm list of options) and for the search operators you can now type words and press enter to insert an option or a search operator, which are now represented as tags. You don't need to use the tilde or the slash spearator anymore. You can also reorder the options and the operators just by draggin and dropping tags. In case for some reasons you prefer the old approach, you can set the config parameter $dont_tagify_form_config to 1. The form configurator has also been reorganized and improved for clarity.
Guessing relationship based on field names
DaDaBIK, during installation or while adding tables/fields, now tries to guess relationships among tables (and set fields as lookup) according to the names of the fields. For example the field products.brand_id, if a brands table exists having PK id, will be set as lookup table. Before, this was only done using referential integrity constraints (still used) and only on MySQL.
Cascade dropdown menus for search forms
Cascade dropdown menus now work in advancded search forms as well (if you enable this feature setting $enable_cascade_advanced_search_form to 1). They still don't work on quick search forms. Related forum post.
Most of the standard buttons ("Create new", "Advanced search", "Generate chart", ... and many others) have now a unique ID; this makes the application of custom CSS easier. The IDs all have the suffix "_btn". For the few buttons that already had an ID, their ID has not been changed, to keep backward compatibility. Related forum post.
Conditional rules (Show ONLY if & Conditional functions) always apply to edit and insert forms. If the new parameter $use_conditional_rules_for_details_pdf is set to 1 (as it is by default) now also apply to the details page, PDFs generated with the standard template and list view. For example, if you set a conditional rule to hide Field A when Field B is less than 10, this rule won't apply only to edit and insert forms—Field A will also be hidden on the details page, in PDFs, and in the list view when Field B is less than 10.
A new config parameter, $menu_hidden_tables, allows to set a list of tables and views you don't want to show in the left menu. This is a parameter you will rarely need, in fact you can control the permissions for a table from the Admin Area (Edit This App -> Permissions) and if you disable read permissions for a table, the table will not be displayed in the let manu. However, you may need to handle corner cases where the read permission is enabled but you don't want to see the table listed in the menu, these are the only cases where you need to set $menu_hidden_tables. Related forum post.
DaDaBIK during installation from excel/CSV can now use, as unique field, the firt column of the CSV or the first column of each Excel sheet
It is now possible to hide the header of the application for public pages, setting the configuration parameter $hide_header_for_public_user to 1. Another new configuration parameter, $hide_mobile_header_footer_for_public_user, allows to hide fixed header and fixed footer for small screens. Related forum post.
For fields having type TEXT and content NUMERIC, in the results grid, the cell alignment for their values is right (insteaed of left). Set the configuration parameter $align_right_numeric_values = 0 if you want to keep left allignment for all the columns.
If, during Excel/CSVimport, one or more required field values were missing, DaDaBIK produced a generic "You haven't filled out some required fields" and this sometimes was hard to intepret. Now the list of field labels is also displayed.
The max length of the function names you use for custom formatting, calculated fields, custom validation, custom CSV validation and custom required function is now 255 (was 500)
A new config paramter $permissions_upgrades_folder allows to set the default permissions for the temporary upgrades folder.
A login link is now available on the top right corner for the "public user". Related forum post.
The page name textbox in Admin > Pages is now larger
If you logout and there is an available public user, now DaDaBIK redirects to the homepage of the applicaiton, not to the login form.
The installation process has been improved in terms of clarity and user interface
Link to manual chapters added to custom buttons and operational hooks section in Admin > Automations
The import button is now before the export CSV button.
Shorter labels for "Export to CSV" buttons in English and Italian.
A new library, tagify, is now used in DaDaBIK and mentioned in the DaDaBIK license.

FIXED BUGS

The rules for table and field names are now more strict: apart from the already reserved words, the only characters allowed are now letters, numbers, underscore and hyphen. The use of different characters, even in DaDaBIK versions < 12.4, where the check was not performed, can lead to unexpected behaviour and security issues. You can change the allowed characters by editing the config parameter $valid_table_field_name_pattern and/or disable the names check by setting the config paramter $check_table_field_names to 0 but it is highly recommended that you keep those parameters as they are. The documentation (chapter: Known bugs, limitations and unexpected behaviors) has been updated to reflects this.
All DaDaBIK files now have stricter permissions: files are set to 644, directories to 755, and the file config_custom.php to 600. Prior to version 12.4, some files and directories had unnecessarily permissive settings, potentially introducing security risks. These updated permissions enhance the overall security of the application.
Upgrading DaDaBIK < 12.0 to V 12.1, 12.2 or 12.3 using the old upgrade/upgrade2 procedure generated an error. Fixed.
Some libraries used by DaDaBIK have been upgraded (TCPDF to v6.7.7, Chart.js to v4.4.6, Sortable.js to 1.2.15). This fixes bugs and security issues that the version previously used by DaDaBIK could have, check the change log of each library for the details.
Documentation: the example related to row-level custom filters now uses escape($current_user) instead of $current_user; without escaping, there could be unexpected behaviour and security issues.
Documentation about calculated fields now points out that to trigger a calculated field, records must be updated / inserted through the form. Calculated fields do not auto-calculate for pre-existing records without interactions and do not auto-calculate for SQL operations executed by your custom code, even if Custom Code API is used.
Documentation about 2FA now points out that to generate the QR Code, the API of qrsever.com is used. When the QR Code is generated, the following information is sent to qrsever.com: the username of the user, the name of the app ($two_factor_auth_app_name) and the TOTP secret. Being an HTTP(s) call, other information (for example your IP address, your browser, your OS) could be potentially stored by qrsever.com.
In some contexts / with some browsers, after a form submission using the Enter key, DaDaBIK produced a "unexpected error function ... " error. Fixed. Related forum post.
On SQLite, the content type of decimal fields was not correctly set, by default, to "numeric" and the corresponding related search operators were not set. Fixed.
If, for a user, you set Enable 2FA to 'yes' and the configuration parameters $two_factor_auth_app_name or $encryption_key are empty, DaDaBIK now produces an error.
When an advanced Pivot report contained more than five columns, DaDaBIK displayed empty values for all the columns after the fifth. Fixed. The columns limit is now 15 and if your advanced report query contains more than 15 coliumns, an error is displayed. Related forum post.
Documentation, for calculated fields, now points out that rich editors, as input fields for calculated fields, do not work.
Form configurator: typos in the in-line help have been fixed.
Installation process: two buttons did not correctly render with safari, this made their label unreadable. Fixed.

September 12, 2024
V. 12.3 Aveto

NEW FEATURES AND CHANGES

Two-Factor authenticaiton is now available. For further details, see the relevant chapter in the manual.
PHP 8.3 is now officially supported by DaDaBIK. To use it, you need ioncube loader V 13.3.x
New config parameter $data_add_field_default_nullable allows, if set to 1, to make by default a field nullable when you add fields from the admin area > data page. Default is 0.

FIXED BUGS

Config documentation, about custom user tables, said "You should leave the following 10 parameters as they are, unless you don't want to use your own custom users and groups tables."; there was a typo and the correct sentence is "... unless YOU WANT to use your own ...". Fixed.
Admin > Layout > Custom CSS: while the CSS box allowed the use of up to 2000 characters, DaDaBIK stored only the first 255 characters. Fixed.
After an upgrade process, a message suggested to clear the cache to load the latest CSS and image files. Also Javascript files, howver, may change so the message now states that both the layout and the functionalities may not render/work as expected if the users of your application (not only the admin, as the old message may suggest) do not clear the cache.

July 25, 2024
V. 12.2 Aveto

NEW FEATURES AND CHANGES

A new field type, "camera" has been introduced. It works similarly to image_file but with compatible devices (typically smartphones), the device's camera opens directly when the user clicks on "select file". A config parameter camera_capture_value allows to choose the front or the back camera. Read documentation (chapter "How to manage uploaded file") for further details and corner cases.
A new admin > layout parameter, "Max length results grid" allows to set the maximum number of characters displayed in the results grid for textarea fields (excluding HTML fields) .If you specify a number (e.g., 150), only the first 150 characters of longer texts will be shown, followed by an ellipsis (...).
A new config parameter, $pdf_page_format, allows to set the page format of the PDF you produce with DaDaBIK.
$grant_permissions_autoincrement_after_table_installation is now, by default, 0.
If the config parameter $grant_permissions_after_table_installation is set to 1 or 2, now the quick search permissions is not set to YES when you add a new field.
Fields containing 'picture' or 'image' in their names are now automaticaly set as image_file fields.

FIXED BUGS

When you inserted a record in a lookup table using the + button on lookup fields and duplication checking was enabled in the lookup table, the process did not work as expected if a duplication was found and you confirm insertion: the record was inserted but not set in the lookup field. Fixed.
V 12.1 upgrade procedure allowed to upgrade using the 12.0 file, it should have blocked the upgrade. Fixed.
The up/up2 upgrade process produced a generic error when the custom_php_files contained a subfolder. Now the error is more descriptive, subfolder are still not supported.
Form configurator preview says "To configure a field, click on its label", however, this did not work if the preview was for the details page. Fixed.
Custom code API methods load_table_page() and load_custom_page() produced an "Undefined variable $dadabik_main_file" error. Fixed.
Config file, about $enable_sql_logging, said: "operations you execute through hooks or other custom functions are not logged"; this, however, is not true if you use custom code API. Documentation fixed. Manual says that "Operations executed by custom code are not audited."; this, however, is not true if you use custom code API. Documentation fixed.
chart.js upgraded to v 4.4.3, this fixes bugs and security issues that the version previously used by DaDaBIK could have, check the change log of the library for the details.
If you installed a prepackaged app and tried to add a new table, you got a "General error: 1364 Field 'show_if_field_field' doesn't have a default value" error. Fixed.
In some particular MySQL cloud environments, the DaDaBIK installation produced this error: "Unable to create or change a table without a primary key, when the system variable 'sql_require_primary_key' is set.". Fixed.
The "Double click to edit" message was hard coded in English, now it uses the correct translation according to the language selected.
With large logo images, you got the wrong background color for the login form. Fixed.
pwd.php (the popup encryptor window), since V 12, is not needed anymore but was still used by some developers e.g. for allowing users management workarounds, and it produced an error. Fixed.
The change language dropdown menu, when the application was used through a mobile device or in general small screens, did not work. Fixed.
Documentation: added several videos produced in 2024.
When only one language is allowed in config_custom, the link to language selector in the header now disappears.
If you set $enable_user_password_modification = 0, the top right corner of the layout was not rendered as it should. Fixed.
Typos fixed.

June 3, 2024
V. 12.1 Aveto

NEW FEATURES AND CHANGES

LDAP authentication: two new config parameters $ldap_service_account_username and $ldap_service_account_password allow to set username/password pair to use for the first LDAP bind/authenticaiton, regardless of the username/password pair set in the login form by the end user.
A new config parameter $show_collapsed_menu_by_default (0|1) allows to show, by default, the menu collapsed. Parameter default is 0 (left menu is open unless the user closes it).
UI change: the main content area background is now white.
Left menu is now smaller (in width).
The option 'No PDF template' in the template listbox is now named 'Standard Template' in all languages. Since the sentence 'No PDF templates' was localized in some languages, check if 'Standard Template' works in your own language and let us know in case it does not.

FIXED BUGS

Permissions managers: fields set as "edit: yes but disabled" using a dadabik version < 12 appeared in the new (V 12.0) permissions manager as "edit: no", however, if you didn't save the field permissions, permissions still worked as expected. If you saved the field permissions, "edit: yes but disabled" for the current table/group permanently became "edit: no". For new "edit: yes but disabled" permissions you set using V 12, even if you saw in the permissions page "edit: yes but disabled", the DaDaBIK engine, in the application forms, treated these fields as "edit: no". Fixed. Suggestions to fix the wrong permissions and possible updates on this bug here: https://dadabik.com/forum/index.php?threads/field-permission-edit-yes-but-disabled-doesnt-work-in-v-12.24733/
The admin > menu > drag & drop feature did not correctly work if two menu items had the same "menu order". This still happens but now DaDaBIK detects duplications and warn you. For new installation and when you add tables/pages, this cannot happen anymore (unless you manually change "menu order") because DaDaBIK now assigns the highest value+1 to "menu order" considering all the page types.
If you were in Beta mode, the admin > menu > Drag & Drop feature did not work correctly and can also change the menu order of your (live mode) custom pages. Fixed.
The left menu sometimes did not correctly collapse. Fixed.
Version 12.0 introduced a new User Interface. The 12.0 changelog did not mention that new elements and changes in the UI may break some of the CSS custom code you used in V 11.
Documentation, beta dev mode: it is now mentioned that if you work in beta mode, before dropping/renaming fields in the Data page, you should put the system in maintenance status and set it back to available status only after having PUSHed the changed. It is also mentioned that if you work in beta mode with $use_db_name_beta = 1, if you have added / dropped / renamed fields in the Data page, you should put the system in maintenance status, manually (using PHPMyAdmin or any other db admin tool) apply the schema changes to your production DB, PUSH your changes and then set the system back in available status.
Produce a PDF with tabular data: the documentation now mentions that according to our tests, the TCPDF library in some cases my have problems in handling grids that split across pages, resulting in missing content and/or producing documents that according to Adobe Acrobat Reader are "malformed". Carefully test PDF tabular data before using it and use at your own risk.
V. 12 up/up2 procedure did not work correctly on some systems, producing PHP Warning: session_name() ... errors. Fixed.
PDFs generated by DaDaBIK did not display images anymore in V. 12. Fixed.
The config.php file still mentioned the 'letizia' password, not used anymore. Fixed.
CSS style of some buttons fixed.
The "menu" link in the admin home produced a "Unexpected table name communications " error. Fixed.
Charts: Y axis was displayed also when pie or doughnut charts were produced. Fixed.
Login form, logo area background should have been white, it was not. Fixed.
Several typos fixed, some English senteneces rephrased.

May 8, 2024
V. 12.0 Aveto

NEW FEATURES AND CHANGES

NEW Graphic User Interface
DaDaBIK finally has a new, more modern, UI. Among the (very long) list of changes in the front-end: new font, new colors, new icons, header completely redesigned, new side menu (icons are now supported, menu is now collapsable), other UI elements redesigned. Bootstrap 5.3.2 is now used for many elements of both the frontend and admin area. The admin area UI has also been partially revamped to make it more consistent with the front-end.
The BETA development mode
When you are in Beta mode, changes you make in the admin area (e.g. you change a form or you set permissions differently) or in your custom code (e.g. you add a custom validation rule) are only visible to admins and (optionally) to other trusted users.

When you want to make available your changes to everybody, you have to Publish your changes (PUSH).

Why is Beta mode useful? Especially if you are working on critical applications you want to test your changes before making them public. Before DaDaBIK 12, this was typically done keeping two different instances (on two different URLs, with two different DBs) of the same DaDaBIK application: a Development instance and a Production instance. This was time consuming because you had to maintain both and manually synch them once your changes to the Dev instances were tested. Starting from DaDaBIK 12, you don't need this anymore, from one instance of DaDaBIK, through the BETA mode, you can test your work before deploying them to your final users.

Only with DaDaBIK Platinum and only if you use MySQL or MS SQL Server you have an additional option: the use of a completely separated database when you are in Beta mode. (config parameter $use_db_name_beta): everything explained above is still valid when $use_db_name_beta is enabled, however, since you are working in a separate DB, when you are in BETA mode you can for example add test records to test your app and your final users will not see such records, the production DB will be kept clean.
Export a DaDaBIK application
You can now easily export an entire DaDaBIK application (files + DB) in one click, from the admin area. This is useful both for backup and for moving the application to another server. At the moment, only available if you use MySQL as DBMS.
No-code conditional fields
Conditional fields have been available in DaDaBIK for a long time, but you needed to code your conditional rules in PHP. You can still do it, for complex rules, but you can now set simple rules (e.g. show field A in a form only if field B = 'yes') directly from the form configurator, without any coding.
Richer Custom code API
Four new methods added:
delete_record(): delete one or more records
insert_record(): insert a record
load_table_page(): load a page (results_grid, edit, search or insert form, details page) based on a table, optionally adding a message
load_custom_page(): load a custom page, optionally adding additional input.

The old update_record() method is now called update_records(), to guarantee backward compatibilty, update_record() still works.
Improvements in the admin area (in addition to the revamped UI)
- The new "Menu" tab shows a preview of your application menu. The menu is sortable by dragging and dropping menu elements. Yes, you don't need to get crazy anymore trying to sort your menu elements.
- Permissions manager now uses - time savers - toggle switches instead of drop down selects.
- Form configurator: you can now choose which field to configure by clicking on its label in the form preview.
- New config param. $show_set_yes_no_all_combinations_links, by default 0.
New installation option: create an app describing it in plain English (using Artificial Intelligence)
The new option uses AppifyText.ai (DaDaBIK's sister application), the app created can then be deployed to DaDaBIK.
The hated encrypter popup is gone, forever
When you add a new user or change, as admin, the password for an existing user you no longer need - finally! :) - the encrypter popup window anymore. You write the password in the password field and DaDaBIK automatically encrypts it before storing it in the database. In the edit form, if you leave the password field blank, the password is not modified.
It is now possible to set, for standard "save" and "insert as new" buttons in edit and insert forms, a confirmation message. Check the documentation, "Customize standard buttons" chapter.
Change: themes (classic, bluegray, black, blue, green) are not available in DaDaBIK 12, at the moment there is only one theme that can be customized using custom CSS. Built-in alternative themese will be probably introduced again soon.
DaDaBIK has now a default favicon and icon. The related files are all in the root and their names are favicon.ico, apple-touch-icon.png, favicon-32x32.png. In case you already have one or more files in your installation, DaDaBIK, during the upgrade, will not overwrite them (only for the existing files).
Form configurator: parameter "Custom display / required function" is now called "Conditional field function" and the inline hlep contains a code example and a link to the corresponding chapter in the online documentation
The db_name parameter in config.php is now better explained
Save+go back and "insert as new" butttons now do not appear on small screens
The "menu type" layout parameter has been removed: since the left menu is now collapsable by the user, the "left_side_menu" type is the one always used.
If you enable password validation ($enable_password_validation = 1), your custom error message must now be in $normal_messages_ar['password_not_valid'] and not in $error_messages['password_not_valid'] as it used to be.
The support for the old jQuery datepicker has been dropped. Now the only supported datepicker is flatpickr.

FIXED BUGS

The method update_record, if revisions for the updated table was enabled, registered after update, in revisions, the wrong version of the record (the version before the update instead of the version after the update). Fixed. Check next fixed bug in this change log for a strictly related bug.
The custom code API method update_record, to decide if the update operation needed to be registered in revisions, checked if revisions were enabled in the table currently used in the front-end and not in the table that needed to be updated. For example, if an insert into a table movements, executed through the standard DaDaBIK interface, produced, using hooks, also an update on the table warehouse, made using custom code API method update_record(), the revision on the table warehouse was registered if revisions were set on table movements (it should have been registered if revisions were enabled on table warehouse, instead). Fixed.
If, on an insert form, the user clicks multiple times the save button (and/or the enter button), multiple records could be inserted. Fixed.
After the execution of the up/up2 upgrade script, all the DaDaBIK files (except your custom files) are replaced with the new versions; the file permissions assigned by default to those files may differ from the previous ones so, after upgrading, you should check the (maybe changed) file permissions to be sure they are as you like. The up/up2 script did not mention this important note, now it does.
The X-Content-Type-Options header has been added and set to 'nosniff'. This helps preventing attacks based on MIME type confusion.
Tooltip HTML content in form was not sanitized. Even if the content comes from admins and not from final users, for security reasons is now sanitized.
On DB connection error, now DaDaBIK stops the execution of the script, before V 12, the execution continued and a possible subsequent query obviously failed, showing the related error message.
The old (upgrade/upgrade2) upgrade procedure (as the new up/up2 already did) now points out that during the execution of the backup and until the upgrade process is over nobody should use the application or access the database.
With DaDaBIK PRO, the use of the method update_record() triggered an error. Fixed.
Documentation now points out that When you execute SQL in your custom code (even when Custom Code API is used, see later), permissions are not checked.
The documentation (Audit/Revisions chapter) now points out that if in your DBMS the transaction isolation level is set to a level lower than "Repeatable reads" (e.g. this happens by default in MS SQL Server, the default isolation level is in fact "Read committed"), it may happen that, if a "delete all" or "delete selected" operation is concurrent to an insert/update/delete operation on the same table, DaDaBIK doesn't correctly register in revisions, as deleted records, all and only the records actually deleted.
The documentation now points out (new "known bug" added), that while applications you create with DaDaBIK support multiple, concurrent, users (record locking and other mechanisms are used to prevent data loss or unexpected behaviour when multiple users are working on the same data), the ADMIN area (the area you access when you click on "Edit this App") is not designed for supporting multiple concurrent developers working on it: two admin users (or the same users accessing from two different clients/browser tabs) working at the same time on the admin area of the same application, could lead to unexpected and unpredictable behaviour.
Custom code API, update_records method: the documentation now points out that 1) If SQL logging is enabled, your UPDATE query will be logged. 2) If revisions are enabled for the table, the records updated will be tracked by revisions, however there are cases when the revisions are not correctly registered (see the documentation for further details) 3) Automatic email notices ($enable_update_notice_email_sending = 1) are not sent. 4) Data validation is not executed
If, in the insert and edit forms, custom required/conditional functions and calculated functions ajax calls did not reply as expected (e.g. for a network problem or any other issue) and consequently did not work (not calculating / not hiding / not making required fields in the form the user is filliung), no error message was displayed to the user. The required/conditional and calculated functions were, however, executed again, server-side, after pressing the save button (and in this case, everything worked as expected), this means for example that a field could have been calculated without the user knowing about it. Fixed.
Some libraries used by DaDaBIK have been upgraded, this fixes bugs and security issues that the version previously used by DaDaBIK could have, check the change log of each library for the details.
- TinyMCE, the rich-text editor we use in the front_end for the rich_editor field type and in the admin area for the rich editors we have in pages tab > custom pages, has been upgraded from V.6.4.0 to V.6.8.3. This fixes bugs and also security issues of the old version (we now set the new TinyMCE parameters sandbox_iframes and convert_unsafe_embeds to TRUE, sandbox_iframes is TRUE, HOWEVER, only for TinyMCE used in the frontend, not for the ones you have in the admin area ). Please note that V.6.8.3 is not the latest TinyMCE version, V7.x has been released but its license has been changed and the new license seems not compatible with the DaDaBIK's license, consider this and check TinyMCE change log if you decide to use rich_editor in your DaDaBIK applicaiton.
- The bootstrap library (both CSS and JS), when used in the up/up2 scripts, has been upgraded from from V4.5.2 to V5.3.3. The bootsrap library used in the rest of the code, which used to be CSS only, has been upgraded from V3.3.7 to V5.3.2.2 (NOT 5.3.3 yet) and now also includes the bootstrap JS.
- TCPDF has been upgraded from V.6.6.5 to V.6.7.5
- Chart.JS upgraded from V.4.4.0 to V.4.4.2
The up/up2 upgrade procedure now check if PHP can write on the DaDaBIK root folder before continuing
Master/details form, the (disabled) lookup field representing the primary key of the master table showed the + sign to add a new item, this was not correct, removed.
A unique field having a quote in its value prevented the form configurator preview to work correctly. Fixed.
For insert_date_time and update_date_time fields, in the quick search form, if you selected "between", the first datepicker was displayed as a date only picker and not as a datetime picker. This, assuming you have $date_picker_type = 'flatpickr' (as it was by default). Fixed.
The "double click to edit" message in results grid incorrectly appeared on fields 1) Whose edit permission was "Yes but disabled" 2) Whose edit permission was "Yes" but edit permissions on the related table was "No". Fixed, now the message does not appear (please note that the actual update was not allowed, even before the fix, though).
In the english_custom.php file, it is now mentioned that if you are editing a prepackaged app, the file to edit is english_custom_prepackaged_app.php.
Documentation, custom buttons: the documentation did not specify that the label of a button whose label_type was "language_file" must be set in the normal_messages_ar array. Fixed.
DaDaBIK warned about the fields of both custom users and custom groups tables even if just the user or just the group table is custom. Fixed.
Long file names as source for custom pages were not recorded correctly in Admin > Pages. Fixed. Now file names up to 100 characters are correctly saved.
Documentation now clearly states that operational hooks are never triggered by SQL operations executed by your custom code, even if Custom Code API is used.
Documentation now clearly states that the DELETE hooks are not triggered by "delete all" or "delete selected" operations (only "delete all" was mentioned)
Conditional fields, improved documentation: the possibility that $granual_permissions is set to 0 is now considered.
When a select_multiple* nonlockup field was NULL, a "Deprecated: explode(): .... " error was produced. Fixed.
config.php did not mention that, if you use a custom users table, your table must have a set of fields whose name is pre-defined (in addition to other fields you already have). Fixed.
Config.php documentation improved.
Documentation still mentioned the default password "letizia", not used anymore. Fixed.
When using the application as public user, the login link had "logout" tooltip insted of "login". Fixed.
the up/up2 upgrade script now checks if the ZIP extension is installed
In the advanced search form, the fields were too close to their search operator. Fixed.
Typos fixed.

November 30, 2023
V. 11.12 Elba

FIXED BUGS

DaDaBIK suffered from a SQL injection vulnerability which could allow an attacker to execute arbitrary SQL code by sending properly forged data to a DaDaBIK URL. The attacker needed to be logged in DaDaBIK; however, if you have disabled authentication or you have set a public user, the vulnerability could be exploited by a non-logged user as well.
The kind of SQL operations allowed depended on the permissions granted to the database user ($user in config.php) and the SQL code could be executed (if the user had the permissions) even on other databases, different from the application's database. The permissions we are referring here are the DBMS permissions (e.g. the MySQL permissions) not the DaDaBIK permissions you set in the permissions page. The vulnerability has been fixed.
DaDaBIK could not generate correctly PDFs if one or more fields available in the details page are not available in the results grid. Read all the details here: https://dadabik.com/forum/index.php?threads/pdfs-that-uses-fields-available-in-the-details-page-but-not-in-the-results-grid-are-not-correctly-generated.24541/. DaDaBIK 11.10 was silently upgraded to fix this but the fix was never mentioned in the changelog.
The instructions of the file english_custom.php mentioned a engliish_custom_template.php file, the name was wrong, it's english_custom.php. Fixed.
Documentation about audit/revision now mentions that if an update operation changes the primary key/unique field value for a record, the revision will not be correctly registered: it could be NOT registered or registered as linked to another (wrong) record.
Documentation about audit/revisions said: "if you change the primary key for your table or you change the primary key value for a record, you will lose the link with the related revisions". "Primary key" is now mentioned as "primary key/unique field" to highlight that you may have set, for a table, a unique field that is not the Primary Key.
With $enable_user_password_modification = 0 and $enable_forgotten_password = 1, DaDaBIK produced an SQL error. Fixed.

September 27, 2023
V. 11.11 Elba

NEW FEATURES AND CHANGES

PHP 8.2 is now supported.
Communications with dadabik.com (for example to check for new releases) are now possible even if allow_url_fopen is disabled, the cURL extension (if available) is used.
What you set in Admin > Layout > Custom CSS is now read even if $dont_use_admin_config = 1.

FIXED BUGS

When an insert or edit form was displayed on a mobile device, the gap between the label and the field was too big. Fixed.
Depending on your system, if you used, as $date_format, "literal_english" you could have problems displaying dates prior to a certain date or after a certain date. This was documented in config.php and documentation said "prior to 01-01-1970 or after 19-01-2038", but the actual dates could change depending on your system. Fixed, now literal_english can correctly display also dates prior to 01-01-1970 or after 19-01-2038.
If $dont_use_admin_config was set to 1, the admin > data page showed some warning message and the DATA settings (Data types: simple/advanced, Install & enable tables on creation: yes/no) were not read correctly. Fixed.
A konwn bug related to the loss of the DaDaBIK session when used in combination with WordPress has been added to the documentation, check here for additional details.
Some libraries used by DaDaBIK have been upgraded (TCPDF upgraded from v6.6.2 to v6.6.5, jQuery upgraded from v3.7.0 to v3.7.1, Chart.js upgraded from v4.3.0 to v4.4.0, htmlAwed version upgraded from v1.2.14 to 1.2.15). This fixes bugs and security issues that the version previously used by DaDaBIK could have, check the change log of each library for the details.
Starting from DaDaBIK V 11.8, even if terms/privacy checkboxes were not enabled ($show_accept_terms_privacy_checkbox_registration_form = 0), users self-registration could stop working and ask for missing fields. Fixed.
With DaDaBIK enterprise monthly edition, you got a "serial not valid" or similar error message during an upgrade process (up/up2 method). Fixed.
Having, as an hard-coded option for select_single/select_multiple fields, a value containing quote, double quote, backslash or the NUL byte (the list of characters can be shorter, depending on the DBMS used) caused, during insert or update (even via file import), false positives or false negatives during the dropdown validation (check config parameters $dropdown_security_form_check and $dropdown_security_csv_check): a dropdown validation error for content that is correct (false positive) or no dropdown validation error when the content should be blocked (false negative). Fixed.
Having a database field with name "operator" could lead to unexpected behaviours: it could trigger a wrong "attack 06" warning or it could impact on the execution of an advanced search, using the OR operator (any of the conditions required) instead of the AND operator (all the conditions required) or viceversa. Now, if you have a field whose name is "operator", DaDaBIK alerts you (if the config parameter $check_table_field_names is set to 1, as it is by default).
For the release of V 11.9, we wrote: "some additional countermeasures have been now adopted to prevent session stealing in case other XSS vulnerabilities come up in the future: session cookies are now httponly so they cannot be read via Javascript, this works with all the recent versions of the most popular browsers and require you have PHP session.auto_start = 0 (as you probably already have), futhermore, the session cookie is now destroyed after logout". This was done for the session cookie used by DaDaBIK in case of standard login, but not for the session cookie used by the Wordpress Plugin. Now, also that cookie is httponly (the WordPress plugin has been updated). About destroying the cookie after logout, it is not done in case of Wordpress logout.

July 13, 2023
V. 11.10 Elba

Watch the release video

NEW FEATURES AND CHANGES

The query executed for building the results grid has been optimized: only the fields allowed in the results grid are now selected. Before, the fields allowed in the results grid + the fields allowed in the details page were selected. This, in some situations, could lead to a huge performance improvement, especially if the fields now excluded from the select are lookup fields.
A new configuration parameter, $use_long_select_query_for_count, when set to 0 (default is 1), potentially allows for drastic performance increases when searching and browsing the results grid. To count the results of a search, instead of using the same query used to display the results, a simple SELECT COUNT(*) is used. It is recommended to set this parameter to 0 unless you are having problems.
Performances improvement while opening the insert form: in case you used, for a lookup field, an SQL-based or custom function default value, the query (or the function) could be executed by DaDaBIK multiple times (instead of just once): this could lead to a huge delay when you opened the related insert form. The query/function is now executed only once.
A new $date_format, "ISO_8601" has been added. E.g. May 31, 2023 is displayed as 2023-05-31.
A new language, Traditional Chinese (zh-tw), is now available. Thanks to our user Andy Li who provided the translation.

FIXED BUGS

Form configurator, inline help, search operators parameter: the documentation about how searches on select_multiple_* fields work was wrong. Fixed.
If, in the same form, you mixed in your custom required functions the current (return 'show' and 'required' info) approach and the legacy (only return 'required' info) appoach, you could get unexpected results: a field could be hidden by DaDaBIK even if it was supposed to be displayed. Fixed.
Edit permissions set to MY prevented uploading files for image_file and generic_file field types if AJAX upload type was set (as it is by default). Fixed.
Some libraries used by DaDaBIK have been upgraded (JQuery from 3.6.4 - and 3.5.1 for the up2.php script - to 3.7.0, Chart.js from 4.2.1 to 4.3.0, htmLawed from 1.2.11 to 1.2.14). This fixes bugs and security issues that the version previously used by DaDaBIK could have, check the change log of each library for the details.
Documentation: it is not pointed out a new, known, unexpected behaviour: If a user has insert or edit permissions on a table and the table contains at least a field set as image_file or generic_file, the user may be able to upload a file even if they don't have edit/insert permission on the file field. The file, however, would be stored only in the file system, in the system temporary upload folder and in the dadabik upload folder, without be recorded in the related record.
The dcoumentation says that the "check for duplicated" feature causes uploads to fail during insert; it is now pointed out that this is true only if the "classic" upload type is set.
config.php: the examples for numeric_english and latin $date_format were not completely correct, May is displayed as 05, not 5. Fixed.
Documentation: it is now pointed out that in two cases, row-level custom filters let appear values that should be filtered out (see documentation, row-level custom filter for additional details.
Documentation, known bugs section, Added link to the bugs forum to check new bugs as they are discovered.

March 23, 2023
V. 11.9 Elba

Watch the release video

NEW FEATURES AND CHANGES

New Custom Code API functions: update_records() and count_records(). Custom Code API functions are now methods of the ddb_api class. Check the documentation for all the details.
DaDaBIK, by default, sent all the email using the mail_custom() function defined in /include/general_functions.php. A new config parameter, $custom_mail_function, allows to define your own custom function; this is useful, for example, if you want to send messages using a library such as PHPMailer.
if live edit is enabled, a "double click to edit" message is displayed when the mouse is over a text, textarea, date or date_time field cell. You can disable this by setting the config parmeter $show_double_click_message to 0. ***
The self-registration email confirmation message was hard-coded in English (both subject and body). You can now customize it according to the language.
You can now call PHP Custom Pages and get JSON replies using DaDaBIK HTTP APIs (Platinum edition only), check the documentation for the details.
Wider menu order box in the admin > pages form.
The admin area has now a white background. ***
Style of the datagrid heading slightly changed. ***

FIXED BUGS

An XSS vulnerability has been fixed. The vulnerability could be exploited if graph generation was enabled ($enable_report_generation = 1, as it is by default) and allowed an attacker to execute arbitrary javascript code uring a forged URL. This means, for example, that an attacker A could send to a user B of your application an URL to open; if B opens the page, their cookies (related to the DaDaBIK app) could be read and send to A, allowing A to steal B'session and impersonate him/her in the application. A patch to the vulnerability was already delivered through the newsletteron Jan 30 and DaDaBIK 11.8 was silently patched on Jan 31 so if you downloaded DaDaBIK after Jan 31st or if you applied the patch described in the newsletter message, your version is already patched. However, some additional countermeasures have been now adopted to prevent session stealing in case other XSS vulnerabilities come up in the future: session cookies are now httponly so they cannot be read via Javascript, this works with all the recent versions of the most popular browsers and require you have PHP session.auto_start = 0 (as you probably already have), futhermore, the session cookie is now destroyed after logout. It is strongly recommeded, after upgrading to DaDaBIK 11.9, to change your $dadabik_session_name.
Some libraries used by DaDaBIK have been upgraded (TCPDF from 6.5.0 to 6.6.2, jQuery UI from 1.12.1 to 1.13.2, jQuery from 3.6.1 to 3.6.4, Chart.js from 4.0.1 to 4.2.1, TinyMCE from 6.3.0 to 6.4, htmLawed from 1.2.10 to 1.2.11 ). This fixes bugs and security issues that the version previously used by DaDaBIK could have, including a TinyMCE XSS vulnerability, check the change log of each library for the details.
TinyMCE could behave in an unexpected way in DaDaBIK V 11.7 or lower, this has been fixed in V 11.8 and not mentioned in the 11.8 change log.
Upgrading a DaDaBIK V <= 10 could produce errors. Fixed.
The Before Insert and Before Update operational hooks did not work correctly: for any field except from image_file fields, the corresponding value of the array was NULL; for image_file fields, the hook could triggeer a PHP error or store an empty value value instead of a NULL value in case the field was empty. The related documentation contained a mistake, it stated that before insert hooks "receive as input an associative array containing all the values the user filled in the update form" (it should be "insert form"). Fixed. ***
Forms were not corretly rendered (wrong alignment) in Safari 16.x. Fixed
The readme file and other documentation/test files related to the library htmLawed were old and not related to the actual library version released with DaDaBIK. Fixed.
In form configurator, two fields of the dadabik_users table had the same order (10); this didn't produce any proper malfunction and the upgrade process will not fix that for existing applications but for new installations this issue is fixed.
DaDaBIK produced some "DevTools failed to load source map" error messages in the browser console. Fixed.
The Dutch language has been updated. Ronny Vanblaere and Hendrik Simoens are the new official translators for Dutch.
DaDaBIK produced a notice: Undefined index message if $dont_use_admin_config was set to 1. Fixed
The "Automation" tab in the admin area could trigger an "Undefined variable $normal_messages_ar" error. Fixed.
An explanation and a fix for the 'favicon.ico' bug, that could trigger an "You don't have or have lost your lock on this item" error, has been added to the FAQs
On MySQL, is you set as $db_name a DB that does not exist, DaDaBIK tries to create it during a 'blank app' installation process. However, the database was created using the default charset instead of utf8mb4, the charset strongly suggested for DaDaBIK. Fixed. ***
When you get an 'attack 02 message', sometimes is just a false alarm due to the fact you drop a field you were ordering by. Instead of getting stuck, you can now reload the page and fix it. ***
In some particular cases (typically on Windows machines), the ionCube loader was not able to find the files included by DaDaBIK; this caused to fail the execution of install.php. Fixed (the inclusion method has been changed in the DaDaBIK's code). ***

*** Depending on when you downloaded DaDaBIK and which edition you downloaded, you may have this fix/change/new feature already available in your V 11.8

December 5, 2022
V. 11.8 Elba

Watch the release video

NEW FEATURES AND CHANGES

During the installation, DaDaBIK now asks an installation password, it is used for all the default users created by DaDaBIK during the installation. Goodbye to the good, old, default "letizia" password :)
A new "Layout" tab in the admin area allows to: set some basisc layout parameters (e.g. logo, menu type) without using the config_custom.php file and set custom CSS without editing the styles_screen_custom.css file. A new configuration parameter $dont_use_admin_config (by default, 0) allows to continue using the config_custom.php file for the basic layout parameters instead of the new admin page.
It is now possible to show up to 3 checkboxes (e.g. "I accept the terms / privacy" checkboxes) to the user (self) registration form. You can configure labels and requiredness. Check the new config param $show_accept_terms_privacy_checkbox_registration_form for details.
After login ($hooks['login']['after']) and after user self-registration ($hooks['user_self_registration']['after']) operational hooks are now available.
A new layout hook: login_form (before) is available ($hooks['login_form']['before']). The typical use will be for adding some login / registation instructions to your users.
Menu page custom names are now available: you can specify a different page name (and menu item) for table/view pages according to the user group. E.g. "group1:Customers~group2:My account". The feature is enabled by default, you can disabled setting the config param. $enable_menu_page_custom_names = 0.
The new "Automation" tab in the admin area allows to see the email alerts, operational hooks and custom buttons set.
The logo now links the home of the application (you can disable this by setting the configuration parameter $link_logo_home to 0).
In the result of the upgrade script, the release notes are now showed more clearly
Data page: if you create a table whose name contains a blank space or a dot, DaDaBIK now automatically replace those character with an underscore.
The ID of custom pages is now showed in Admin > Pages > Custom page. This could be useful if you need to manually create links to the custom pages in the form index.php?function=show_static_page&id_static_page=XXX
A new config parameter, $show_back_button, allows to hide the back button in the forms.
A new config parameter, $show_first_last_name_registration_form, allows to hide first and last name fields in the self-registration form.
A new Feedback page in the Admin Area allows to send feedback to us directly from your DaDaBIK application.
PDF, Reports and Import buttons show up also for PRO edition: those features, however, are not available, you can set the related configuration parameters to avoid displaying them.
Admin home text improved.
Default theme is now 'bluegray' (was 'classic')
New config paramter $default_install_enable_tables_on_creation
Installation documentation improved (better config_custom example for newcomers)
Form configurator: all the low-code settings (custom functions) have been moved at the end of the page.
Data and permissions tabs improved (data: added link to form config and more)
Admin > Relationships tab improved, better explanation + 2 short video tutorials.
In the data section, for each field is now displayed the linked table, if the field is a lookup field.

FIXED BUGS

Documentation: it is now pointed out that DaDaBIK set the PDO ATTR_STRINGIFY_FETCHES attribute to TRUE (and therefore you will always get PHP strings when you fetch records. This may impact on your custom code, while at the moment we are not aware of changes/issues with the DaDaBIK core code. For a detailed discussions about this, check https://dadabik.com/forum/index.php?threads/a-very-important-dadabik-patch-especially-if-you-are-using-php-8-1.24377/
Some wrong behaviours / security issues that could be experienced if authentication was disabled ($enable_authentication = 0) have been fixed, in particular:
1) By directly calling the RELATED "show_file" URL, a user could see an attached file without having the read permissions on the related table A nor its master table B if, for table A, they had the CREATE permissions.

2) AJAX upload did not work and produced PHP errors or warnings

3) $enable_lookup_insert_popup: this feature allows users, for lookup fields, to add an option to the listbox without leaving the current form (insert popup page) and did not work (and produced PHP errors or warnings) if $enable_authentication = 0
Some wrong behaviours / security issues that could be experienced if granular permissions were disabled ($enable_granular_permissions = 0) have been fixed, in particular:
1) By directly calling the RELATED "show_file" URL, a user could see an attached file without having the read permissions on the related table A nor its master table B if, for table A, they had the CREATE permissions.

2) AJAX upload did not work correctly, in particular DaDaBIK checked, once per login, the insert or update (depending on the form) permissions needed to upload a field from the granular permission even if $enable_granular_permissions was 0. This means that a user in some cases could upload a file even if the insert or update permissions were not granted or could not complete the upload even if the insert or update permissions were granted

3) enable_lookup_insert_popup: this feature allows users, for lookup fields, to add an option to the listbox without leaving the current form (insert popup page) and did not correctly work (and produced PHP errors or warnings) if $enable_granular_permissions = 0
If you used a lookup field, you enabled "Use ajax to load options" in form configurator and one of the linked fields could contain NULL values, the field didn't work correctly: when you typed in the lookup field, the (matching) options having at least one NULL linked field didn't show up. This bug apparently did not occur if you used MS SQL Server, at least for some versions/configurations. Fixed.
Only with MySQL, if, in ADMIN -> DATA tab, you renamed a field and this produced a MYSQL error (e.g. you also changed the field type from SHORT TEXT to INT and you had already some alphanumeric content stored), the result was an incosistent state: the DB field was not renamed in the database but DaDaBIK thought it was (so, for example, in form configurator you saw the new field name). Fixed.
If you used a custom users table, the up/up2 procedure, during an upgrade to V 11.7, should have told you to add a new field, ids_group_others TEXT NULL to your table; in some cases, however, this message did not appear. Fixed.
If you upgraded from a version < 6.3 using PostgreSQL or MS SQL Server, the upgrade procedure did not work correctly and produced an error. Fixed.
For certain versions of MySQL, integer fields types were not recognized in the admin>data page if you set Data types to simple and therefore you got the blank option selected for the field type when you opened the data page. Fixed.
Some libraries used by DaDaBIK have been upgraded (jQuery to v 3.6.1, jQuery dirrty to V 0.8.4, TCPDF to v 6.5.0, Chart.js to v4.0.1, flatpickr to v4.6.13, Tinymce to V 6.3.0, HTMLawed to V 1.2.10). This fixes bugs and security issues that the version previously used by DaDaBIK could have.
When you embedded a results grid and the number of results to show was zero, DaDaBIK displayed not only the grid but also the header, menu and footer of your application. Fixed. (bug report: https://dadabik.com/forum/index.php?threads/iframe-shows-complete-homepage-when-there-is-no-record.24385/)
Documentation: we now point out that operational hooks are not triggered by SQL operations executed by your custom code.
If you disabled authentication or granular permissions, in permissions manager, the inline help for READ was not updated to the latest version. Fixed. In particular it now points out that 1) if you set READ NO for a table/view, users can still read its records if the view/table is used as source for any lookup field (only select_single was mentioned) 2) to see the details page of your records, you need to set DETAILS:Yes and READ:Yes; however, if CREATE is Yes, DETAILS:YES is enough (the user will be able to see the details page of a record if they know its URL, even if the table is not displayed as a menu item).
Form configurator, in-line help for "Use ajax to load options": it has been pointed out that if you use PostgreSQL, all your Lookup table linked fields must have a String data type (e.g. Varchar or Text) in your Database, otherwise the Ajax loading does not work correctly (this was not true before V 11.8).
ADMIN > DB SYNCHRO: if you added fields to a table that hadn't any field to add, DaDaBIK triggered two PHP error messages. Fixed.
A new known bug has been added to the documentation: When you add a record to a lookup table using the + sign close to the lookup field, if a possible duplication is detected, the process is not correctly completed (the record is inserted but the lookup field in the underlying form is not updated).
Documentation updated, all the old videos embedded have been replaced with new (2022) video chapters, if available.
Documentation: the javascript button example erroneously pass the variable "field" to the custom javascript function. Fixed.
DaDaBIK could produce a "deprecated" message when used with PHP 8.1. Fixed.
Documentation: there was a typo (additional, wrong, parenthesis) in the startup function code example. Fixed.
The documentation now points out that after an upgrade, if you changed the edition (e.g. from pro to enterprise) you must replace the serial number in config_custom.php with the new number you got.
If the config_custom.php file started or ended with blank spaces or new line characters, the upgrade procedure (up/up2) failed. Fixed.
In the admin section, DaDaBIK now checks if you have any select_multiple fields that is allowed in a quick search form and, in case, produces a warning (select_multiple fields do not work correctly in quick search forms, check known bugs).
Upgrading a V <= 11.4 to 11.7 using the up/up2 procedure generated an error. Fixed.
Config file, $enable_access_logging parameter, we now point out that at the moment, only the standard logins executed through the form (no WP login, no HTTP APIs login) are logged.
After installation, the group "normal" is mentioned instead of "default". Fixed.
"uncaught" Javascript error message could appear in some cases during installation. Fixed.
Some error messages are now, hopefully, more clear.
Typos fixed.

August 18, 2022
V. 11.7 Elba

NEW FEATURES AND CHANGES

DaDaBIK now supports PHP 8.1.
It is now possible to assign more than a group to the same user. If the new config parameter $enable_multiple_groups_permissions is set to 1 (by default it is) the permissions for a user will be computed considering all the groups the user belongs to (main group + additional groups), using a most permissive strategy. You can check the resulting permissions for each user in the new Permissions -> Show user Permissions page. All the details in the documentation, chapter "Permissions based on multiple groups".
If the database $db_name you specify in your config_custom file doesn't exist, DaDaBIK tries to create it. This allows to create an application with DaDaBIK without using any external tool, not even for the cration of an empty database (experimental feature currently available for MySQL only).
Custom code API. A set of API functions will be released to make your custom code leaner and more secure. In V 11.7, the first function, get_record_details(), has been released. In one code line you can get the field values of a record belonging to any of the tables you have in your database, without directly executing SQL queries. Further info in the new documentation chapter "Custom Code API".
The library htmLawed, used to sanitize HTML, has been upgraded to V 1.2.9. This fixes bugs and security issues that the version previously used by DaDaBIK could have.
In addition to $current_user (containing the username of the currently logged user), a new global variabile, containing the ID of the currently logged user, $current_id_user, is now available.
For before insert and before update hooks, for file fields now the parameters passed, in case a file is not specified, is NULL instead of empty string.
The minimum required PHP version is now 7.2.
When importing from CSV, the end of line \r character (without 1n) (used by old MacOSs) is no more recognized.
When a query error is generated a message now suggests to logout and login again to clear possibly wrong search filters.

FIXED BUGS

After having imported an XLS/CSV/ODS file and even if the import was successfull, you could get an SQL error, related to the ambiguity of a field, when you tried to see the imported records. Fixed.
Self registration: if the user or the email was already in use, instead of displaying a user-friendly message, DaDaBIK triggers a DBMS error. Fixed.
Self registration: if $enable_password_validation was set to 1, in case of validation failure DaDaBIK didn't show the custom 'password_not_valid' message and triggered an undefined array key message. Fixed.
If you had a before update or before insert hook in a form containing a file field and the $upload_field_type was ajax (default), you got an error if you submit the form without uploading a file. Fixed.
After an upgrade to V. 11.6, DaDaBIK showed this message "Starting from V 11.6, if $show_grant_permissions_message is set to 1 or 2, permissions are granted not only after a table installation but also after having added a field (from the data page or by synching).", the parameter, however, is $grant_permissions_after_table_installation and not $show_grant_permissions_message. Fixed.
If you upgraded from V. < 10 and you used MS SQL Server, DaDaBIK produced an error related to the column url_installation during the upgrade process. Fixed.
After an upgrade, even if DaDaBIK was upgraded to the latest version, a "New version available" message could be displayed until the user logged out and logged in again. Fixed (for the user who executed the upgrade).
Even if $dont_show_menu_if_only_one_item was set to 0, the left menu was not displayed when the number of menu items was 1. Fixed.
Typo in about page fixed

June 14, 2022
V. 11.6 Elba

NEW FEATURES AND CHANGES

Permissions templates are now available: you can add rules to your config_custom file to set, automatically, your granualar permissions when you add a new table or a new field to your DaDaBIK application. The new $permissions_template config parameter is an array that allows you to set, for each group, the table and field permissions to add by default. This new feature will save you time, especially if you have many user groups. You can read all the details in the Permissions Templates chapter of the documentation.
Unsaved changes warning: DaDaBIK now warns the user when an insert/edit form has been changed and the user leaves the form without saving. Two new config paramters ($warn_unsaved_changes_edit_form, $warn_unsaved_changes_insert_form) allow you to control this feature and since the feature is still experimental (read config.php for details) by default are set to 0.
The config paramter $grant_permissions_after_table_installation, if set to 1 or 2, now causes the automatic permissions assigment not only when you install a table but also when you add a field (from the data page or by synching).

FIXED BUGS

Data page, the inline help now points out that when you save changes after having changed the schema of a table, IF you added one or more fields, also other fields that you may have added to such table using other tools (and not synchronized yet) will be synchronized with your DaDaBIK application.
DaDaBIK uses dot (.) as decimal separator (number format en-us), however Chart.js, the library used to produce charts, uses by default the client locale to determine how to format numbers. This means that you could have mixed formats (e.g. dot as decimal separator in a results grid, comma as decimal separator for labels in a chart). Fixed: now, to guarantee consistency, en-us is set as locale for Chart.js. You can still see a minor inconsistency: Chart.js uses a thousands separator, DaDaBIK doesn't so you could see the thousands separator in graphs.
When authentication was disabled ($enable_authentication = 0), DaDaBIK produced a [08] Error: during query execution. error unless $always_show_advanced_search_button was set to 1. Fixed.
The generation of a PIVOT table could produce an SQL error in some cases. Fixed.
When you deleted multiple records, an error could be produced. Fixed.
Installation of the WP plugin, documentation (file dadabik_wrapper/installation.txt) improved.
A bug introduced with V 11.4 produced an error: "Unexpected error, the data has not been correctly POSTed." when a search was executed using a "search URL". Fixed.
Documentation, custom pages: it is now pointed out that the _cp_ naming rule must be followed not only for variables but also for functions and classes and that you don't need to follow the _cp_ naming rule for your local variables (variables having local scope in your functions).
V 11.5, when the old upgrade/upgrade2 procedure was used, did not allow to correctly upgrade the edition if the version was the same (e.g. from 11.5 Pro to 11.5 Enterprise). Fixed.
Documentation, hooks: an after insert hook was defined as $hooks['accounts']['delete']['after'] instead of $hooks['accounts']['insert']['after']. Fixed.
When $enable_granual_permissions was set to 0, the 'advanced search' button was displayed even if none of the fields was in the search form. Fixed.
The Spanish translation has been updated.
Config file: it is now pointed out that when the language is not set yet (for example in the login form), the language used is the first in the list.
One of the links to the VIEWS tutorial in the admin->data page was wrong. Fixed
The select multiple form element in db synchro (step 2) was too small to easily select multiple elements. Fixed.

April 28, 2022
V. 11.5 Elba

NEW FEATURES AND CHANGES

New Force Password Change feature: the users table has a new field: "Force password change", if you set it to yes (it's yes by default, when an admin adds manually a new user), the user is forced to change the password after the next login.
Search-related vocabulary and UX improved: the "Search" button on the top menu is now "Advanced Search" and it only appears when at least one field is available in the search form (or if the new config parameter $always_show_advanced_search_button is set to 1); the "quick search" button on the top of the results grid is now "search", the "search for items" button in the advanced search form is now "search".
The submit button label for the insert form is now "Save", you can still use the old label ("Insert a new item >>") by setting the new config parameter $use_old_insert_form_button_label to 1.

FIXED BUGS

If you used the form configurator on the users table (by default, the dadabik_users table) you could experience unexpected behaviours, including an (apparently unmotivated) change of the "position" parameter of a field when you save. This was due to a "missing" position (position 2). The positions have been modified by the upgrade procedure and are now contiguous, this fixes the issue.
If you upgraded (using the up/up2 procedure) version < 10.0-Manarola to the latest, the table dadabik_forms_preview was not correctly altered, this resulted in an "Unknown column 'label_grid_field'" or similar message while using the form configurator. Fixed. More details here
The German and Hungarian translations have been updated,

February 28, 2022
V. 11.4 Elba

NEW FEATURES AND CHANGES

Fixed Header for the Results Grid
A new config param. $results_grid_fixed_header, allows to enable a fixed header for the results grid. This settings is compatible with grid_scroll and site_overflow $grid_layout_scrolling
LDAP binding: new mysubtree\username syntax supported
A new config parameter $ldap_binding_type allows to do the ldap binding using a mysubtree\username syntax instead of using the full path specified in $ldap_base_dn_ar.
Performance: force a user search before showing results
A new config parameter, $force_search_before_rsults, allows to set, for each table, if you require that a search is executed by the user before showing the results. This can be useful, especially for tables having a lot of records, to avoid the execution of (sometimes useless) SELECT queries when the user open the related page and therefore to reduce the load.
A new config param., $enable_ldap_debug_mode, allows to see some debug information about the LDAP login/binding process.
A new config parameter, $set_ldap_authentication_as_default, allows to make the LDAP checkbox checked by default.
Two new config parameters allow to choose to escape or not the various components involved in the LDAP authentication.
A new "after quick search filters" layout hooks has been implemented.
The $ldap_host parameter now expects a full URI like 'ldap://ldap.yourdomain.net' (instead of ldap.yourdomain.net)

FIXED BUGS

DaDaBIK, after the first LDAP login of a user, only for copying email, first and last name of the LDAP user into the dadabik_users table (and only if $ldap_copy_users_data was set to 1, that is the default setting), assumed $ldap_username_field was 'cn', even if you set a different $ldap_username_field. This could lead to errors (user not found or multiple users found in the LDAP directory) or to a situation in which the wrong email, first name and last name was copied (in case the search using 'cn' found a different user). Fixed.
DaDaBIK, after the first LDAP login of a user, copied the password of the user in the dadabik_users table. Even if the password was hashed and salted (same process applied to the other 'standard' passwords) this exposed the password itself to a unnecessary risk. Fixed, the passwords are not copied anymore. If you use or have used LDAP authentication in a DaDaBIK application, you should DELETE (setting them as empty string) the old passwords you might have in your dadabik_users table for the users having authentication_type_user = 'ldap'
DaDaBIK, after the first LDAP login of a user, did not set the user as "confirmed" as it happens with users registered by admins. Therefore, if $enable_email_confirmation was set to 1, LDAP users could not login because they were unconfirmed. Fixed. If you use or have used LDAP authentication in a DaDaBIK application, you should confirm in your dadabik_users table all the existing users having authentication_type_user = 'ldap', by setting confirmed_timestamp_user to the current timestamp (check https://www.unixtimestamp.com/ to see the current timestamp.)
DaDaBIK allowed an LDAP authenticatd user to change their password. Even if the operation was pointless (the password was changed locally but during the login the LDAP password was still used), it was not correct. Fixed.
The config param. $check_post_for_data (by default 1) allows to guess if the form data POSTed actually arrived (the post_max_size PHP parameter can limit the amount of data POSTed). This check wsa done on insert/update forms, now the same check is done on search forms as well (an additional param. $check_search_post_for_data has been added to config.php)
When you execute a search on a table, DaDaBIK stores the search filter until the session expires, so if you come back to such table after having visited other pages of your application, you still see the filtered results. However, if, for such table, you embedded a grid/chart into a (custom) page, when the (custom) page is displayed not only the filter is not consider (this is the expected behaviour) but it was also reset, even if the user could still see the search parameters in the quick search bar (if any). Fixed, now the filter is not reset anymore.
Documentation, bugs/unexpected behaviours chapter: we now point out that (unless you use PostgreSQL) the $enable_lookup_insert_popup = 1 feature only works if the "linked table" has an auto-increment primary key (that is also set as the unique field in the DaDaBIK -> Admin -> Pages page).
The config file, at the $ldap_default_id_group param, said 'after LDAP authentication, the authenticated user is also inserted into the dadabik LDAP users table', but the user is actually inserted in the DaDaBIK users table, there is no dadabik LDAP users table. Documentation fixed.
The LDAP authtentication process did not correctly escape the character #, it was only escaped if it was a the beginning of a string. This could lead to unepxected behavour if your usernames or DNs contained such character. Fixed.
Two messages: "Generic upload error" and "File uploaded! The file will replace the current one (if any) after saving the form." that are displayed after the upload of a file (if $upload_field_type is 'ajax', deefault setting) in case of failure or success were only displayed when the language set was English, foro all the other languages the messages were not displayed and a Javascript syntax error was produced. Fixed.
When $enable_authentication was 0, DadDaBIK produced an undefined index message. Fixed.
The "after 2 results grid header" layout hook was available but not listed in the documentation. Fixed.
Typos fixed

January 17, 2022
V. 11.3 Elba

NEW FEATURES AND CHANGES

It is now possible, for each field, to set a label for the results grid different from the the label used in the forms. A new parameter in form configurator (label grid) allows to set it. If left blank, the same label will be used for both the forms and the results grid. For charts and pivot tables, the labels used is still the form label.
A new config parameter, $hide_quick_search, allows to hide by default the quick search bar.
Documentation: a new chapter "Previous/Next buttons and page navigation bar, unexpected behaviors" has been added, the paragraph explains the (probably unexpected) behavior of such features.

FIXED BUGS
For bugs marked with *, depending on when you downloaded V 11.2, the bug could have been already fixed (we made a silente upgrade in November 2021)

For self-registered users, DaDaBIK always assigned them to group 2, regardless of the parameter $default_group_user_self_registration. Fixed.
Upgrading using the up/up2 procedure a dadabik MS SQL Server installation <= V 10.7 produced an SQL error. Fixed. *
Two libraries used by DaDaBIK have been updated to the latest stable version: TCPDF to version 6.4.4, Chart.js to V. 3.7.0. This fixes bugs and security issues that versions previously used by DaDaBIK had.
DaDaBIK installation from XLS/CSV/ODS file: starting from V.11, the "force string import" option was required and you could not disable it. It is now possible to disable it and to let DaDaBIK detect the field types as it happened before V.11. The install screen has now a detailed inline help that explains the risks of disabling "force string import" in case the values in a column are not homogeneous, see the inline help for additional details.
If you had a select_single_radio field in your insert form and you left it blank, DaDaBIK produced an undefined index error if the "possible duplication" page was showed. Fixed.
Layout of embedded tabular reports improved (wrong padding fixed).
The old upgrade/upgrade2 prodcedure, if used to upgrade a dadabik installation <= V 11.0 and if the DBMS was NOT MS SQL Server, did not create a 'unique' constraint on the email field of the users table as it should. This made the forgotten password feature work incorrectly: in case two users had the same email address, the feature, for those users, just did not work. Fixed. *
The parameter $check_post_for_data was not considered; regardless of the settings, DaDaBIK considered it as 1 (the default value). Fixed. *
After a successfull login through the API method "get_token", the failed login attempts were not reset, as it happens with the standard login. Fixed. *
Installation of a prepackaged app (Dada helpdesk, Dada sales): adding (and synching) fields to the dadabik_users table after the installation could lead to unexpected results.
DaDaBIK produced some Undefined index: less_then error messages if the Dada helpdesk or Dada sales applications were installed.

November 16, 2021
V. 11.2 Elba

NEW FEATURES AND CHANGES

The live edit feature has been improved a lot:
- Live edit is now enabled by default, check the (improved) chapter about live edit in the documentation to understand which are the current limitations and the implications of enabling it. You can disable it using the config param $enable_live_edit.
- A new config paramter, $allowed_fields_live_edit, allows to select for which fields you want to enable live edit and to override the live edit limitations (e.g. enable live edit even if a table use calculated fields). Read the documentation for all the details.
- Date and date_time fields are now compatible with live edit (only if $date_picker_type is 'flatpickr', as it is by default).
- Before update hooks are now compatible with live edits (please read the documentation for details about how the $parameters array changes when you do a live edit)
- JS event functions (if any) are now triggered also when you do "live edit"; if you have set JS event functions in form configurator, take that into consideration (the standard form and maybe some other fields are not available in the results grid).
- After update hooks are now compatible with live edits.
- You can now use live edit on fields having a custom formatting function.
- Non-lookup select_single and select_single_radio fields are now compatible with live edit.
- The 'live edit not allowed' messge is now more clear.
Several graphic improvements and changes to buttons, forms, icons, fonts. Edit, delete, details, files icons are now, by default, Font Awesome icons and you can choose them using the related config parameters. Both Font Awesome 4 and 5 are supported. In case you prefer to use the old images approach you can change the config parameter $edit_delete_details_icons_type.
The "Forgotten password" feature is now available even if user self-registration is disabled.
After login with a temporary password, dadabik forced the user to change the password, redirecting to edit account any attempt to see other pages. This was correct but an exception has been introduced: the login page.
For bar charts, only one background colour is now used.
When you add a new field in the data section, for the "Nullable" field, the option NO is now the default one.
The before update hook funciton has an additional (and third) parameter: the update type (standard, csv, live_edit)
The (hashed) passwords of users are not showed anymore in the users results grid.
Admin > Page section, custom pages: the show/hide HTML content link now shows a much higher rich editor.
The embed code showed to embed a chart into a custom page creates an iframe having same with and height of the chart, this made the browser display the scrollbars. Fixed. Now the iframe is higher and larger (+20px).
A new function: check_refresh_record_lock() is now available for your custom code to easily check if the current user is locking a particular record and, in case he/she is, to refresh the lock. This can be useful for example if you have buttons in edit forms and your button custom code modifies the record: before executing the code, you want to be sure if the current user is still locking the record. You can find an example in the documentation, code of the function dadabik_change_status, custom buttons chapter.

FIXED BUGS

Documentation, chapter 10: it has been highlighted that, for security reasons, it's important that you write in the custom_functions.php files and in all the files contained in the custom_functions folder only function definitions. If you write additional code, external to your functions, such code could be executed by an attacker by directing calling the files. This is true for any DaDaBIK file you want to modify adding your code (even for config_custom.php, that in fact you should use just to set parameters), except from the files you use to build custom PHP page (please read additional details in the documentation).
If you set as calculated a date_time field and you were using the flatpickr date picker (the default one), the value was not assigned correctly to the form field but the submission of the value was correct: this could lead to misundersdandings and errors because users saw a value in the form but the value actually submitted and registered was another. Fixed.
If a field for which a user didn't have edit permissions was "live edited" from the results grid, apparently the operation was executed without errors. The update was not actually executed (in fact, if the results grid page was reloaded, the old field value was reloaded) but such behaviour was confusing. Fixed. Now a permissions error is generated.
Revisions were not recorded for live edits. Fixed.
When a user enters a record in edit mode, DaDaBIK "locks" the record so that other users cannot modify using DaDaBIK. This prevents conflicts and data loss. The record lock was released when the user clicked on a custom button available in the edit form: this was not correct because it allows other transactions to modify the data you are working on with your button custom code. Fixed. Now the lock is kept. It is still the developer's responsibility, however, to check in the custom code (if the code will modify a record) IF the user is still locking the record (in fact, after a certain amount of time, the lock is released anyway), regardless of the position where you placed the button (edit form, results grid, ...). Read the updated paragraph "Queries and records locking" for additional details.
Show embed code, instructions displayed: it is now pointed out that when you embed a grid report, pagination is not available, this implies that only X records will be displayed, where X is your current items per page setting.
Line chart: when the minimum value of your dataset was > 0, the Y axis began at such minimum value, instead of beginning at 0 as it was supposed to. While the data was technically correct, the chart could be misleading, overamplifying (from the graphical point of view) differences between data points. Fixed, now the Y axis always begin at 0 when the minimum value of your dataset is > 0.
The paragraph "Queries and records locking" (chapter "How to add your custom code to DaDaBIK") has been improved, better explaining the problem of executing a custom query that modifies a record without the locking mechanisms that DaDaBIK offers with a standard edit+update operation. An example, at the moment only for buttons in edit forms, has been added to show how you can use record locking even in your own custom code: you can find it in the function dadabik_change_status. The old dadabik_change_status example, which implemented a record modification triggered by a button on the results grid, has been removed because at the moment there isn't an easy and completely safe way to execute it.
If a user did not have permissions on at least one table (e.g. the user had permissions only on custom pages), DaDaBIK produced an error after login. Fixed.
DaDaIK, if used with SQLite as DBMS, always generated an "attack 07 detected" when you tried to create a chart or a pivot table. Fixed.
Documentation, calculated fields now points out that If you want to assign a calculated value to a date/date_time field, regardless of format and format_edit you set as a config parameter, you have to set the value in the following format yyyy-mm-dd hh:mm:ss
When a record update was executed and none of the fields were allowed to update (this can happen in two cases: a form including only edit-disabled fields or a live-edit on a field where the user doesn't have edit permissions), the SQL UPDATE query was not executed but the query was registered in the dadabik_logs table and a revision was registered in revisions table. Fixed: no entry in the dadabik_logs and in the revisions. Please note that after update hooks are still executed.
If you added fields to the (standard, not custom) dadabik_users table and then you synch -> add fields, the fields were correctly added but also additional, internal fields (temporary_password_user and others) were added and showed in the users table form. This could lead to unespected behaviours because those fields were not supposed to be in the forms. In addition, an error was produced when you tried to insert a new users. Fixed.
DaDaBIK since v 11.1 requires user emails to be unique. If you had duplicated emails (even two emails set as empty space are considered duplicated, while two NULL emails are fine) the upgrade procedure failed. Fixed. Now the upgrade procedure first check if there are duplications and propose a solution in case there are duplicated emails.
Form configurator, Hint and tooltip parameters: it has been highlighted that they don't work with live edit.
Some of the libraries used by DaDaBIK have been upgraded, this fixes bugs and security issues that versions previously used by DaDaBIK had. More details: Spout, the library we use to import XLS, ODS and CSV files, has been upgraded to V. 3.3.0; Chart.js upgraded to V. 3.6.0; TyniMCE upgraded to V. 5.10.1; htmLawed updated to V. 1.2.6
With particular combinations of DBMSs and charsets (e.g. old MySQL and MariaDB + utf8mb4 charset) DaDaBIK 11.1 can fail installation or upgrade with a 'Specified key was too long; max key length is 767 bytes' error message. Fixed.
When creating a graph, DaDaBIK did not dislay correctly labels when they contained the following characters: < > ' " &. Fixed. Check this post for details about the bug.
Documentation about Excel/CSV/ODS synchronization: it has been pointed out that records that are in your DB and are NOT in your Excel/CSV/ODS file are kept as they are, DaDaBIK does not delete any record during the import process.
When an insert form was reloaded because of a "Possible duplication", if you clicked on the "Other..." option of a select_single* field, the textbox to add the new option was not displayed. Fixed.
The documentation about using a custom users/groups table has been improved, in particualar it is now pointed out that if you use a custom users/groups table, you should not manage (create/edit) your users/groups directly via DaDaBIK, see documentation for furhter details.
The search operator "less_then" is now "less_than" (typo fixed). The "less_then" occurrences you have in your form configurator will be automatically fixed by the upgrade procedure. In case you have set a custom translation in your language custom files for the key "less_then", you have to modify the key name in less_than.
DaDaBIK produced an undefined error message after login if there was no hompage set. Fixed.
The average loading time (client-side) of a DaDaBIK app page has been reduced.
Two messages related to the new file uploaded component ('File uploaded! ... ', 'Generic upload error') are now available in the language files (they were hard-coded)
When generating graphs and pivot tables, if you aggregated data by a date field, DaDaBIK could produce a 'SELECT list is not in GROUP BY clause .... ' error. Fixed.
Documentation: the example of minimum config_custom.php file did not contain the serial_number parameter. Fixed.
When $show_details_after_insert was set to 1, DaDaBIK produced an undefined variable error message after having clicked on 'continue' on the details, after-insert, page. Fixed.
DaDaBIK could produce an 'undefined variable' message during the live edit process. Fixed.
The error message related to the lack of permissions during live edit was hard-coded (not available in the language files). Fixed.
(Ajax) uploads and live edit: the related messages did not consider the language customization (language custom files). Fixed.
Documentation about before update hook was not clear. Typos fixed, documentation improved.
The FAQs page on the Website contained several improvements and fixes that were not available in the local FAQs document. Fixed.
During installation, the 'close' links for the alert messages did not work. Fixed.
Form configurator: the in-line help for "other choices allowed" did not open the help window. Fixed
In a results grid, when no records were found and there was an import from xls/csv/ods search filter set, the system message that pointed out the filter was hard-coded in italian. Fixed. The message available in the language file is now used.
The documentation about config and config_custom has been improved.
Documentation, live edit: it is now pointed out that live edit doesn't work for the users and groups tables.
The HTTP API authentication error message referred to REST API instead of HTTP API. Fixed.

September 14, 2021
V. 11.1 Elba

NEW FEATURES AND CHANGES

Users self-registration is now available. A register link allows visitors to create their account, specifying username, email, password and other optional information. This feature is disabled by default, a new enable_users_self_registration config parameter allows you to enable it. Other two new config parameters allow to enable email confirmation (account is active only after email confirmation) and the "forgot password" feature (a temporary new password is sent via email). Finally, you can also choose the group a self-registered user belongs to.
For php_ajax custom buttons, it is now possible to specify, in your custom function, a custom message (confirmation message or error message) that wil be displayed to the user after the execution of the funciton. Until now, only a Done! message was always displayed (all the details in the documentation).
A Select all feature is now available to select all the elements in a page without selecting each checkbox manually. You can then delete all the elements or apply a custom function to the set of elements.
French translation improved.

FIXED BUGS

Documentation: it has been highlighted that, in most of the cases, when you use custom formatting functions or you directly display content in a PHP pdf template, you must pass your content through htmlspecialchars, otherwise you could have unexpected results, including a (silent) partial display of your data. You are strongly advised to go through the documentation ("custom formatting functions" chapter, "Templates in PHP" chapter) to understand the possible consequences and to see examples.
Documentation, a known bug has been added: the default value parameter in form configurator does not work for select_single and select_single_radio fields if you open the insert form as the details part of a master/details form.
The "Show search URL" button was supposed to be displayed only afther the exeuction of a (standard) search but it appeared also after a quick search if the user loaded the results page again after the quick search. This could produce unpredictable results in case you had select_multiple/selct_multiple_checkbox fields in your quick search form. Fixed.
If you set $enable_search_by_url = 0 you could still get a search URL after a search and even if DaDaBIK did not perform the actual search when you used it, this was not clear and could be confusing for the user. Now, if you set $enable_search_by_url = 0, the "Show search URL" button does not appear anymore.
In DaDaBIK 11.0, when you sorted a table by clicking on a column heading and the table is a "details table" of a master/details form, you got an "Undefined variable" error and a query execution error. Fixed.
After having imported a huge numbe of rows from excel/csv/ods, DaDaBIK could easily trigger a "request URI too long" or similar error. Fixed.
For select_single loockup fields, the + sign that allows to add a new item from a popup window (enable_lookup_insert_popup) was displayed and worked, replacing the current value of the field in the form, even if the field had edit permissions "yes but disabled", giving the user the false impression of current record being updated with the new item (it was not the case: when the user finally saved the record, the field was returned to its original value). Fixed, now the + sign is not displayed for "yes but disabled" fields.
The crypter page produced an error. Fixed (this bug was silently fixed in V. 11.0 already, but users who downloaded it during the days immediately after the release of V. 11.0 could experience it).
While selecting/unselecting a record using the checkboxes, you could get a Forbidden error message triggered by ModSecurity. Fixed.
The link to the VIEWS tutorial in admin->data section was wrong. Fixed

June 16, 2021
V. 11.0 Elba

NEW FEATURES AND CHANGES

Live edit feature
For some fields you can now edit values directly on the results grid, by double clicking on the cell, without entering the record in edit mode. At the moment, this feature is only available for text and textarea fields in a table where you don't use custom validation functions, custom display/required functions, calculated fields and before/after update hooks. This limitations will be gradually removed in the future.
Import from MS Excel (or OpenOffice, CSV)
Users can now import data into a table from MS Excel (OpenOffice and CSV are also supported). This new feature is very flexible; the very basic usage is: import the raw data from a file having, in the header, the same column names you have in your DB table. But you can do much more: in your custom_functions.php file you can easily specify:
- The correspondence between column names and DB field names
- The transformation rules (you might need to change the data before importing it)
- The preview rules
- and more...
Synch with MS Excel (or OpenOffice, CSV)
Not only you can decide to import all the rows into your table, you can also decide to synch your table with your Excel file (OpenOffice / CSV). DaDaBIK checks, for each row, if it's already available in your table and in case it is, it will update the existing DB record instead of inserting a new one. You can specify the field (or combination of fields) DaDaBIK must use to "recognize" existing records.
New, AJAX file upload.
Uploads are now executed asynchronously, before submitting the form, showing a progress bar during the upload process; this make them much more user friendly, especially for big files. A new config parameter ($upload_field_type) can be used to choose between this new method (default) or the old one.
Add a record to a lookup table via pop-up window
Near to your lookup field you have now a + button that opens a pop-up window; from the window, the user can add a new item to the related linked table and the item will immediately be available for the current form after having closed the pop-up.
Search by URL
It is now possible to search by URL, specifying search criteria in the URL itself. This can be useful to send the result of a search to another user or to create a menu item showing the result of a pre-determined search without the need of creating a VIEW. A "Show search URL" button allows to show the URL for the current search.
New maintenance mode
It is now possible to set the maintenance mode from the admin area ("status" link in the top bar), without using the config file. You can also specify a list of non-admin users who can access the application in maintenance mode.
A new show/hide quick filters link allows to hide the whole quick filters box to save space. You can also disable this new link from the $show_hide_show_quick_filters_link config parameter.
Some DaDaBIK features were not supported or fully supported with PostgreSQL. These limitations have been solved. Now the after-insert hook, the "show details after insert" feature, the "insert multiple" feature, the insert e-mail notice, the registration of an insert operation REVISION and the "insert other ..." feature of a select_single lookup field are fully supported on PostgreSQL.
When you submit (insert, update) a form containing file fields, a notice about the number of files uploaded with the form is now displayed.
A "New line after this field" setting now is also considered if the related field, due to permissions settings, is hidden.
The minimum PostgreSQL version is required is now 8.2.
A new theme, bluegray, is available.
The "show labels" options (that permanently showed tooltips on the top of a pie/doughnut chart) is not available anymore, now the tooltips are only displayed when you mouse pointer is over the chart.
It is now possible to set a specific upload import directory as a configuration parameter, this is the directory where the xls/csv/ods files you import (both during installation and during following imports) are stored. The documentation has been updated, suggesting, for security reasons, to choose as $upload_import_directory as directory that is not accessible via Web.
Install from excel/csv/ods: now the 'force string import' option is requried, you cannot disabled it
Internet Explorer does not correctly work anymore for some of the DaDaBIK fatures and it is not supported anymore. Internet Explorer users are encouraged to move to Edge (or to any other supported browser).
The color of the buttons of the black theme has been changed.

FIXED BUGS

db synch: when the name of a field was changed, an "undefined variable" message was displayed; furthermore, DaDaBIK did not correctly check if the new field name lenght was <= 64 characters (a lenght > 64 can lead to problems with the permissions). Fixed.
When in maintenance mode, DaDaBIK could produce an "Undefined index: logged_user_infos_ar" message. Fixed.
The TCPDF library has been upgraded to the latest available. This fixes bugs and security issues that versions previously used by DaDaBIK had. If you want to know all the changes / fixes, check the online change log of the library (https://github.com/tecnickcom/TCPDF/blob/main/CHANGELOG.TXT) and see what happened since the release of the version DaDaBIK used before.
Many other libraries have been upgraded: palette.js, jQuery (v3.6.0), Chart.js (v. 3.3.0), TinyMCE (5.8.1), Split.js (v. 1.6.0), Spout (3.1.0). This fixes bugs and security issues that versions previously used by DaDaBIK had.
With PHP 7.4, DaDaBIK produced the message "Array and string offset access syntax with curly braces is deprecated in ... ". Fixed.
DaDaBIK, if used with MS SQL SERVER, could produce in some cases this error message 'A column has been specified more than once in the order by list'. This bug was fixed in version 9.4 but there was one case where the error was still produced: when you edited a record of a table having a master/details view set. Fixed
Documentation: it has been higlighted how to manage parameters for conditional fields in results grid when the user executes a 'between' search.
If, for a required/conditional custom function that you used for the results grid, you checked for select_types is_null, is_not_null, is_empty, is_not_empty, the function did not work correctly, because those select types were not correclty stored in memory after the execution of a search. Fixed.
A search executed with the operators is_null, is_not_null, is_empty, is_not_empty was not correctly reflected in the quick search form. E.g. if you searched for 'desc_product is null' the search was correctly executed but if you had the desc_product field in the quick search form, "is null" was not selected. Fixed.
Known bugs: it has been highlighted that if you execute a standard search or a search by url using a select_multiple field, the related field in the quick search filter is not properly filled with the value you used
The 'show embed code' for a results grid generated immediately after the execution of a search was wrong and could produce an error if embedded. Fixed. Now, immediately after the execution of a search the embed button is not showed, it's only displayed when you later access the table (e.g. by clicking on the related item in the menu)
Form configurator, "Other choices allowed?" option, inline documentation, it has been highlighted that if you enable this option, the content type of the field must be compatible also with the content the user will add with the "other" textbox. Furthermore, such content is not checked against custom or standard validation when it is automatically inserted in the primary key table.
"Other choices allowed?" option: the option works for both select_single and select_single_radio fields but the corresponding parameter showed up in form configurator only for select_single fields. So if it was set to yes because a former select_single field is now select_single_radio, the option was enabled without proper evidence in form configurator. Fixed.
"Other choices allowed?" option: when the select_single field is a lookup field, DaDaBIK automatically inserts the new option in the primary key table. However, if such option is already available, DaDaBIK did not insert the option in the primary key table but tried to insert an empty value, for the select_single field, in the main table. Fixed. Now in case of duplicated value, an error is generated and the operation is cancelled.
The German, Hungarian and Spanish translations have been updated
Form configurator: if you changed the lookup table name for a lookup field for which you had more than one linked field, the add/remove linked linked field links did not work as expected. Fixed.
DaDaBIK with PHP 7.4 produced an error 'Trying to access array offset on value of type int i'. Fixed.
With PHP 7.4, when showing revisions, DaDaBIK produced an error 'Notice: Trying to access array offset on value of type bool'. Fixed.
After the installation of a prepackaged app, the information about the installation (date installation, edition installation, ...) could be wrong. Fixed.
When you click on "remove search filter", DaDaBIK reset also the sort criteria, now the sort criteria will remain unchanged.
The prepackaged app Dada Sales produced an error on the "Revenues by month" page. Fixed.
Clculated fields, as already stated in the documentation: "If you need to use a field value, the correspondent field cannot be disabled in the edit form", it has now been also highlighted that the calculated value displayed in the form is apparently correct but the value stored in the db would be wrong.
The results grid after_2 layout hook was not executed when the number of records of a table (or the results of a search) was zero. Fixed.
config, record locking feature: it has been highlighted that each user can "lock" only one record at a specific time, so if, for example, a user opens two records in two different windows, the lock will be on the second one only and the lock on the first one will be lost
The documentation referred to several operations that did not work correctly if you don't have an auto-increment primary key. This was not completely correct: 1) you need an auto-increment 'dadabik unique field', it is normally the PK but it could be another field 2) If you use PostgreSQL, the field doesn't need to be auto-increment. Documentation fixed.
Documentation, requirements for MySQL, it has been highlighted that if you don't use InnoDB as engine, some features won't work as expected.
Documentation: the part related to conitional fields in results grid has been improved: the example contained a typo (now fixed) and some additional details have been highlighted; if you are using this feature, you should read this improved section.
If you used MySQL 8 and you set Data types: simple in your Data -> settings page, you might see, in the Data page, the field type as blank for integer fields. Fixed.
Known bug added in documentation: If you use a MySQL version < 8 and you set Data types: simple in your Data -> settings page, you might see, in the Data page, the field type as blank for integer fields.
DaDaBIK could produce errors during the installation from CSV/XLS/ODS or during the installation from a database having a table with a composite primary key and in case granular permissions were disabled, the "form presence" settings for the ID field added by dadabik were not correctly stored. Fixed.

Jan 26, 2021
V. 10.6 Manarola

FIXED BUGS AND CHANGES

DaDaBIK on MS SQL Server: some wrong "N" characters were added to the content of your fields when some character sequences were detected. In particular, the following sequences of characters (without double quotes)

"('", ",'", ", '", "= '", "<> '", "> '", "< '", "like '"

became (without double quotes):

"(N'", ",N'", ", N'", "= N'", "<> N'", "> N'", "< N'", "like N'"

It should be easy to check if in your database, for alphanumeric fields, you have those string sequences, if you got these, wrong, additional "N"s and to delete them in case they were not supposed to be there. If you are storing binary data, however (for example in varbinary or image fields), it might be harder. The bug is now fixed.
DaDaBIK on SQL Server: starting from V 10.6, nvarch, nchar and ntext fields are not supported anymore. If you have such fields in your own tables, you should convert them to varchar, char and varchar(max). Your dadabik_ tables also contain nvarch, nchar and ntext fields, you should convert them as well. If you don't do it, you won't be able to represent Unicode characters other than ASCII and if you use the \"simple mode\" for data types in the data section, you will see your field types empty. To represent Unicode characters other than ASCII, you are now required to use char and varchar fields together with the new _utf8 collations introduced with SQL Server 2019. Text fields are also not supported to represent Unicode characters other than ASCII (and they are deprecated in SQL Server anyway), you should use varchar(max) (+ _utf8 collation) instead.
DaDaBIK on MS SQL Server: the crypter link in the users table was not correct. Fixed.
DaDaBIK and MS SQL Server: data section, the online help stated that for 'short text' the varchar(255) field type was used and for 'long text' the text field type; we used, however, nvarchar(255) and ntext until V. 10.5 (now it's varchar(255) and varchar(max)). Furthermore, in the onlne help it has now been highlighted that, if you use the 'advanced data types' mode, you could see varchar(-1) instead of varhcar(max) and you should replace -1 with max when you save your changes.
The DaDaBIK Worpdress plugin could make some Wordpress features not working as expected and in some WP versions the WP site healt page displayed some 'critical issues' generated by the plugin. Fixed. The new plugin also requires the new $site_path parameter, which decreases the risk of session hijacking in case other applications, in addition to the intended one, are using the same session name (parameter $dadabik_session_name).
If, in a insert or edit form, a field field1 was dinamically changed because of a change in its parent (cascade) and field1 was one of the parameters used by a calculated field field2, its change was, apparently, not considered by the calculated function (the calculated value of field2 in the form did not reflected the change in field1). After the submission of the form, however, the calcuated function considered the new value of field1. Fixed. Field2 is now updated 'live' also before form submission.
DaDaBIK on MS SQL Server: applying the primary key index to a field in the DATA section produced an error. Fixed.
Data section: when you altered a table (e.g. changing a field name) you got two, different 'DONE' messages, one after the other. This was confusing because after the first 'DONE' the operation wasn't completed yet and the second one could appear even some seconds later. Fixed.

Jan 14, 2021
V. 10.5 Manarola

NEW FEATURES AND CHANGES

Conditional fields for results grid: it is now possible to use your custom required/display functions for the results grid columns as well, check the documentation for the details.
Table and field names length must now be max 64 characters; this is not a real limitation for MySQL or PostgreSQL databases, because unless you don't recompile them, you can't use more than 64 characters anyway, it could be a limitation for SQL Server and SQLite.
A new parameter $csv_headers_formatting_function allows to set an optional formatting function for the CSV headers. It can be useful, for example, to remove <br> from your labels, if any.
Leading and trailing spaces (and other similar characters such as \n and \t) are not allowed anymore for email field types. If you prefer the old validation rules you can set $allows_leading_trailing_spaces_email = 1 in config_custom.php

FIXED BUGS

The "copy permissions from group to group" feature had a bug that arose if you selected a table/view: if the name of the table (or the name of the related fields) contained one of the following characters: % _ \ (for sqlserver, in addition, [ and ]) or characters which need to be escaped (such as single quote, double quote, backslash or the NUL byte), the field permissions for the target group were not updated (not deleted, not copied from the source group). The "copy permissions from table to table" feature also had a similar bug: if the name of at least one of the tables involved (or the name of the related fields) contained one of the character mentioned before, the field permissions for the target table were not deleted AND/OR the field permissions for the source table were not copied to the target; apart from not producing the expected result, this can lead to unpredictable situations where for the same field, operation and group combination, more than one value is stored in the dadabik_permissions table, making unclear which is the actual permission value. Both the bugs refers to the field permissions, while the table permissions were correctly erased/copied.
The bug related to select_multiple_*, non-lookup fields, fixed in V 10.4 (see this change log for further details), was fixed for the results grid and the details page, but the same issue could arise when you created a CSV. Fixed.
If you installed V 10.4 Pro and then upgraded to V 10.4 Enterprise/Platinum the upgrade procedure couldn't be correctly completed; this did not have effects on the functionalities of your installation, but in the 'About' page DaDaBIK still displayed 10.4 Pro. The next time you upgrade DaDaBIK this will be fixed.
DB synchro, field rename didn't show an alert if the new field name contained a simicolon, as it did for the other not allowed character. Fixed
The xlsx files did not have the correct mime type in config.php, they had the one belonging to xls instead. This could produce, for example, the following behaviour: you download an xlsx file, the operating system automatically changed the extension to xls and finally MS Excel produced an eror when the file was loaded.
For an application having a huge number of tables and making use of master/details forms, V 10.4, for pages related to operations on the details table of a master/details form, was slower than 10.3. Fixed.
The new upgrade procedure registered as current version 10.4 instead of 10.4-Manarola. This didn't have any impact on the functionalities but DaDaBIK alerted for the availability of a new version even if you had the latest one. Fixed.
Upgrade procedure: if you upgrade from a version < 10.0 now the procedure tells you to paste some code in your custom_functions.php file. In case you upgraded to V 10.4 from a version < 10.0 using the new upgrade procedure, you did not receive these instruction so here is what you should do: you need to paste the content of the the new custom_functions.php file at the end of your old custom_functions.php. In case you already have the statement $cnt = 0; in your old file, delete this statement from the code you have pasted. If you don't do that, you can still use DaDaBIK without issues but you can't take advantage of the new custom files structure (one file for each category of function) introduced in DaDaBIK 10.
The date picker flatpckr has been updated to the latest 4.6.9 version. This fixes bugs and issue related to the version previously used. The language translations have also been upgraded, while in the previous DaDaBIK version the library was upgraded without upgrading the translations.
Upgrade procedure: unhandled errors now produce an error message.
Form configurator, inline help: it has been highlighted that if you set a default value for a cascade parent field, the cascade action will not be triggered automatically, the cascade action is only triggered by a value change
The after results grid header layout hook was not executed if, for the current table/view, DaDaBIK did not find any results (record). Fixed.
Upgrade procedure: if a wrong file was copied in the upgrades folder (not the latest version or changed file name) DaDaBIK threw a PHP error instead of displaying the specific error message. Fixed.
Upgrade procedure: it is now possible to skip the file count check in the upgrades folder.
Hungarian translation updated.

Dec 10, 2020
V. 10.4 Manarola

NEW FEATURES AND CHANGES

DaDaBIK has a new, easier, upgrade procedure, compatible with any DaDaBIK >= 5.0: you just need to copy the files up.php and up2.php in the main DaDaBIK folder of the application you want to upgrade, run up.php and follow the instructions; DaDaBIK will copy the needed files, upgrade your database and give you some useful additional information. If you edited config.php, DaDaBIK detects those edits and tells you which parameters you should add to config_custom.php.
Performances for applications having a huge number of tables and/or fields have been improved.
Before v. 10.4, using config_custom.php instead of config.php was strongly suggested, now it is required. If you edit config.php directly, you can get unexpected results. Some related changes: it is now possible to set all the parameters in config_custom.php, even if you are using custom users/groups tables; you no longer need to execute date_default_timezone_set() in config_custom.php, $start_year and $end_year are now computed based on the timezone you have in config_custom.php (if any) and the documentation has now a short chapter dedicated to the config.php and config_custom.php files.
All the documentation that was included in the custom_functions.php file has been moved to the DaDaBIK manual (documentation.htm), the documentation has also been improved and a general chapter related to custom code (best practices and rules) has been added.
The title of each grid in a master/details view has now its own CSS class: title_items_master_details

FIXED BUGS

DaDaBIK, if used in an environment having session.auto_start = 1 in php.ini (the default is 0) AND PHP < 7.2 could have unexpected behaviour; session.auto_start = 1 AND PHP >= 7.2 only produced, instead, some warning messages ("Cannot change session name ..." and others). This has been fixed. However, since having session.auto_start = 1 could make your application less secure, it is strongly recommended to have session.auto_start = 0. For this reason, starting from V. 10.4, DaDaBIK shows a warning if you have session.auto_start = 1 in your php.ini. You can disable it by using the new $warning_sessions config paramters but it is strongly recommended to keep session_auto_start = 0. You can find further details in the config.php file or in the documentation, security chapter.
In results grid and details pages, a select_multiple_*, non-lookup field, could produce unexpected behaviours if, in the same table/view, in any position before such field (considering the position assigned in form configurator) there was a lookup field. More in details, DaDaBIK could produce an "undefined variable" message or show the related value in a wrong way, considering, to format the value, the "Field type" and "Content type" related to another field (the lookup field mentioned before). Fixed.
Dropdown security form check. When you use any select_* field (select_single, select_multiple_menu, ....) you can choose the options to include (even from a table) and this ensures the user cannot choose other, different, options. However, a malicious user could try to POST a different value, sending the data directly to the insert or update function without passing through the DaDaBIK form. The new dropdown security form check feature (config param. $dropdown_security_form_check), introduced in V 10.4, stops that. If it is enabled (by default, it is), DaDaBIK, before registering a value in the database, if the corresponding field is a select_* field, checks if the value belongs to the ones the user is allowed to see in the corresponding list of options and if not, throws an error.
Documentation, custom code, a new paragraph "Queries and records locking" has been added, highlighting that if you update a record using your own custom code, there isn't any check related to record locking.
When an error occurred during the deletion of a file, DaDaBIK showed an "error while deleting file ... " including the name and path of the file. Since this could reveal the physical path where DaDaBIK was installed, the information related to the file has been removed.
When, for a lookup field, "Show link to record?" was set to YES, DaDaBIK showed a link to the corresponding record even if the value of the lookup field was NULL. Fixed.
With some OS/MySQL environments, DaDaBIK, during the installaiton, produced several "undefined index" messages and could not use the information related to referential integrity constraints to guess the lookup fields settings. Fixed.
Config.php documentation: it has been highlighted that, regardless of the $treat_blank_as_null value, when you import a CSV/XLS/ODS file, a blank, non-string, field is always converted to NULL.
When, during an insert operation, DaDaBIK detected similar items, it showed the list (max $number_duplicated_records items) without saying that the list can be limited by $number_duplicated_records (by default 30). Fixed, now DaDaBIK says there could be more similar items, not displayed.
DaDaBIK produced an 'Error template heading' message if an HTML footer template was set for PDF generation. Fixed.
DaDaBIK, if used with PHP >= 7.4, produced some 'deprecated' warning messages. Fixed.
Many libraries used by DaDaBIK have been updated to the latest stable version: jQuery, flatpickr, select2, TCPDF, TinyMCE, htmlawed, Chart.js. This fixes bugs and security issues that versions previously used by DaDaBIK had. If you want to know all the changes / fixes, check the change log of each library and see what happened since the release of the version DaDaBIK used before.

In case you have directly used these libraries in your own custom code, check if everything is still working as expected because there could have been some breaking changes.
The (old) upgrade procedure failed to work properly and produced an error if the starting version was 5.0. Fixed.
Installation process: it has been highlighted that each prepackaged app has some config fixed parameters that you cannot change.
Documentation: it has been highlighted that if you upgrade an installation based on a prepackaged app, only the DaDaBIK engine will be upgraded, not the app itself.

Aug 26, 2020
V. 10.3 Manarola

FIXED BUGS AND CHANGES

select_multiple_menu and select_multiple_checkbox field types: if, while editing a record, the user unselected all the options of a select multiple field (making the field empty), after saving, if there was an error (e.g. a missing required field in the form), the select multiple field, instead of being displayed as empty (no options selected) was displayed with the selected options it had when the edit page was open. This could lead to a situation where wrong data was saved, if the user didn't realize the select multiple had been restored to its original value. Fixed.
The (clear) password you typed in the encrypter popup form could be saved by your browser and offered as autocomplete option to other users, if the same computer (and browser) was shared among different users. This could lead to security issues, because users could see, incidentally or maliciously, other users' password. Each browser seems to behave in its own way, please note that the password could pop-up in clear as autocomplete option even on a completely different page if the field name is the same (in this case the field name is "pwd") so a malicious user could create on purpose a custom form with that specific field name. We can't provide specific information about where the autocomplete data is saved (and how, clear text Vs. encrypted) by your browser, because each browser works in a different way. Now, that field is not a normal HTML text field anymore but an HTML password field, this should avoid to be part of your browser's autocomplete feature but again, we can't guarantee because each browser works in a different way. Also the encrypted password fields (a total of three) are now "password" fields, for the same reason (since the password, in these cases, were displayed as encrypted, the problem was milder).
The search operator 'less_equal_than' did not work correctly: if a user chose it, the correspondant search parameter was ignored. This bug did not occur in two cases: for all the date related dadabik field types and if enable_user_booleans was set to 1. Fixed.
A small change in the form layout introduced in DaDaBIK 10.2 impacted on the vertical alignment of the fields (if you had more than one field on the same line), that became 'bottom' instead of 'top'. Fixed.
If, for a field, you had ' ' as value (exactly one blank space), dadabik implicitly read it as '' (empty field). The same happened if you have ' ' as a value for some of the form configurator parameters and for the config parameter FORM_CONFIGURATOR_SEPARATOR. Fixed.
Documentation, PDF template: it has been highlighted that if one of the fields you use in your template has field type: rich_editor or field content:html you can experience unpredictable results in the PDF produced.
Documentation, upgrade section: it has been highlighted that the file styles_screen_custom.css should not be replaced during the ugprade.
Documentation, Primary Key / Unique field related, it has been highlighted that the same limitation applies to the values of the $users_table_id_field field, in case you are using a custom users table.
Version 10.1 pro was erroneously released as a zip file having name 10.0; after unzipping, you got the right version but the naming could be confusing.
Documentation, know bugs: when version 10.2 was released, for the "Table and field names related:" category, the parameters $field_button_hint_container_id_prefix and $custom_button_ids_prefix were added to the list. This change, however, was not highlighted in the change log.
Typos fixed

July 15, 2020
V. 10.2 Manarola

NEW FEATURES and FEATURE CHANGES

A new, modern and powerful calendar/date picker has been introduced: flatpickr. This replaces the old jquery date picker (you can still use the old date picker by setting $date_picker_type in config.php) and provides several improvements including localization (the calendar uses the general language you chose for your DaDaBIK application) and user-friendly date format (you can show, in the edit form, something like May 12, 2020 even if the value you are sending to the server is 2020-05-12, see new config param $date_format_edit). Please note that, in case you wrote custom javascript code that sets a date/datetime, the code must be slightly changed for the new date picker. If your users use Internet Explorer, V. 10 (minimum) is required for the new calendar.
Permissions: it is now possible to copy the permissions from one table (or view) to another. When you copy permissions from table A to table B, DaDaBIK identifies the fields that A and B have in common and copy the permissions, for all the groups, only for those fields. A typical use of this feature is when you create a view B starting from a table A (where the view B has the same fields table A has, os a subset of them) and you want to assign the same permissions.
Custom display/required fields are now compatible with calculated fields. Please note that the requirdness of the field will not be taken into consideration, the 'show' element of the returning array will be taken into consideration to show/hide the field in the form but even if the field is hidden, its value will be computed during insert and update operations.
Custom formatting functions now also get, in addition to the value of the field that you want to format, the $where_value parameter: the value of the unique field, for the record processed in that moment. It can be useful to get other information about the record and use them to format the value of the field that your are formatting. You don't need to change your old custom formatting functions; you can, if you want, add $where_value as a second parameter only for the formatting functions that need it.
Each custom button can now have an (optional) ID, this is useful if you need to select the button from your custom javascript code. All custom buttons also have a css class now: "custom_button", in addition to "button_form", which is the class we use for all the buttons (custom and not custom).
The (updated) documentation related to PHP custom pages, that was included in the example.php php page example, has been moved in the official documentation (chapter 'custom pages').
session cookies have now the samesite attribute set, in order to guarantee compatibility with future browsers.
The English translation related to the password encrypter window has been improved
xlsx, docx and jpeg are now part of the file extensions allowed by default in config.php for uploads.
Form configurator: the very annoying 'unexpected error function get_where_value_form_preview' error provides now a more explicative error message.
When you drop a table/view, an alert now suggests to remove references to the table/view you might have in form configurator.
The $treat_blank_as_null config parameter is now set, by default, to 1. This means, among the other things, that if you leave a field empty during insert/update operations DaDaBIK will set, for that field, the NULL value and not an empty string. Set it back to 0 (in config.php or better in config_custom.php) if you need it and read the config.php documentation about $treat_blank_as_null, $null_word adn $null_checkbox to understand all the possible alternatives you have with regards to NULL.
An informative error message is now displayed when a save operation on the admin->pages section, for some reasons, does not send all the relevant data.

FIXED BUGS

In some cases, the previous/next record buttons did not bring the user to the correct record, considering the order the records had in the results view. More in details: when you displayed a recordset in DaDaBIK it could happen that, if you are browsing, using previous/next buttons, the recordset, you saw the same record twice and/or even if you are browsing all the records, you DID NOT see all the records belonging to the recordset. The recordset could be the results of a search or not (just table browsing), this didn't impact on this issue. Please note that even if you don't notice this issue, it may arise under particular circumstances (it depends on the DBMS's query execution plan). Fixed. The fix for this bug relies, as many other features in DaDaBIK, on the existence of a primary key in your tables.
For the fields having 'Use ajax to load options' enabled, the search process that shows the matching options as the user types gave unexpected results and wrong options if the string typed by the user contained a LIKE wildcard (% and _, for sqlserver in addition also [ and ]) or a backslash. Fixed.
Documentation: a new known bug has been added to the documentation: if your DaDaBIK unique fields contain (we are talking about the actual content, not about the name here) characters that need to be escaped (such as single quote, double quote, backslash or the NUL byte), you can experience problems and security issues.
If you have upgraded dadabik starting from an installation that was <= V 7.3.3 and your prefix internal table (by default 'dadabik_' ) contained a like wildcard character (_ % and, for sqlserver, in addition, [ and ]) DaDaBIK could delete the field permissions for tables whose name ends with 'static_pages'.
Permissions copy bug. Let's say you are copying permission from groupX to groupY for the table tableZ (if you don't select a specific table/view, the bug does not arise) and tableZ contains, in its name, one of the following two characters: _ % (or, in additions, also [ ] if you are using SQL Server), this is what will happen:

DaDaBIK will copy, for groupY, not only the FIELD permissions that group1 has on tableZ but also the FIELD permission that group1 has on tables having "matching" names.

What does "matching" names mean?
It means tables that match the (wrong) condition generated by the (not properly escaped) LIKE statement; just a few examples:

1) if the name of tableZ is cities_2, also groupX's field permissions related to, for example, cities-2 (dash instead of underscore) will be copied from groupX to groupY

2) if the name of tableZ is cities%2, also groupX's field permissions related to, for example, citiestesttesttesttest2 will be copied from groupX to groupY

For SQL Server, the bug could be more severe and could lead, in general, to wrongly copy the permissions (e.g. keeping the old permission of the target table, not copying the right permissions, ... )

The bug is related to field-level permissions, table-level permissions are not affected.

A missing field permission is equivalent to setting NO.
Config.php: it has been highlighted that enabling $enable_advanced_sql_report feature in combination with a non-empty $username_public_user can be dangerous (an unauthenticated user might have access to any data in your database or even in other databases).
When you dropped or uninstalled a table, if the table name contained a like wildcard character (% and _, for sqlserver in addition also [ and ]), the field permissions for other tables having matching names (see previous changelog item for a definition) could be deleted as well. For SQL Server, it could also happen that the permissions for the target table were not deleted. A missing field permission is equivalent to setting NO.
MS SQL Server: admin > data tab, table schema modification (e.g. you changed the field type of a field) did not work correctly: the modifications were not applied or only some of them were applied.
If you use MS SQL Server: searching records using the contains, starts_with, ends_with, doesnt_contain operators could lead to wrong search results if, in the search value, the user used these characters: [ ] The problem, for select_multiple_menu and select_multiple_checkbox fields, arises also with is_equal and is_different. Fixed.
DaDaBIK, for PostgreSQL, could detect, as a primary key (and, consequently, as unique field for DaDaBIK, admin > pages tab) a UNIQUE field (if any) instead of the Primary Key. This had the following consequences:

- if the unique field admitted NULL values, DaDaBIK could not identify the records and this can produce unpredictable behaviours
- if the unique index is a composite index (multiple fields), this can produce unpredictable behaviours (that's because DaDaBIK doesn't handle composite primary key)
- in the data tab, you could see a wrong composite primary key warning
- while editing a user, you could get a query error message and/or the message 'This is an imported LDAP user: his group is the only information which you should change, if needed.' could be displayed for the wrong user or not displayed.
- when you deleted a group, DaDaBIK could produce an error and/or, while automatically deleting the users belonging to the group, delete the wrong ones.

The bug has been fixed, you should, however, for all the existing tables, check if the unique field is the correct one (the primary key of the table). The easiest way is to check the table dadabik_table_list, pk_id_table field. For the records related to the tables dadabik_users and dadabik_groups, you should have id_user and id_group as pk_id_table (unless you changed $users_table_id_field / $groups_table_id_field in config.php).
Custom php files documentation: it has been highlighted that, in custom PHP pages, $_POST, $_GET and $_COOKIES are not escaped by DaDaBIK for your queries, regardless of your magic_quotes_gpc settings. If you use custom code in other situations (custom functions, hooks, .... ), however, $_POST, $_GET and $_COOKIES are always escaped by DaDaBIK.
Custom functions documentation: it has been higlighted that values coming from $_POST $_GET $_COOKIE are automatically escaped by DaDaBIK, if you need to use them in your prepared statements (bind_param_db functions) you should unescape them before (using the dadabik function unescape() ).
The username field in the dadabik_users table was set as varchar(50) but the max length for the field in form configurator was set to 100. This could lead to wrong username registrations for usernames longer than 50 characters. Fixed
Permissions Manager, inline help: it has been highlighted that, to see the details page of your records, you need to set DETAILS:Yes and READ:Yes; however, if CREATE is Yes, DETAILS:YES is enough (the user will be able to see the details page of a record if they know its URL, even if the table is not displayed as a meu item.).
HTTP API: if the username of a user contained a character that needs to be escaped (such as single quote, double quote, backslash or the NUL byte), a failed login was registered as belonging to the wrong user (e.g. for the user Bo'b: Bo\'b instead of Bo'b), this had an impact on the count of failed attempts before blocking the account, that was wrong. Fixed.
custom functions file included in the prepackaged apps: it has been highlighted that for up-to-date documentation the file to refer to is the /include/custom_functions.php you have in the root of yor DaDaBIK folder.
DaDaBIK removed characters considered as escape characters from the name of the files uploaded. This did not affect the upload feature and the data integrity, because DaDaBIK assigns anyway a unique name to the files, that could be different from the original file names, but deleting those characters was not needed. Fixed.
Documentation, file upload: it has been highlighted that some particular characters (that have a special meaning) in a file name can make PHP misinterprets the file name, e.g. the filename "my\test.txt" will be seen as just "test.txt"
HTTP API: if the username of a user contained a character that needs to be escaped (such as single quote, double quote, backslash or the NUL byte) the API did not work correctly. Fixed.
In the requirements, it has been highlighted that, for MySQL, running MySQL with the NO_BACKSLASH_ESCAPES SQL mode enabled is not compatible with DaDaBIK; DaDaBIK now checks if such SQL mode is enabled and produces an error in case it is.
Custom display/required functions and custom validation functions: it has been highlighted that if you need an input field value in your function, the field cannot be a calculated field.
MariaDB v. 10.x was not correctly recognized by the requirements check script, even if it is compatible with DaDaBIK. Fixed.
The language code to use for Russian in multilanguage labels, hints and tooltips was RI instead of RU. Fixed. In case you used RI, you hae to modify it otherwise your multilanguage labels, hints and tooltips won't work correctly
CSV and PDF files are now created taking into account the sorting criteria used in the results grid. Before this version, for CSV and PDF exports, no sorting criteria was used for the records. Two new parameters, $use_sort_for_csv and $use_sort_for_pdf, allow you to disable this new feature in case, for performance issues, you prefer not to apply sorting.
If you hid a field using the custom display / required function, the hint and the buttons related to that field were not hidden. Fixed.
DaDaBIK, together with PostgreSQL V. 12, produced a '.....ERROR: column pg_attrdef.adsrc does not exist....' query error. Fixed.
It has been highlighted, both in the documentation and in the inline help (data section) that for PostgreSQL the value you see in the extra column (admin, data tab) at the moment is still not 100% reliable, e.g. you can see the value empty even if the field is actully serial; we suggest to always check if a field is serial also from a db administration tool and to check if you are overriding the value from the data section.
DaDaBIK 10, during installation or upgrade, could produce a "specified key was too long" error message. Fixed.
It has been highlighted that if you use a custom create_password_hash function, this also affects the hashes of the APIs tokens, and at the moment those hashes can be max 100 chars long.
Form configurator, inline help, it has been highlighted that Custom display / required function only impacts on insert and edit forms.
DaDaBIK could produce PHP and Javascript errors after an update attempt if the user lost the lock on the record. Fixed.
In config.php it has been highlighted that access logging only works if SQL logging is enabled.
Tables creation, tables and views drop: if the table/view name contains characters that need quotes around table/view names, the operation produced an error. Fixed.
Config.php: it has been highlighted that $insert_again_after_insert = 1 does not work when you insert a record for an items table (master/details view)
DaDaBIK, after the installation of a table (from install2.php or from the admin > pages tab), if the table has a composite primary key and the DBMS is not MySQL (or $add_additional_dadabik_id_field is 0) now shows an alert saying that it does not support composite primary keys and proposes a workaround, instead of setting as unique key the first of the field composing the primary key (which can lead to unexpected results).
DaDaBIK, for the password encrypter windows, always showed the first language available in the languages_ar array (by default, English), regardless of the language selected. Fixed.
Config.php: it has been highlighted that the features $show_multiple_inserts_checkbox and $show_details_after_insert, to work, require an auto-increment primary key on the related table
For most of the field types, the autocomplete attribute was erroneously set to off for the fields included in a DaDaBIK edit / insert / search form. Fixed.
When a user logged out from DaDaBIK when a record was open in edit mode, the lock on such record was not released. Fixed.
Documentation: it has been highlighted that, on PostgreSQL, the after-insert hook doesn't fully work and the "show details after insert" feature, the "insert multiple" feature, the insert e-mail notice, the registration of an insert operation REVISION and the "insert other ..." feature of a select_single lookup field don't work. The previous version of the documentation stated that some of these features can work on PostgreSQL if you have a sequence with a particular name; as explained in the v. 10.1 changelog, however, this is wrong.

March 9, 2020
V. 10.1 Manarola

NEW FEATURES and FEATURE CHANGES

PDF templates: it is now possible to create template files in PHP (not only in HTML). Adding PHP code to your templates opens to many new possibilities, for example part of your template can change according to some conditions (e.g. according to the user currently logged in). Plese note that, because of the introduciton of PHP templates, the templates naming has changed a bit. The .php template files you had (if any) must be renamed *_settings.php. For example, if for a table customers you had a customers.html template file and a customers.php template file containing additional settings, the latter must be renamed customers_settings.php (while customers.html can keep its original name)..
It is now possible to specify, in the _settings.php template file, the name of the PDF file produced.
DaDaBIK now fully supports NESTED master/details forms. If you downloaded DaDaBIK 10.0 starting from January 29, you have this improvement already available in v. 10.0, because of a silent upgrade.
Primary keys composed by multiple columns are now partially supported: when DaDaBIK detects a table having a composite primary key, it automatically adds a unique, auto-increment, additional field to the table and uses it as "unique field". This feature at the moment is only available on MySQL and you have to enable it from config.php ($add_additional_dadabik_id_field parameter). If you downloaded DaDaBIK 10.0 starting from January 29, due to an error in a silent upgrade, you already have this feature enabled (without the possibility to disable it) for the general installation (not for a single table installation) so if you use MySQL you might have an additional dadabik_id field already for tables with composite primary keys, if you use other DBMSs you might get an error during installation and/or a wrong unique field set for table having composite primary keys (for those tables, the unique field was wrong anyway even before, because composite primary keys were not - and are not - supported).
DaDaBIK now shows, for uploaded pictures, the picture itself in the edit form (it used to show only a link to the picture). A new config parameter $show_images_in_edit_form can be used to enable this feature (enabled by default).
$show_top_buttons is now 1 by default in config.php.
Improved form configurator live preview error messages.
The error messages produced by the form configurator security checker are now more explicative.

FIXED BUGS

For select_single and select_single_radio LOOKUP fields, when the insert form was displayed after an insert attempt because of a validation error (e.g. a missing required field), the selected value of the select_single* field could become the DEFAULT VALUE (if set in the form configurator) instead of keeping the value selected by the user before submitting the form; this, if the user didn't notice it, could lead to the registration of wrong data. Fixed.
With v. 10.0, some bugs related to PostgreSQL were fixed:
- Insert/update didn't work correctly on PostgreSQL if the user chose 'Other....' from a select_single field menu and the field had some linked fields (fixed in DaDaBIK 10.0 but not highlighted in the v.10.0 changelog).
- The after-insert hook did not work on PostgreSQL: it did not receive the value of the primary key of the record just inserted
- The insert e-mail notice didn't work on PostgreSQL (fixed in DaDaBIK 10.0 but not highlighted in the v.10.0 changelog).
However, these features still had problems, due to the fact they relied on the use of serial fields and sequences; more details:
- The assumption of the existence of a serial field (let's call it ID for simplicity) with a sequence having the default PostgreSQL name TABLENAME_FIELDNAME_seq name: if the sequence was not available, an error was produced and the current operation failed
- Even if the sequence was available, since sequences are non-transactional in PostgreSQL, their uses is not reliable for this purpose, especially for high traffic applications. What could have happened with v. 10.0 is that, after an insert operation, DaDaBIK didn't receives the id of the record just inserted but the id of another (inserted by another concurrent transaction) record, and consequently registered or sent via email wrong data (select_single with "other ..." or email notice) or sent to the after inser hook the wrong id.
For these reasons, the features have been disabled in v. 10.1, we need a deeper analysis and a more reliable solution. For the same reason, the registration of the insert operations (audit/revsions feature), introduced with V. 10, has been removed in V. 10.1 because, again, DaDaBIK could register the wrong ID in the revision table. The other operations (update, delete) are, instead still registered as revisions.
For select_single fields using the "User-friendly searchable" option, it was not possible to clear the field after having selected an option. Fixed.
Default value using a custom function did not work for select_single lookup fields having 'Use ajax to load options?' = NO in form configurator. Fixed.
A DaDaBIK installation from CSV/Excel generated a "Notice: Undefined variable: select_checkbox_prefix" message. Fixed.
If you installed DaDaBIK from CSV/Excel and one of your sheet or column name contained the string set in $select_checkbox_prefix (config.php, default is "sel_chk__"), you could get unexpected results. Fixed.
The inline help for the advanced SQL report was not displayed if the language was Italian. Fixed.
The classic_grid / list menu didn't work in a master/details form having more than 1 items table. Fixed.
Documentation: it has been highlighted that, for the records selection HTTP API method, you can get an handled error as response.
custom_functions.php file: it has been highlighted that when you define a custom function, you can't add spaces or tabs in front of the definition, otherwise the form configurator parser can't read it.
The default sort by/type settings ("pages" tab) didn't work for items tables (master/details view). Fixed.
DaDaBIK, if used with postgreSQL, could produced a '[08] Error: during last ID fetching.' message due to the lack of a sequence having the expected name. Fixed.
Default value using SQL: did not work for select_single lookup fields having 'Use ajax to load options?' = NO in form configurator. Fixed.
Delete all and delete selected operations, if $delete_files_when_delete_record = 1 and the table contained file fields, produced a [08] Error: during query execution. Fixed.
For image_file fields, the link to the file displayed in the edit form can provide incorrect headers to the browser. Fixed.
In a details page, the PDF template menu also showed the _header and _footer template files as templates. Fixed.
if $details_page_dont_show_insert_edit_delete_items = 0, DaDaBIK after the insertion of an item record from a master/detils view accessed in "details mode" (not in "edit mode") shows a "Continue" button instead of a "back" button. Fixed.
After having clicked on "Show revisions", if there weren't revisions for the table, it was not possible to return to the standard table view (missing "hide revisions" link). Fixed.
When, while editing a record, you clicked on "show revisions" and the revisions were not enabled for the table or there were no revisions yet, DaDaBIK produced an 'error: during query execution.' message. Fixed.
For lookup fields, you can get an undefined index error message if an edit form was displayed after an error (e.g. a missing required field) if you are using custom filers for them. Fixed

December 12, 2019
v. 10.0 “Manarola”

NEW FEATURES AND OTHER CHANGES

From configurator live preview
You can see a live preview of a form WHILE you are working on the form configurator.
Audit/Revisions
Track, for each record, the history of changes (and who/when modified it).
DB admin
Create and alter tables directly in DaDaBIK (Admin -> Data) without the need to use PHPMyAdmin or similar.
Conditional fields
You can now decide if you want to show or not a field in a form according to a cusotm function, e.g. you might want to show/hide a field according to the value of another field. You can do that using the custom required function, that can now return two pieces of information: required (true/false) and show(true/false)
HTTP API
You can now access a DaDaBIK application through an HTTP API: two methods are implemnted: authentication and record selection. The authentication method allows to get an auhtentication token, the record selection method allows to retrieve data from a table/view, specifying search criteria. The API's response is in Json.
Performances improved
Displaying a results grid page is now faster if you have several lookup fields. Furthermore, a new config.php parameter, $always_refresh_permissions, allows to avoid the permissions 'refresh' that DaDaBIK does at every page load. This can also increase the performances. The performances of the export to CSV function have also been improved: if you have several lookup fields in a table, the production of a CSV file is now faster.
Pivot / Summary tables.
It is now possible to create Summary/Pivot report tables: the process is similar to the creation of a chart report, you select a field to aggregate data on and one or more aggregation function. For exammple, for a products table, you could create a Pivot table containing, for each brand, the number of items and the average price. Pivot tables, as chart reports and results grid, can be embedded in a custom page to crete dashboards.
Multiple record selection
It is now possible to select records from the results grid using checkboxes and to execute functions (the default 'delete selected' function or custom functions) on the selected records. You can enable/disable this feature using $enable_record_checkboxes in config.php
Maintenance mode
A new "Maintenance mode" is available; when you set $maintenance_mode = 1 in config.php, non-administrator users can't access the application, $debug_mode and $display_sql will be automatically enabled and the page execution time will be printed in the page's footer.
Multi-language labels, hints and tooltips
In form configurator, you can specify one or more language translations e.g. EN:name~IT:nome~DE:name~ES:nombre~. You can enable the feature with $enable_multilanguage_labels in config.php and you can also have a default language in case you have a missing traslation ($default_language_missing_translation parameter).
The before delete hook can now prevent the deletion of a record: your custom function must return 'dont_delete' and you can also specify a custom error message.
From Admin -> Pages it is now possible to optionally specify, for each table, a default SORT BY field and SORT TYPE (ASC or DESC).
PDF generation improvements
- You can now specify a template header and footer file (e.g., for the customers.html template, a customers_header.html and customers_footer.html); this can be very useful in combination with the new $add_pdf_page_for_each_record paremeter: if set to 0 (default is 1), DaDaBIK, when you produce a PDF starting from a results set, doesn't create a new pdf page for each record (this allows you, for example, to create a 'grid' of records with your PDF, putting <table> and <th>s in the template header, each <tr> in the template and </table> in the template footer.)
- A new parameter, $parse_pdf_php_template_even_if_export_pdf_disable, allows DaDaBIK to read the PDF template.php file even if $export_to_pdf_feature = 0. This can be useful because you can then override $export_to_pdf_feature in the template itself, enabling PDF export only for one or a few tables. This, in combination with the fact that a PDF template can be now set through the URL (e.g. index.php?tablename=customers&function=search&export_to_pdf=1&pdf_template=customers_summer_template to produce a PDF starting from the customers table, using the 'customers_summer template), allows you to create custom "produce PDF" buttons for specific tables without showing the standard PDF button + templates dropdown menu.
- A new config parameter, $pdf_page_orientation, allows you to set the PDF page orientation. You can also override this parameter (and the other new $add_pdf_page_for_each_record for each different template, in the nametemplate.php file)
- The PDF creation process now uses $site_url if it is set. This might be useful if you are having issues displaing images in PDF.
Custom validation functions now work for select_single* and select_multiple* field types as well.
Calculated fields are now compatibile with date and date_time fields.
The master_table_where_field and master_table_where_value variables are now passed, if set, to the function that refreshes cascade listboxes; this might be useful if you need to use them in your where clause filter.
A new config.php parameter, $enable_password_validation, allows to define a custom validation password function; this is useful if, for security reason, you want to set rules for passwords (e.g. minimum 8 characters)
Textarea fields get now, by default, 4 rows.
Admin area, improved layout
The installation page has now a new, "Build a blank application" option to start building a DaDaBIK app from an empty DB, adding data structures using DaDaBIK itself.
The install and ugprade procedures now preliminary check if the system meets the DaDaBIK requirements. In addition to install.php and upgrade.php, two additional files (install2.php and upgrade2.php) need to be deleted after an installation or upgrade process.
In the admin section, pages tab, custom pages, the list of PHP source files is now sorted alphabetically.
A new parameter, $compute_calculated_fields_update_if_hidden_disabled, allows you to avoid recomputing a calculated field during update if the field is hidden or disabled in the edit form.
It is now possible, to set the default value for a field, to use a custom function. PLEASE check your current default values in form configurator: if for some reason you have a default value starting with "dadabik_", a function might be executed when the insert form is displayed or when an insert operation is executed.
Custom PHP functions and hooks are now stored in different files according to the set they belong to (custom_formatting_functions.php, custom_validation_functions.php, layout_hooks.php .... ). You can still, if you prefer, store all your code in the file custom_functions.php. Furthermore, in form configurator, you can choose custom PHP functions from a (searchable) listbox, instead of manually typing the functinon name; you can still use the old approach by setting $use_listbox_for_custom_function_selection = 0 in config.php.
You can now upload files without setting $upload_directory and $upload_relative_url: DaDaBIK guesses the path of the uploads directory by itself. While $upload_relative_url is not used anymore, you can still use $upload_directory to change the default upload directory (uploads in the DaDaBIK root) and you should do that for security reasons: in fact you can now set as upload directory a folder that is ABOVE the Web root: while you could do that before, this possibility was not documented. Furthermore, in order to use the upload feature in DaDaBIK, you should enable it by setting $enable_uploads = 1 in config.php.
In a master/details form, if you execute an action on one of the detail items (e.g. you delete an item), after the page reload, the page is now automatically scrolled down to reach the relevant details section.
Until now, in a master/details form, if the user opened the details page related to a record of the master table, the insert, delete and edit buttons were not displayed for the items table, regardless of the related permissions. A new parameter $details_page_dont_show_insert_edit_delete_items allows, if set to 0, to display the insert, delete and edit buttons of the items table (if the related permissions enabled them).
A new layout hook is available: [TABLENAME]['resultsgrid_header']['after_2']: the hook is triggered after the search filters of a results grid.

FIXED BUGS

Default values can now be used for date and date_time field types. Until version 10 they weren't officially supported but they worked anyway: this could lead to unexpected behaviours e.g. if an admin user, in the form configurator, set the default value for a text field and then changed the field type to date, the default value parameter disappeared but after saving it was recordered and used.
For date_time, insert_date_time, update_date_time field type, if you chose "between" as search operator the second input box element was a date field instead of a datetime field. Fixed.
The prepackaged dada sales app used the float data type instead of the decimal data type for the 'price' and 'price + tax' fields in the table products, this could lead to rounding errors. Fixed. You should re-install the app from scratch to be sure to have the fixed version or, instead, change the database field type for both fields to decimal(20,2) and the maxlength in form configurator for both fields to 15.
The prepackaged Dada Sales app produced a "Attack 08 detected. The script execution has been terminated." message for two of the built-in statistics. Fixed. You should re-install the app from scratch to be sure to have the fixed version or, instead, you can just update the URLs linked by DaDaBIK for the pages belonging to the "Statistics" category.
Default values using SQL: did not work for select_single and select_single_radio fields. Fixed. They work, however, only if the field is a lookup one (and it has been higlighted in the inline help).
After the installation of a new application after having used another, already installed, application you could get an 'Attack 02 detected' message. Fixed
It has been highlighted in the known bugs section of the documentation that if you have a master/details form having multiple detail tables, for the detail tables the switch classic grid/list doesn't work
The password encryption popup window did not use the language custom files (if any). Fixed.
Insert form, if a select_single or select_single_radio field was a calculated field, DaDaBIK did not make it disabled. Fixed.
DaDaBIK produced an error and/or did not work correclty during table installation if you customized the parameter $groups_table_id_field in config.php. Fixed.
If you set permissions for a custom page and then moved to the 'pages' tab, DaDaBIK produced an error. Fixed.
The 9.4 changelog stated: "In config_custom.php it has been highlighted that in case you want to set $timezone you have to paste an additional piece of code as well and that $start_year and $end_year are computed based on the $timezone you have in config.php." the first version of the changelog published online, however, didn't contain this item (it has been added about one hour after the release) so you might have missed it and consequently not updated your config_custom.php
An error message referred to a $enable_upload parameter , but the parameter is $enable_uploads. Fixed.
The v. 9.4 change log, fixed bugs, stated: "The config_custom approach introduced in DaDaBIK v. 9.3 didn't work and could lead to unexpected behaviours in two cases 1) you have set the parameter in config_custom OR" the correct sentence should have been: "The config_custom approach introduced in DaDaBIK v. 9.3 didn't work and could lead to unexpected behaviours in two cases 1) you have set the $prefix_internal_table parameter in config_custom OR". Fixed.
DaDaBIK, if used with PostgreSQL, showed in the pages tab the views as tables (views were showed also in in the views list). Fixed.
typos fixed
A message related to the security of the uploads_import folder said "The uploads_template directory is publicly accessible", the directory, however, was the uploads_import. Fixed.
The after-insert hook now fully works also with PostgreSQL: it now receives the value of the primary key of the record just inserted (if the unique field of the table is a serial field using a sequence with the default sequence name: "TABLENAME_FIELDNAME_seq")
The user password change operation was not logged in dadabik_logs. Fixed.
Calculated fields were not computed (or re-computed in case of update) in the insert/edit form if none of them were present (and not disabled) in the form. They were re-computed, however, afterwards, during the actual UPDATE or INSERT query execution. Fixed, now they are re-computed even in the form.
DaDaBIK produced a javascript error when, in a form, no custom required functions were set. Fixed.
If you set, for a field having edit permissions = yes but disabled, a custom required function in form configurator, the function was not executed in the edit form. Fixed.
Hungarian, Dutch, Finnish, Danish, Spanish and German translations updated.
The /apps/config_template.php file has been modified adding this line: $use_listbox_for_custom_function_selection = 0; If you have created prepackged apps, please add this to the config.php file of your package.
The documentation has been revised and improved.
The code of views/results_grid.php has been cleaned up

July 23, 2019
v. 9.4 Monterosso

NEW FEATURES

It is now possible to set if a custom button must be shown or not according to a custom function. This is useful if you want, for example, to show a button only for a particular users group (regardless of the permissions they have on the table) or if you want to show a button according to the state of a record (e.g. you don't want to show an "approve" button for a table "members" when a particular member is already approved).
You can now edit the title of your DaDaBIK application (html title tag) using the $title_application new parameter in config.php, without touching header.php.
Two new search operators are available: less_equal_than, greater_equal_than.
It is now possible to add a javascript confirmation dialog to custom buttons (paremeter 'confirmation_message'); only if the user confirm, the related function is executed.
It is now possible, only if granular permissons are enabled, to set the permissions for a custom page as VIEW: yes, but don't show in menu. This can be useful if you want to use a page in your DaDaBIK applicaton but you don't want DaDaBIK to display the related menu item (for example, you could call it from a custom button).

FIXED BUGS

DaDaBIK suffered from a SQL injection vulnerability which could allow an attacker to execute arbitrary SQL code by using a proper string as a table/view name for a table/view available in the database used by DaDaBIK. The kind of SQL operations allowed depended on the permissions granted to the database user ($user in config.php) and the SQL code could be executed (if the user had the permissions) even on other databases, different from the application's database.

The vulnerability has been fixed but was, however, quite difficult to exploit: the sql code needed to be part of a table/view name so the attacker needed to create or rename a table/view in the DaDaBIK database. The malicious SQL code, then, could be executed by running the 'pages' tab of the admin section (even unawares by a 'normal' admin user, not necessarily by the attacker).

Furthermore, the possibility to exploit the vulnerability depended on the possibility to run, in your DBMS environment, multiple SQL statements using a single PDO query execution. If you used MySQL, a recent DaDaBIK version ( >= 9.2.1), a recent PHP version (PHP 7 or PHP 5.6 >= 5.6.5 or PHP 5.5 >= 5.5.21) and you had $disable_mysql_multiple_statements =1 in config.php, you were safe.
DaDaBIK now uses tcpdf v. 6.2.26: this fixes bugs and security issues that the version previously used by DaDaBIK had.
With PHP >= 7.2, DaDaBIK could produce a 'Deprecated: The each() function is deprecated.' message when a PDF was produced. Fixed.
DaDaBIK, if used with MS SQL SERVER, could produce in some cases this error message 'A column has been specified more than once in the order by list'. Fixed.
The documentation about custom buttons said that for the callback function in some cases $where_field and $where_value were not set. In those cases, they actually were "empty string" and now (9.4) they are NULL, as the documentation says.
The documentation about custom buttons didn't explain what happens when you used a permission for a custom button (e.g. the delete permission) and the current user has such permission set to MY or there is a row-level custom filter set. It is now highlighted that if, for the current user, the permission is set to YES or MY, the button is showed (regardless of the record); however, if a user clicks the button for a record he/she doesn't own, he/she will get an error. This is valid just for php_standard and php_ajax callback functions, though: for a javascript callback function, all the users having such permission set to YES or MY will be able to execute the function. The same thing happens for Row-level Custom Filters.
DaDaBIK 9.3 didn't correctly set the default timezone (used by all date/time functions) specified in config.php and tried to get it from php.ini (if set) or from the Operating System. This could also produce one or more warning messages such us "Warning: date(): It is not safe to rely on the system's timezone settings......". Fixed.
If you enabled the 'user-friendly searchable' option for a field, after an insert operation DaDaBIK could produce a 'PHP Notice: Undefined variable: show_edit_form_after_error' message. Fixed.
Custom pages, when $enable_granular_permissions was set to 0, were not displayed/executed, even if they were enabled (the page could work if you set the permissions from the current group before disabling granular permissions). Fixed.
The documentation file how_to_create_a_packaged_app.txt contained wrong content (last paragraph, now removed).
DaDaBIK produced an error when a search was performed using the "less than" operator on a date, insert_date_time or update_date_time field. Fixed.
The config_custom approach introduced in DaDaBIK v. 9.3 didn't work and could lead to unexpected behaviours in two cases 1) you have set the $prefix_internal_table parameter in config_custom OR 2) you use MS SQL Server as DBMS. This problem was silently fixed a few days after the release so you might have a fixed version already (see https://dadabik.com/forum/read.php?1,21579 for details). Furthermore, it has been highlighted (again, in the same silent update) that if you want to use a custom users or groups table (you want to change $users_table_name or $groups_table_name) you cannot use the config_custom file, you have to edit all your parameters in the config.php file.
In config.php, $disable_mysql_multiple_statements parameter, the instructions said: "if you are running PHP 5.5.21 or PHP 6 < PHP 5.6.5 this parameter doesn't have effect", the correct sentence is obviously "if you are running PHP 5.5 < 5.5.21 or PHP 5.6 < PHP 5.6.5 this parameter doesn't have effect". Fixed.
Characters ; and \ where accepted as column names for CSV/MS Excel files during an installation based on CSV/MS Excel, however they didn't work properly after installation, since DaDaBIK does not accept those characters as field names. Fixed, the characters are now replaced with underscore.
For date_time, insert_date_time, update_date_time field type, if you chose "between" as search operator the second input box element was a date field instead of a datetime field. Fixed.
In config_custom.php it has been highlighted that in case you want to set $timezone you have to paste an additional piece of code as well and that $start_year and $end_year are computed based on the $timezone you have in config.php.
The before delete hook was executed even with DaDaBIK PRO. Fixed.
A message related to the security of the uploads_import folder said "The uploads_template directory is publicly accessible", the directory, however, was the uploads_import. Fixed.
Typos fixed in config.php
At the end of the upgrade process, a mesasge now suggests to remove, for security reasons, the install.php and upgrade.php files

May 29th, 2019
v. 9.3 Monterosso

FIXED BUGS, NEW FEATURES AND OTHER CHANGES

When you displayed a recordset in DaDaBIK and the number of records required pagination (number of records > records per page), it could happen that, if you are browsing, page by page, the recordset, you saw the same record twice (in two different pages) and, even if you are browsing all the pages, you didn't see all the records belonging to the recordset. This could happen if you were NOT sorting the recordset by a unique field (more precisely, a field containing no duplication in the recordset). The recorset could be the results of a search or not (just table browsing), this didn't impact on this issue. Please note that even if you don't notice this issue, it may arise under particular circumstances (it depends on the DBMS's query execution plan). Fixed. The fix for this bug relies, as many other features in DaDaBIK, on the existence of a primary key in your tables.
A new file, config_custom.php can be used to set your configuration parameters without directly editing config.php. This makes your DaDaBIK upgrades easier.
If a field was the child of a cascade drop-down list and was not displayed in a form (while the parent was), after having choosen the parent value DaDaBIK hanged out. Fixed.
The form configurator in-line help, for the ID_user field type, said that "a ID_user field is automatically excluded from the insert form" but for this field type the user MUST exclude it manually. Documentation fixed.
The Hungarian translation has been updated and improved.
Typos fixed.

March 5th, 2019
v. 9.2.2 Monterosso

FIXED BUGS, NEW FEATURES AND OTHER CHANGES

DaDaBIK produced an "Attack 07 detected" and / or a "Attack 08 detected" during chart generation if one or more field names contained capital letters. Fixed.
If you changed the order of the fields in your database schema and then (without or without adding new fields to the table) you used the "Add Fields" function (DB Synchro), you lost your form configuration settings for one or more fields of the table. Fixed.
DaDaBIK now uses the last versions of htmLawed: 1.2.4.1; this can fix security problems and other issues that the old htmLawed version used could cause.
DaDaBIK produced a "Deprecated: Function create_function() is deprecated" message if used with PHP 7.2. Fixed
A known bug related to PostgreSQL has been added: If you use cascade fields and the cascade parent field is a numeric field, you might get a "SQLSTATE[22P02]: Invalid text representation" error.
The parameter $lenght_separator_display_linked_field allowed to set the separator character to use while displaying several lookup table linked field values related to the same field, but only in data grid and details page, while the separator character for edit, search and quick search fields was always " - "; a new parameter, $lenght_separator_display_linked_field_2, allows to set such separator for edit, search and quick search fields.

December 19th, 2018
v. 9.2.1 Monterosso

FIXED BUGS AND OTHER CHANGES

DaDaBIK suffered from SQL injection vulnerabilities which could allow an attacker to execute arbitrary SQL code by adding a proper string to the application URL or by injecting the malicious code in some other forms such as table/field names or form configurator parameters. The kind of SQL operations allowed depended on the permissions granted to the database user ($user in config.php) and the SQL code could be executed (if the user had the permissions) even on other databases, different from the application's database.

In all the situations, the attacker needs to LOGIN in your DaDaBIK application first to exploit the vulnerabilities (IF you have authentication enabled, otherwise anyone can exploit the vulnerabilities), so the attacker needs to be a user of your application UNLESS they can access the database from other applications or directly (not via DaDaBIK).

The vulnerability has been fixed. You are STRONGLY encouraged to upgrade. In config.php, at the end of the section "authentication and security parameters", you will find three new parameters which allows to disable some of the new security checks that DaDaBIK does. They are there just to make the upgrade smoother in case of problems, but you are strongly encouraged to leave the default values.

After having upgraded, change the parameter $dadabik_session_name in config.php; this allows to make invalid all the current sessions that might have potentially dangerous content. In general, for your application, changing $dadabik_session_name each time you upgrade it, using a name you haven't used in the past, is a good security practice (if you use the Wordpress DaDaBIK Wrapper, you must change the session name there as well).
It was possible to use a table as "Lookup table name" even after its uninstallation. Fixed."
Semicolon is a new, additional, not-allowed character for table and field names.
DaDaBIK produced a warning message in some cases when a graph was generated. Fixed.
DaDaBIK could produce a "Notice: Undefined index: doesnt_contain.." warning when the Chinese or Norwegian language was set. Fixed.
The documentation said that, for MySQL, the BIT field type was not supported. It has now been highlighted that, more in general, for all the DBMS, BIT and Boolean field types are not fully supported; the use of INT (1/0) or char(Y/N) is advised.
For a public (authentication disabled) application using the parameter $username_public_user, the login button on mobile devices took to the wrong URL. Fixed.

November 7th, 2018
v. 9.2 Monterosso

NEW FEATURES AND FEATURE CHANGES

A new search operator, BETWEEN, is now available. You can use it with date* an text field types. When you select between from the search operator menu, an additioal textbox appears and allows you to specify the interval between two dates, two numbers or even two generic strings. A typical use is the search in the interval between two dates.
DaDaBIK now supports Microsoft SQL Server (in addition to MySQL, PostgreSQL, SQLite) through the pdo_sqlsrv driver.
For insert and update forms, DaDaBIK now tries to guess if all the data has been submitted (checking for an hidden field value): the php.ini parameter post_max_size can, in fact, limit the amout of content that can be submitted through a form and PHP doesn't produce an explicit error in case of violation; this can lead to unexpecrted results. Now DaDaBIK checks for an hidden field that always has the same value: if the value is not available after submission, it means that post_max_size could have been exceeded and therefore DaDaBIK produces an explicit error and stops the execution of the script.

FIXED BUGS

When you added a new item record in a master/details form, the (disabled) select_single field representing the primary key of the master table showed the value of the current master table record. This, however, didn't happen if the "Use ajax to load options?" parameter was set to yes. Fixed.
After having inserted a record in a table that was details in a master/details form, the insert form was showed again (if the user didn't have read permissions on such table, as normally happens with details table) instead of redirecting to the relevant record of the master table. This happened even if $insert_again_after_insert was set to 0. Fixed.
An installation from an Excel/CSV/ODT file produced an error in some cases when one or more column names contained special characters like -. Fixed.
Chart generation: it has been highlighted that if the user creates an advanced SQL report, the current active search filter (if any) wont't be used.
In the config file, two comments "feature not available for SQLite" and "feature not available for PostgreSQL" erroneously stated that the auto-configurator feature was available only for MySQL, this is not true. Fixed.
Form configurator, "Use Ajax to load options": it has been highligthed that the options only works for lookup fields, not for hard-coded lists.
Form configurator, "user-friendly searchable": the in-line help said the Chosen plugin is used to implement the feature; wrong, the plugin is select2 since V 8.2. Fixed.
Form configurator, in-line help for search operators: it has been highlighted that the less_than operator needs to be typed as less_then, this issue will be fixed soon.

September 12th, 2018
v. 9.1 Monterosso

NEW FEATURES AND FEATURE CHANGES

Row-level custom filters
It is now possible to define, for each table/view, a custom PHP function that provides an additional row-level custom filter. This is useful when you want to filter your records by some criteria which is not related to the ownership; take a helpdesk application, for example: let's say the help requests are inserted by some managers and each help request is then assigned by a manger to a member of the IT staff group; you might need to filter the requests so that each member of the IT staff can only see the requests assigned to them.
The new config parameter $show_edit_button_in_details allows to display an EDIT button in the record details page.
In the results grid page, the page navigation links (page 1 of x) are now displayed also at the bottom of the results grid. You can disable this feature by setting the new $show_navigation_bar_bottom paramter to 0 in config.php
It is now possible to set, using the new config parameter $unique_ID_custom_function, a custom function to use to generate IDs for the unique_ID field type.
It is now possible to define a custom startup function (see custom startup function in custom_functions.php) that is executed every time a DaDaBIK page is run.
The current database name is now showed in the top right corner of the admin pages.

FIXED BUGS

The Dada sales app had, among the tables / fields configured, two tables (and related fields) that weren't actually part of the database and among the permissions, the permissions related to a group (group id 4) whih was not one of the three groups avaialble in the app. This could lead to conflict in form field settings in case the developer added to the app a table having the same name of one of the two tables; futhermore when a new group was added, this group automatically took all the permissions already available (by mistake) for the id_group 4, so those permissions were granted to a group just created that shouldn't have had any permission. The same problem (automatic permissions granting) happened in case the developer added a new table to the app having the same name of one of the two tables mentioned before. Fixed. You should re-install the app from scratch to be sure to have the fixed version.
In the custom_functions file, calculated fields, it has been highlighted that if you need to use a field value for the calculated field function, the correspondent field cannot be disabled in the edit form. If a field is disabled, in fact, after having pressed the SAVE button DaDaBIK cannot access the value of the field and therefore the calculated field value would be wrong.
Documentation, upgrade section: it has been highlighted that keeping the old custom_functions.php and custom_functions.js files during an upgrade is not a good practice; the default custom_functions.php and custom_functions.js files may change when a new version comes out (for example, more documentation in form of comments can be available, and this may affect your functions) you should, instead, read the new custom_functions.php and custom_functions.js files and then copy your custom functions into the new files. Normally, if there are changes in the files that you should be aware of, this is mentioned in the changelog file.
The form configurator in-line help, for the unique_ID field type, said that "a unique_ID field is automatically excluded from the insert form" but for this field type the user must exclude it manually so the sentence is now "a unique_ID field must be excluded from the insert form". Furthermore, it has been highlighted that the unique_ID field type is NOT a field type to use for primary key, autoincrement, database field types.
In the documentation, security section, it has been highlighted that If you use SQLite, you should store your SQLite database file outside the Web root or protect it from public acces, otherwise anyone who knows the URL of the file can access it, even without logging-in.
Both the bundled apps, when installed, showed a wrong DaDaBIK version number in about/check upgrade. Fixed.
DaDaBIK showed a "Base table or view not found" error when the application was executed before installation. Fixed. Now a more explicative message is displayed.
The "insert as new" button was displayed in the edit form even if the current user didn't have insert permissions (the insert operation, however, wasn't processed). Fixed.
It has been highlighted that, for editing custom functions of a prepackaged app, the files to edit are custom_functions_prepackaged_app.php and custom_functions_prepackaged_app.js
The German translation has been completed and updated.
The Hungarian translation has been updated.
Some characters of a few french translations were corrupted. Fixed.
When two or more tables were added in master/details view to a table, the "items per page" menu for those table didn't work. Fixed.
DaDaBIK when used with PHP 7.2 produced several 'Warning: count()' messages. Fixed. (you could have a 9.0 version where this bug was already fixed since a silent upgrade was released)
DaDaBIK produced errors and warnings if the current user didn't have permissions for none of the table/view-based pages. Fixed. (you could have a 9.0 version where this bug was already fixed since a silent upgrade was released)
The Dada sales app didn't have "doesn't contain" among the default search operators
The upgrade online registration sometimes didn't work. Fixed. (already fixed in 9.0 but not highlighted in the changelog)

July 5th, 2018
v. 9.0 Monterosso

NEW FEATURES AND FEATURE CHANGES

Build a DaDaBIK application starting from an Excel/CSV/ODS file
It is now possible, during the installation, to build a DaDaBIK app starting from an Excel, CSV or ODS file: you just need to upload the file and DaDaBIK will create the relevant database tables and build an application over them.
Prepackaged apps
You can now create a DaDaBIK app package: a folder containing a manifest.json file (that describes the app) and all the relevant files (custom functions, SQL scripts, custom images, .... ); any DaDaBIK owner can install your app just by copying the package in the new apps folder and choosing the app during the installation process.
Bundled prepackaged apps
DaDaBIK Enterprise/Platinum comes with two bundled prepackaged apps: Dada sales (a sales management application) and Dada HelpDesk (a HelpDesk application. It can be used within a company to manage, for example, the IT help requests). You can install them directly from the installation procedure. At the moment, they are only available for MySQL.
Custom buttons
You can now add personalized buttons to your application, specifying for each button a callback PHP or Javascript function to execute. Buttons can be placed in several positions (for example on each row of a results grid, on the top of an edit form or near to a form field) and can execute a Javascript function or a PHP unction, even via AJAX.
Dashboards
It is now possible to embed a graphic report or a tabular report into a custom page; when logged in as an admin, you can get the embed code by clicking on "show embed code" at the bottom of a graphic report. By embedding one or more reports into a custom page you can easily create a dashboard.
Granular permissions for CSV Export and Custom pages
- You can now assign permissions to the "Export to CSV" operation, as you do with any other operation (insert, edit, delete, ...); this means that, for each users group and each table/view, you can set if the users group is allowed to execute an export to CSV operation on that table and on which field. If granular permissions is set to 0, you will just be able to enable or disable the export to CSV for each table.
- Custom pages are now covered by permissions as table/view pages are. For each custom page, you can choose if a group can view the page or not using the permissions section of the admin area.
Record copy
A new "copy record" feature is available: when you enter a record in edit mode, you can click on 'insert as new' to insert the current record as a new record instead of saving it. Furthemore, you can check the 'multiple inserts' checkbox to get again, after an insert operation, the edit form that allows you to insert another record starting from the values of the one previously inserted. A new configuration parameter, $show_multiple_inserts_checkbox, allows to display/hide the checkbox (by default, the checkbox is displayed). Please note that 'insert as new' doesn't work for generic_file / image_file fields and that, if the record is a master of a master/deails view, the details records are not 'copied'.
Easier layout customization with layout hooks
With layout hooks you can add custom HTML or PHP code in some parts of the layout without modifying the DaDaBIK core code and therefore making future upgrades easier. There are 13 layout points (including, for example: page header, page footer, edit form header, edit form footer, ...) where you can add layout hooks. See the documentation for further details. Furthermore, the logo is not part of the core code anymore, it's a parameter in config.php.
It is now possible to make part of your DaDaBIK application public, even if $enable_authentication is set to 1. By defining who is the "public" user in config.php (parameter $username_public_user), you can assign permissions to work on some pages/tables to unauthenticated users. This can be useful in several cases, for example you want to allow unathenticated users to read a public dataset or you want to open to the public a registration form or a contact form.
It is now possible, for each field, to specify a custom Javascript function to execute when a particular event (e.g. onfocus, onblur, onclick, ...) occurs. For example you can write a simple Javascript function that capitalizes the content of a text field when the user leaves the input field ('onblur'). For each form field, in form configurator, you can specify a list of events and for each event the corresponding Javascript funtion to execute.
Before insert hooks are now available; an example of use case: you want to modify the form input values, according to some custom logic, before the actual insertion.
Admin area: the graphic layout has been improved.
A styles_screen_custom.css file is now available: you can add your own custom styles, this helps you when you have to upgrade DaDaBIK (you can keep your custom file, while the other CSS files will be overwritten).
Wordpress plugin installation instructions improved.
The word "website" is now used as a hint, for field names, to guess the content of the field is an url.
A new parameter, $force_reload_css_js, allows to prevent caching of CSS and JS files (useful when you are changing them during the development process).
A new parameter, $apply_function_user_values_to_textarea_richeditor, allows to apply the funciton defined in $function_user_values also to textarea and rich editor fields.
A new config.php, $dont_show_menu_if_only_one_item, allows to hide the menu when, for the current user, there is just one menu item available.

NEW REQUIREMENTS

Part of the DaDaBIK code is now encrypted with Ioncube, therefore you need the free ionCube loader (https://www.ioncube.com/loaders.php).

FIXED BUGS

The memory usage, respect to DaDaBIK 8.3, has been drastically decreased for most of the functionalities.
In a master/details form, in edit mode, changing the "items per page" via the records per page form redirected the user to a page containing ALL the records belonging to the details table, regardless of the master record. Fixed.
If a record has, as primary key value, an alphanymeric value that needs to be escaped (e.g. contains a quote), the files contained in the record were not be showed/correctly linked in the details page and the file link from the edit form did not work. Fixed. This was supposed to be fixed in v. 8.3 already but, only for generic_file fields, the problem in some cases still occurred.
The Hungarian language has been updated.
The "doesn't contain" search operator was not set by default during installation. Fixed.
If you had a custom required function or a calculated field funciton which is based, in input, on the value of a select_single_radio field, the value of the select_single_radio field was not correctly passed to the function. Fixed.
DaDaBIK produced two undefined index (csv and csv_authorization) error messages when granular permissions were set to 0. Fixed.
It has been highlighted that select_multiple and file fields cannot be used as a source for a custom required or calculated field function and that, for select_single_radio fields, if the user didn't select any of the options, the corresponding key in $parameters_ar will be unset.
TinyMCE (the editor we used for the rich_editor field type) has been upgraded to v. 4.7.13; this fixes all the issues in the previous versions, including a problem with some versions of Chrome: you needed to press the tab button before entering text in the editor.
For select_single and select_single_radio fields, when the insert form is displayed again after an insert because of a validation error (e.g. a missing required field), the selected value of the select_single* field could become the default value (if any) and not the value selected by the user before submitting the form. Fixed.
The copy settings in form configurator didn't work if $prefix_internal_table was not the default one: 'dadabik_'. Fixed.
In the hooks instructions it has been highlighted that the delete hooks don't work with 'delete all' operations.
The check of the DaDaBIK last release in "about/check upgrade" sometimes didn't work. Fixed.
The installation online registration sometimes didn't work. Fixed.

Apr 11, 2018
v. 8.3 Lerici

NEW FEATURES AND FEATURE CHANGES

Export to PDF
A new "Export to PDF" feature is now available: you can use it both from the details page of a record and from the results grid page: in the first case it produces a PDF file containing the information available in the details page, in the second case it produces a PDF file containing N pages, one for each record included in the results grid page (taking in to account the current search filter, if any). For master/details forms, only the "master" part is exported.

You can also create an optional custom template file that describes the layout of the PDF document and DaDaBIK allows the user to choose which template file to use, on the fly, during the export to PDF process. The syntax of the template is pure HTML, combined with one or more "placeholders" that you can use to add the values of table fields. The conversion between the HTML template and the PDF document is executed using the TCPDF library (https://tcpdf.org/).

The export to PDF feature applied to a record results set, in combination with the use of custom templates, guarantees results similar to the ones you can get using a typical "Mail Merge" feature available in Word Processors. Let's say for example that you want to send a (paper) mail to all your customers who live in a particular city: you can do it by searching the customers by city and export as PDF the results set, using a template that contains the letter and a name placeholder that will be automatically filled with the name of each of the customer.
New form validation
The form validation has been improved to make it more user-friendly: if an error occurred (missing required or not valid field) the corresponding field is now highlighted with a red border; futhermore, the field type checking is now performed once for all the form fields so you if you have more than one wrong value in your form you can see multiple error messages at the same time.
A new config.php parameter, $dont_show_menu_if_only_one_item, allows to hide the menu when, for the current user, there is just one menu item available.
Revisions of the files structure: now the files containing the functions more related the generation of the user interface (build_form, build_form_element, build_results_table, build_details_table) are each in a different file and all in the views folder.
The $alias_prefix parameter is now, by default, ____ instead of __

FIXED BUGS

DaDaBIK suffered from an SQL injection vulnerability which, in some situations, could allow an attacker to execute arbitrary SQL code. The kind of SQL operations allowed depended on the permissions granted to the database user ($user in config.php) and the SQL code could be executed (if the user had the permissions) even on other databases, different from the application's database.

Here is the list of situations that an attacker can potentially exploit:

1) You have a lookup select_single* field having all the following characteristics:
- the database field type is alphanumeric (e.g. Varchar, Text, ... )
- the potential attacker can insert data in this field (has insert or edit DaDaBIK permissions or can access the field in other ways, not via DaDaBIK)
- it is a field on which the cascade option is enabled OR the linked table has read permissions set to "MY"

2) You have a lookup select_multiple* field having all the following characteristics:
- the database field type is alphanumeric (e.g. Varchar, Text, ... )
- the potential attacker can insert data in this field (has insert or edit DaDaBIK permissions or can access the field in other ways, not via DaDaBIK)

3) You have a table/view having, as DaDaBIK unique field, a field having the following characteristics:
- the database field type is alphanumeric (e.g. Varchar, Text, ... )
- the potential attacker can insert data in this field (has insert or edit DaDaBIK permissions or can access the field in other ways, not via DaDaBIK)
- for the corresponding table, duplication check is enabled

4) You use custom users or groups tables where the id_user or the id_group (in the users table) or the id_group (in the groups table) fields are alphanumeric database field (e.g. Varchar, Text, ... ) and the potential attacker can insert data in such fields (has insert or edit DaDaBIK permissions or can access the field in other ways, not via DaDaBIK)

5) The potential attacker can insert data in the username field of the users table (has insert or edit DaDaBIK permissions or can access the field in other ways, not via DaDaBIK)

In all the situations, the attacker needs to login in your DaDaBIK application first (if you have authentication enabled) to insert the malicious code in the field, so the attacker needs to be a user of your application UNLESS they can access the database from other applications or directly (not via DaDaBIK).

The vulnerability has been fixed. You are STRONGLY encouraged to upgrade.
The use, in a DaDaBIK application, of tables and fields whose names contain quote characters, blank spaces, dots and characters which need to be esacped (such as \, NULL byte), can lead to problems and security issues, the same for field names containing the value set in config.php for alias_prefix, null_checkbox_prefix, select_type_selct_suffix, as described in the documentation. Starting from DaDaBIK 8.3 this problem is not only documented, a series of changes have been made to highlight it in the application and to prevent the use of such tables / fields.
For select_single and select_multiple fields, if 'use ajax to load options' was selected and the value of the option (primary key field) or the text content of the option (linked field) contained characters escaped by htmlspecialchars (see http://php.net/manual/en/function.htmlspecialchars.php), the corresponding conversion, instead o the real character, was saved in the DB (or displayed in the page). Fixed.
Searching values containing % or _ using the contains, starts_with or ends_with operators could lead to wrong search results. This was a known DaDaBIK bug and it is now fixed. The problem arised also with the operator doesnt_contain and, for select_multiple_menu and select_multiple_checkbox fields, also with is_equal and is_different. This second, related part of the bug has also been fixed.
If a record has, as primary key value, an alphanymeric value that needs to be escaped (e.g. contains a quote), the files contained in the record were not be showed/correctly linked in the details page and the file link from the edit form did not work. Fixed.
For select_multiple lookup field, if the linked table name or one of the linked field name contained non-ASCII characters, DaDaBIK produced a query error in resulst grid, details page and while creating the CSV. Fixed.
For lookup select_single and select_multile fields with the user-friendly searchable option enabled it was only possible to search an option 'by column' (by linked field), see https://dadabik.com/forum/read.php?1,19695 for deatils. Fixed.
If, for a select_multiple_* field, the value stored in the field does not correspond to any record in the linked table (something that in a real world application normally does not happen), DaDaBIK produced a warning in results grid e details page. For the results grid, DaDaBIK also filled the corresponding cell with the value of the next cell, moving every field value of the record after the select_multiple_* field to the cell on its left. If exported to CSV, the field was also handled in a wrong way (the quote for the field was not closed). Fixed.
Form configurator, in-line help: it has been highlighted, for the 'where clause' parameter, that PHP variables need to be used with cautions: since their values, UNESCAPED, will become part of an SQL query, the developer should make sure they canoot assume values that need to be escaped (e.g. quotes) to avoid unexpected behaviours and security issues.
When a custom users or gorups table is in use, the id_user and id_group fields must be INTEGER and PK to avoid unexpected behaviours and security issues. This is now highlighted in config.php (previously the reference was 'numeric field and PK') and displaying a warning message at the top of all pages.
DaDaBIK, during the installation, produced an error if a table name contained blank spaces or dots and all the field names of the tables don't.
Usernames or group names containing single quotes produced query execution errors after some operations.
The ajax options loading didn't work correctly for select_single/select_multiple fields when used from the details form of a master/details view. Under particular circumstances, the ajax options loading didn't work also when used from the master for a master/details view. Fixed.
For lookup fields, when the Lookup table name was changed in form configurator, the fields 'Cascade parent field' and 'Cascade filter field' were filled in the wrong way (the content of the first one was used for the second and viceversa). Fixed.
Tha Spanish translation has been improved and completed.
The children of a cascade drop-down menu, after options refreshing, was always set to 'user-friendly searchable: yes'.
The user-friendly searchable option for select fields now works also on mobile. (This was true in DaDaBIK 8.2 already but it was not mentioned in the changelog)
Minor HTML mistakes fixed.

Dec 19, 2017
v. 8.2 Lerici

NEW FEATURES AND FEATURE CHANGES

Ajax autocomplete for dropdown lookup menu: DaDaBIK can now load on demand (AJAX) the options related to a dropdown lookup menu (select_single or select_multiple_menu) while the user is typing on the menu form element. This is extremely useful to avoid delay in form creation when the number of options is very huge: the menu are in fact created without loading any options, the options are loaded only when the user starts typing. This feature has been implemented using the Select2 jQuery plugin (https://select2.github.io/), which replaces the Chosen jQuery plugin we used in the past.
It is now possible to define through config.php the default function to execute for menu items related to pages based on tables/views; for example you can set, for the table 'customers', to show the insert form instead of the results grid.
For PostgreSQL, DaDaBIK can now be installed choosing a specific schema (before, it worked only in the 'public' schema). Please note that creating a DaDaBIK application having tables/views coming from different schemas is still not possible.
Chinese language is now available.
The table dadabik_users was not ready to be extended so when, from DB synchro, new fields were added, the synchronization didn't work and the form configuration settings of the table were lost. Fixed. Now the schema of the dadabik_users table can be extended as any other table but this works only for fresh DaDaBIK installation, for DaDaBIK installations made with DaDaBIK v. <= 8.1 and then upgraded it doesn't work.
The back and prev next buttons are not displayed anymore when printing a record details page.

FIXED BUGS

The parameter 'User-friendly searchable' impacted only on the search form, not on quick filters. Fixed.
Table names used in master/details form were not correctly quoted so DaDaBIK produced SQL errors if they contained special characters (e.g. my-table). Fixed
The 'copy settings' feature in form configurator didn't copy the value of the 'user-friendly searchable' parameter. Fixed.
DaDaBIK didn't apply custom validation functions to date and date_time field types. Fixed.
A new config parameter, $results_display_mode_menu, allows to chose if the results display mode menu (classic_grid, list) needs to be displayed or not and if not which is the default results grid display mode.
A new config parameter, $default_order_type, allows to choose the default sorting type (ascending or descending) for the results grid.
For several languages, the sentences 'Page x of n' was not correctly translated anymore. Fixed.
The in-line help in form configurator let the developer assume that custom validation functions were applied to all field types except from select_single and select_multiple. It has been highlighted that they are actually applied only to text, textarea, rich_editor, date and date_time field types.
Documentation: in form configurator, min width parameter, on-line help, it has been highlighted that also affects the way text is arranged in the results grid.
Documentation: it has been highlighted that DaDaBIK automatically assignes a unique file name to the file the user uploads.
When you installed a table/view from the pages section, DaDaBK produced an error if the list of installed tables/views was empty. Fixed.
DaDaBIK + MySQL produced a 'Specified key was too long' error message if used with some multibyte charsets other than utf-8. Fixed. Please note, however, that the use of utf-8 is still STRONGLY recommended for MySQL and PostgreSQL and it is compulsory for SQLite. (This bug was suppoesed to be fixed with DaDaBIK 8.1 but it was fixed only for applications upgraded to 8.1, not for fresh installations).
The form settings copy function didn't copy the value for the parameter 'Min width (in px) of the results grid column'. Fixed.
DaDaBIK produced a Notice: Undefined variable: linked_table_installed warning in the results grid page when a select_multiple field had a NULL value. Fixed.

Sep 5, 2017
v. 8.1 Lerici

NEW FEATURES AND FEATURE CHANGES

Chosen jQuery plugin
DaDaBIK now optionally provides, for select_single and select_multiple_menu fields, a search box that allows to easily find a list element when the number of elements is huge. Furthermore, for select_multiple_menu, a new and more user friendly approach is used to display the selected values. These new features are implemented using the Chosen jQuery plugin (https://harvesthq.github.io/chosen/) and can be enabled for each field in form configurator (parameter 'User-friendly searchable').
Before delete hooks
"Before delete" hooks are now supported.
Exclusion of some tables during installation
It is now possible to exclude from the installation some tables using the $tables_to_exclude and $prefixes_to_exclude parameters in config.php. The $prefixes_to_exclude parameter, in particular, is very useful to easily install and use two or more different DaDaBIK applications using a shared database: for each application you need a different $prefix_internal_table and you need to set, for $prefixes_to_exclude, all the prefixes used by the other applications. A typical example is the creation of a view-only app that doesn't require authentication e.g. mysite.com/public and another - full-featured - app accessible only by admin, e.g. mysite.com/admin, sharing the same database.
Permissions for autoincrement fields
It is now possible, setting the new $grant_permissions_autoincrement_after_table_installation parameter to 0 in config.php, to hide by default autoincrement fields from all the forms during a table installation or during the application installation. This is often useful because normally you don't want to see 'ID' fields in your forms, especially in the insert forms (you want the value to be automatically generated and assigned). Of course you can alwasy remove the permissions (and hide a field from a form) later. This parameter currently works only with MySQL.
The documentation has a new paragraph explaining how to share the same database between two or more DaDaBIK applications.
In addition to "contains", a new search operator, "doesn't contain" is available.
Norwegian language is now available.
A new config.php parameter, $open_url_field_type_new_window, allows to open URL field type links in a new page (target _blank).
For lookup fields, the link to the related record now opens the details page instead of the edit page. A new config.php parameter ($function_link_to_record) allows to choose between edit and details.
A new config.php parameter, $open_blank_generic_file, allows to choose how to open a generic_file/image_file link (_self or _blank).
It is now possible to specify in config.php a custom function (parameter $function_user_values ) that DaDaBIK applies before INSERT and UPDATE to all the values inserted by users through textboxes.
In-line help in form configurator related to search operators and select_multiple_* field types provides now a clearer explanation.
During the installation producere, when PostgreSQL is used, a message now reminds that by default queries are case sensitive.
Added some instructions to the DB Synchro page.

FIXED BUGS

During a search, a select_multiple_menu/select_multiple_checkbox field was always connected to the next search parameter using the AND boolean operator, regardless of the operator chosen for the search (any condition Vs. all condition). This, therefore, could produce wrong search results if a search form or a quick filter contained a select_multiple_menu or select_multiple_checkbox field. Fixed.
After a db syncro -> add fields, DaDaBIK lost the settings related to the related table for the following properties: Calculated field function / Show link to record? / Min width (in px) of the results grid column. Fixed.
Graph report generation didn't work properly and produced an error if the field chosen for the X-axis was a lookup field and its name was different from the dadabik 'Lookup table primary key field'. Fixed.
Calculated fields were disabled in search forms. Fixed.
DaDaBIK + MySQL produced a 'Specified key was too long' error message if used with some multibyte charsets other than utf-8. Fixed. Please note, however, that the use of utf-8 is still STRONGLY recommended for MySQL and PostgreSQL and it is compulsory for SQLite.
The example of hook function in custom_functions.php was wrong, there was a missing code line. Fixed.
Pagination links didn't work correctly when the results grid was part of a master-details view, only page 1 was displayed correctly. Fixed.
After installation, pages -> menu order was numbered starting from 3 instead of 1. Fixed.
DaDaBIK image_file and generic_file field types didn't work correctly if the related table didn't have read permissions and was part of a master/details view as the item table.
The check_sessions script produced an error messages. Fixed.
[fix] DaDaBIK produced an 'undefined index' notice when an insert or update was executed in a form containing a calculated field. Fixed.
The 'Copy settings' function in form configurator showed a button 'Copy permissions' instead of 'Copy settings'. Fixed.
The installation code was not showed in the about page if PHP short tags weren't enabled. Fixed.
Under particular circumstances DaDaBIK produced a 'PHP Notice: Undefined variable: site_url' message. Fixed.
DaDaBIK during edit and insert operations produced, under certain circumstances, a 'PHP Notice: Undefined index' message. Fixed.
Permissions copy on Postgres produced a 'Indeterminate datatype: 7 ERROR'. Fixed.
DaDaBIK on PostgreSQL produced a 'ERROR: bind message supplies 1 parameters...' when the copy permissions feature was used without specifying a table. Fixed.
Even when authentication was disabled, on small screens DaDaBIK showed the 'logout' and 'your account' buttons. Fixed
In some PHP environments, the online registration of a DaDaBIK installation didn't work. Fixed.
Under certain circumstances, DaDaBIK produced a '[08] Error: during last ID fetching. ' error with PostgreSQL during insert. Fixed.
With DaDaBIK PRO edition, custom pages having type internal or external link didn't work. Fixed.
DaDaBIK produced a deprecated warning if used with PHP7. Fixed. The issue was related to phpass 0.3, now upgraded to the last 0.5 (see the phpass release notes to get details about other issuses fixed from 0.3 to 0.4)
An insert_date_time or update_date_time field could produce a required error even if the field was not displayed in the form and automatically filled by DaDaBIK. Fixed.
DaDaBIK, if used with PostgreSQL, produced a 'Unique violation: 7 ERROR: duplicate key value violates unique constraint' error when an admin added a user, a group or a custom page. Fixed.
Fields having a custom formatting function set and NULL value were displayd as blank instead of NULL and therefore the option didn't apply. The same for select_multiple fields having a NULL value. Fixed
The in-line help in form configurator related to field types now highlights that, for the unique_id field type, the corresponding database field type must be varchar(50). A length less than 50, depending on the server settings, can lead to problems such as silently truncate the string produced for the unique_id field before storing the string itself in the database.
Form configurator, in-line help: it has been highlighted that you cannot specify as linked field a select_multiple field or a field that has, in turn, linked fields associated. This limitation was not clear in the documentation.
SQL logging: the config.php documentation now clarifies that the operations executed through hooks or other custom functions are not logged.
Documentation: it has been highlighted that, when you save a report link for future use, if the report has been generated after a search, the search filter is not saved together with the link.
In the in-line help, form configurator, it has been highlighted that, for select_multiple lookup fields, the lookup table primary key field values cannot contain the character set as FORM_CONFIGURATOR_SEPARATOR.
In the configuration file, it has been highlighted that the lenght of the parameter FORM_CONFIGURATOR_SEPARATOR must be 1.
Form configurator, in-line help: it has been highlighted that the cascade feature only works in EDIT and INSERT forms, not in search forms.
A known bug has been added to the documentation: 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.
The update_date_time fields are now automatically excluded from insert forms. Despite the in-line help said they were excluded, DaDaBIK showed them unless explicitly hidden.

Apr 24, 2017
v. 8.0 Lerici

NEW FEATURES AND FEATURE CHANGES

New, responsive, front-end
DaDaBIK has a completely new, responsive, front-end. The front-end provides four graphic themes, three different modalities to handle the results grid layout overflow and two options for the menu: the classic dropdown list and a left side menu. You can choose a value for all these parameters in config.php.
DaDaBIK also provides two display modes for the results grid: 'classi grid' and 'list', the latter displays each field+value couple in a single row and it is useful when you have a lot of columns (to avoid the horizontal scrollbar) or when you are accessing DaDaBIK from mobile.
A complete graph reporting tool
DaDaBIK now provides a complete graph reporting tool, which allows to easily produce Pie charts, Bar charts and line charts based on the application data. Both a simple mode (create a graph in two clicks) and an advanced mode (write your custom SQL query as source of the graph) are provided.
Calculated fields
DaDaBIK now provides calculated form fields, whose value is not directly provided by the user but calculated according to a custom PHP function. For example you might have a total_price field, which is calculated according to the values of other fields, e.g. as price + tax.
Smart installation / configuration guessing
A new smart installation procedure allows to save a lot of time during the DaDaBIK application configuration: DaDaBIK tries to guess the correct parameters for a field according to database field type, database constraints and even field name. For example if you have a referential integrity constraint in your schema, DaDaBIK chooses a select_single field type for the foreign key and set the correct linked fields; if you have a NOT NULL field, DaDaBIK sets the field as required, if your field contains the word "email", DaDaBIK set the field content to "email". All the rules are expressed in a PHP function guess_field_dadabik_settings() that the users can customize.
Hooks
DaDaBIK now provides HOOKS: 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 example you can easily add some code that, when a new order is register to the system (after insert hook on table orders) automatically updates your stock in a table warehouse. Hooks are defined in the file custom_functions.php.
Improved admin section
The admin section has been drastically improved, in particular:
- The tables inclusion page (now called 'pages') has been completeley redeisigned, and allows now to handle all the settings related to DaDaBIK pages: pages based on Tables, on Views or Custom pages. It is also possible to create database VIEWS directly from this page.
- The usability of the form configurator has been improved a lot, for example when you set a lookup table, primary key, linked fields and other fields are now chosen from a list, without the need of typing field names manually. Furthermore, it is now possible to copy form settings from one table to another in one click, if the tables have exactly the same fields.
- Permissions manager: it is now possible to set the permissions to Yes/No for all field/permission type combinations in one click.
- Permissions manager: the copy permissions feature now allows to copy the permissions from one group to another choosing a specific table.
- Permissions manager: once a table is selected, the current permissions are now showed without clicking on the submit button.
- When, from the front-end, you open the admin area, the working table is now the one you were using in the front-end. This helps during the development process, when you often go back and forth between front-end and admin. Furthermore, DaDaBIK now remembers the last page you were working on in the admin area, and takes you back there when you access the admin area again.
Users can now change their own password. You can disable this feature from config.php.
It is now possible to specify in the form configurator, for each field, the min width (in px) of the corresponding column in the results grid.
A draft of the update_records API method is now available in the new api.php file. The idea is to improve in future the API provided, in order to let other applications talk with DaDaBIK.
Each custom page can now be enabled/disabled; this is useful when you create a new custom page and you don't want to show it before finishing the setup or when you temporary want to hide a custom page.
A new custom page type, LINK, allows you to add a custom link (internal to the application or external) to the menu. This is particularly useful when you create a graph report and you want to easy access it later from the menu, in one click.
DaDaBIK now accepts default values also for select_single / select_single_radio field types
For select_single lookup fields, DaDaBIK allows now to show a link, in results grid and details page, that opens a page containing all the data of the linked record.
A new config parameter: grant_permissions_after_table_installation allows you to automatically grant all permissions to all groups (or only to the admin group) when you install a table in DaDaBIK.
It is now possible to set in config.php, for results grid and details page, the max width and/or max height in px the browser must use when displaying uploaded pictures.
DaDaBIK now check and provide alerts for table and field names containing blank spaces or dots during installation and other operations.
DaDaBIK now supports VIEWS also for SQLite
DaDaBIK has a brand new installation page.
It is now posssible to override language translations specifying them in a separate file. This is 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.
Telugu translation is now available.
New and more user friendly dialog boxes for the in-line help of the admin area, based on jQuery dialog
It is now possible to hide the logout link, useful if DaDaBIK is embedded in Wordpress and the Wordpress authentication is enabled.
When you access the edit form or the details page of a record that doesn't exist, DaDaBIK now redirects to the results grid page
insert_date_time and update_date_time fields are not showed anymore in, respectively, insert and update form, regardless of the user's settings
insert_date and update_date field types are now called insert_date_time and update_date_time, since they actually store date and time if the corresponding DB field is datetime
It is now possible to choose a custom separator to display linked field values. The separator can be customized using $separator_display_linked_field in config.php
Improved sicurity for PHP custom pages, now it is not possible to execute a file if the file is outside the directory custom_php_files
The use of an external users table is now better explained in config.php
The CSS file specific for print (styles_print.css) is not token into consideration anymore

FIXED BUGS

Escape/Unescape of values coming from POST GET COOKIES were not handled correctly for PostgreSQL and SQLite when custom pages or cascade fields were used, this could caused unexpected behaviour. Fixed.
Unless the developer wrote some code to check the user authentication, custom PHP pages can be called and executed directly (calling the URL), bypassing the DaDaBIK authentication system. A proper line of code is now provided in /include/custom_php_files/example.php, this line must be added to the top of any PHP custom page created and prevents the page from being called directly.
A table name containing characters which needed to be url-encoded to be passed via querystring (i.e. all non-alphanumeric characters except -_.) could lead to unexpected results if the table was a master in a master-details view and the user clicked on the sort-by links of one of the items tables. Fixed. Remember that table and field names still have restrictions (see the documentation, known bugs).
Emails (insert notices/update notices) sent by DaDaBIK were text emails having HTML formatting, this produced weird content. Fixed, emails now contain just text, as exported CSV files.
Successful logins to the application were always logged into the logs table, regardless of the setting in DaDaBIK Enterprise. The setting parameter was available in DaDaBIK Pro's config.php, even if the feature was not available. Fixed.
The email field content now accepts also long Top-Level domains such as .media or .photography
DaDaBIK didn't show an insert_date field in a edit form, even if the field was set to be displayed. Fixed.
DaDaBIK, when a CSV was produced, added a carriage return at the end of each cell value if the corresponding field had a custom CSV formatting function . Fixed.
Czech language was available but didn't appear in the languages menu. Fixed.
Russian language is now complete.
The upgrade script didn't allow to upgrade from Pro to Enterprise if the DaDaBIK version was the current one. Fixed.
Due to a iOS Safari bug, users could not properly select options from a select multiple field. Fixed.
The size of the password crypter popup was too small for certain browsers (e.g. Safari). Fixed.
The Danish translation is now complete.
The documentation provided in /include/custom_php_files/example.php contained two mistakes: it said to use the prefix _cs_ (the right one was actually _cp_) and that the database field names can't start with _cp_test (the right one was actually _cp_). Fixed.
DaDaBIK could produce a 'Fatal error: Uncaught Error: Call to undefined function ereg()' error wihen used together with PHP 7.x. Fixed.
DaDaBIK now accepts, for phone numbers, also numbers without the + sign at the beginning and numbers containing spaces or hyphens.
DaDaBIK showed a blank choice for date fields search operator menus, removed.
During a record update, checking the 'delete' checkbox doesn't actually phisically delete the file from the filesystem. Fixed.

July 26th, 2016
v. 7.3.3

FIXED BUGS

The vulnerability fixed with DaDaBIK 7.3 was even worst than we described: an authenticated user (or a user of a DaDaBIK application having authentication disabled) could execute arbitrary SQL queries (even INSERT/DELETE/UPDATE) on the DaDaBIK database (or on other databases if the database user used by DaDaBIK had the needed permissions). This vulnerability WAS actually fixed with DaDaBIK 7.3. Another similar vulnerability, however, was found in the last days; this one fixed by the 7.3.3 version; again, the vulnerability allowed an attacker to execute arbitrary queries on the DaDaBIK database or on other databases (if the database user used by DaDaBIK had the needed permissions). In this case, if authentication was enabled, not only the attacker needed to be authenticated to exploit the vulnerability, but also he/she needed to belong to the administrators group.

July 6th, 2016
v. 7.3.2

NEW FEATURES AND FIXED BUGS

Export to CSV, performances improved: the performance gain depends on the number of columns; for a typical table, the CSV build process can be 7x faster than before.
The crypter link showed warnings messages and was not usable. Fixed.
Microsoft Excel was unable to correctly represent utf8 characters if used to open CSV files created by DaDaBIK. Fixed. You can still have problems with old MS Excel versions on Mac OS. In config.php it has been highlighted that the csv_separator parameter needs to be set to ; if you want to directly open the files with MS Excel.
For content edited using old Mac computers (when \r alone was used as line break character), the export to CSV feature removed the line breaks included in a field value. Fixed.
If a date/date_time field contained a NULL value, DaDaBIK produced a PHP error message after an Export to CSV process and the field was not correctly represented in the CSV file. Fixed.
If a custom CSV formatting function was used for a field, DaDaBIK didn't correctly separate the field from the next one; the result was a broken CSV file. Fixed.
During the installation, DaDaBIK didn't accept 'postgresql' as dbms_type, even if it is a correct parameter value. Fixed.

June 7th, 2016
v. 7.3.1

FIXED BUGS

Table install/uninstall in Admin->Table inclusion didn't work in DaDaBIK 7.3. Fixed.
DaDaBIK 7.3 produced a "Warning: date(): It is not safe to rely on the system's timezone settings." message. Fixed.
Known bugs in documentation fixed: not only field names but also table names cannot contain blank spaces or dot; not only Insert/search/update operations fail but also other operations.

May 24th, 2016
v. 7.3

NEW FEATURES AND FIXED BUGS

DaDaBIK suffered from an SQL injection vulnerability which allowed an attacker to see unauthorized data:

1) data coming from tables the user hadn't the read permissions for
2) data coming from disabled (not enabled in DaDaBIK) or not installed tables
3) data coming from records the user didn't own (enabled table having read permissions set to MY for the user)

For 1) and 2) the tables could also be in another Database respect to the one where DaDaBIK was installed.

The vulnerability has been fixed.

1) and 2) should occurs only in a particular situation: when your DaDaBIK installation has at least a table exposing just ONE field to the attacker in the results grid; however at the moment we can't guarantee it so you are STRONGLY encouraged to upgrade in any case. 3) instead can always occur.

It's important to highlight that the attacker, to exploit the vulnerability, needs to be authenticated in your DaDaBIK application (or access a DaDaBIK application having authentication disabled).

It has also been highlighted that, to prevent SQL injection vulnerabilities (even after this fix) 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.

If you used to create links to pre-filtered grid views using custom URLs, please note that this approach won't work anymore after the application of this fix. You can use VIEWS instead.

The fix for this vulnerability is also available as a separate patch here: http://dadabik.org/patch_sql_2016.txt
In some cases, the previous/next buttons did not bring the user to the correct record, considering the order the records had in the results view. Fixed.
If $use_id_group_for_ownership was set to 1, the count of the total number of records in a table was not correct. Fixed.
In some cases, DaDaBIK produced a "Notice: Undefined index" message during update if a file field wad required.
The French language is now complete and some typos have been fixed.
DaDaBIK produced a "Notice: Undefined variable" message in results grid if a table hadn't a primary key set. Fixed
Sometimes the DaDaBIK execution was blocked by the ModSecurity Web application firewall because of the word "table_name" in URLs, producing a "Forbidden" error message. Fixed.
The check about the max length of a field value didn't work correctly for select_multiple_* fields if the user inserted value containing a character which needed to be quoted (e.g. '). Fixed.
Text flow in textbox/textarea was not handled correctly by Internet Explorer 10. Fixed.

NEW FEATURES

The installation process has been improved, providing specific and meaningful error messages if any configuration parameter is missing or wrong. Furthermore, $site_url and $site_path are not required anymore.
When the user tries to access an admin page but the login screen appears because the session is expired, after a successful login DaDaBIK redirect the user to the section she was trying to access and not to a default page.
It is now possible to specify the years range to use in the datepicker
The final user can now change the language on the fly, while using the application.
It is now possible to upgrade from DaDaBIK Pro to DaDaBIK ENTERPRISE just by running the upgrade script, even if the version number is different.

March 16th, 2016
v. 7.2

NEW FEATURES AND FIXED BUGS

In some cases, during an insert/update operation, the upload process didn't work as expected: DaDaBIK linked the record with a file which was not the file actually uploaded, but an older file (result of an older upload) having the same original filename. This problem happened when the temporary file used by DaDaBIK in the upload process (the files having names starting with "dadabik_tmp_file_") wasn't correctly deleted at the end of the operation. One of the cases where this problem could arise is the following: the user fills an insert form, including a file document.pdf to upload; after the form submission a record duplication warning appears, at this point a temporary file dadabik_tmp_file_document.pdf has been created and won't be used for the operation; the next time a user uploads a file named document.pdf, concluding the operation correctly, DaDaBIK will link the record with document.pdf, not the one just uploaded but the old one. Fixed.

If the user tried to delete a record and the operation for some reason failed, the files related to the record were deleted from the file system (if $delete_files_when_delete_record = 1 in config.php); this created an inconsistent situation where the record could have some non-empty file fields but the correspondent files were not available anymore. The same situation could happen with an UPDATE operation, if the user checked one or more "delete file" checkboxes and the UPDATE operation failed. Fixed. Theoretically, this can still happen if the delete query is executed correctly but the final commit fails, however it is very unlikely.

During insertion/update in a form which contained files field, if for some reason a file writing failed, it could happen that the record was inserted/updated (with a reference to the file in the file filed), without having the actual file in the file system. Fixed.

During update in a form which contained files field, if the user checked "delete file" for one or more file fields, if for some reason the file deletion failed, it could happen that the record was updated (file field) without actually removing the file from the file system. Fixed. The same problem could happen with record deletion if $delete_files_when_delete_record was set to 1.

Results grid, performances improved: the more records per page you display, the more you will notice the difference: for example with 100 records per page the amount of time needed to display a results grid has decreased by about 37%.

Cascade dropdown fields didn't work correctly unless the "cascade filter field" had the same name as the "cascade parent field". Fixed.

DaDaBIK produces an error with PHP >= 7. Fixed.

DaDaBIK, because of wrong file permission settings, could have problems showing two images: the ajax loader icon and the file icon. Fixed.

Admin section: the tables in the dropdown menu are now correctly ordered by table name instead of by alias.

A warning message "Undefined variable: dadabik_url" was produced in some cases if an homepage for the application was set. Fixed.

The documentation related to the upgrade procedure is now clearer.

The online help related to cascade fields is now clearer.

The Catalan translation is now complete and improved.

December 14th, 2015
v. 7.1

NEW FEATURES AND FEATURE CHANGES

A new field type, select_single_radio_button, implements radio buttons in DaDaBIK. As the select_single field type, you can fill the options using pre-defined values or values coming from a lookup table. You can also set cascade radio buttons and allow users to add custom values on the fly by clicking onto the "other" option.

Custom formatting functions now take in input, for select_single/select_multiple fields having more than one linked field, each linked field value singularly. This allows you to have more control on the outupt.

An additional button is now displayed in the EDIT form right after SAVE and BACK: SAVE+BACK; in one click you save the content of the form and you come back to the results grid, making repetitive data entry operations faster.

Danish language is now available.

FIXED BUGS AND CHANGES

If you had authentication and granular permissions enabled, the Form Configurator could retrieve the wrong values for the "Forms presence" parameters ("Field present in the search form?", "Field present in the insert form?", ...) and consequently save the wrong values if you didn't realize the mistake. The "Forms presence" parameters are NOT used by DaDaBIK if you have authentication and granular permissions enabled so in most of the case this bug doesn't produce any issue, however it can affect your application if, at some point, you decide to disable authentication or granular permission. Fixed. Now the "Form presence" section is not displayed anymore if authentication and granular permissions are enabled.

DaDaBIK, in the edit form of a master/details page, showed a "Create new item" button for the items table, even if insertion is not enabled for the items table, if the number of records of the items table was zero. It didn't affect security because the permissions model would have blocked anyway the insertion, though. Fixed.

Documentation and help hints said that if you disable the read permission for a table, users can still read its records if the table is used as source of a select_single field; it has been highlighted that the same behaviour occurs with select_multiple.

It has been highlighted in documentation that DaDaBIK doesn't support the BIT MySQL field type

October 5th, 2015
v. 7.0

NEW FEATURES AND FEATURE CHANGES

Engine optimization
The display of results grids is now much faster if you have several select_single or select_multiple fields in your grid, especially if granular permissions are enabled and if your database is big in terms of number of tables and number of fields. Example: for a DaDaBIK application having 18 tables installed, the display of the results grid is about 43% faster than before for a table having four select_single fields in the grid.
Cascade dropdown fields
It is now possible to populate a dropdown menu (select_single) according to what the user selected from another dropdown menu. For example you can have two menu: country and city; when the user selects the country, the system automatically populates the content of the city dropdown with the list of the cities related to the country selected.
Custom required functions
Until now, you could only set a field as "required" or "not required"; it is now possible to specify, for each field, a custom PHP function to use in order to evaluate if the field is required or not; in particular, you can specify the requiredness of a field according to the value of other fields in the form. For example let's say you have a table customers and for each customer you have several fields, including country (a dropdown menu), address, city and state; you want to make the "state" field required only for customers from U.S.A.: using a custom required function you can very easily specify that "state" is required only if the value of country is = "U.S.A.":
```
function dadabik_required_state_customer($parameters_ar)
{
	
	if ($parameters_ar['country_customer'] === 'U.S.A.'){
	
		return true;
	}
	else{
		return false;
	}
}
```
The check is performed through an Ajax call so, in this case, you will see an asterisks near "state" as soon as you select "U.S.A" from the country dropdown menu.
Permissions copy
From the admin area is now possible to copy all the permissions from one group to another in one click (DaDaBIK Enterprise only).
Others
The time needed to save permissions in permissions manager is now much less than before.

DaDaBIK now requires PHP >= 5.2

FIXED BUGS AND CHANGES

A malicious user could see data from a table A without having read permissions by setting in the URL a master_table_name B (where B is a table she has read permissions), even if B and A were not in a master/details relationship. Fixed.

If a table had the check duplication feature enabled for one or more fields and the user decided to "insert anyway" after having seeing possible duplicated records, date and date_time field values were not inserted in the record. Fixed.

DaDaBIK didn't show file fields if authentication or granular permissions were disabled. Fixed.

PDF files were not handled correctly by DaDaBIK. Fixed.

A bug in DaDaBIK Enterprise could lead to unexpected results in term of "record ownership" (not being able to see/edit/delete a record you own or being able to see/edit/delete a record you don't own) if you set the parameter $use_id_group_for_ownership = 1. Fixed. Please note that all enterprise users should have already received this fix in May 2015 and DaDaBIK files released after May 14th were already patched.

If, while editing a record, the user clicked on a file link, she lost the lock on the record. Fixed.

DaDaBIK Enterprise produced the following error: "Fatal error: cannot redeclare ldap_escape()" with PHP >= 5.6. Fixed

For select_single and select_multiple fields having linked fields, DaDaBIK applied wordwrap to the content even if a template was set. Fixed.

For select_single and select_multiple fields having linked fields, the display of generic_file and image_file linked fields didn't work. Fixed.

The content of the email generated if enable_insert_notice_email_sending or enable_update_notice_email_sending were enabled, was not correctly produced:

select_multiple fields were not correctly handled
formatting rules related to linked fields were not correctly handled
if a field of the table had the "Primary key field" set in form configurator but it was not a select_single/select_multiple field, DaDaBIK could produce unexpected results.

Fixed.

For each table, DaDaBIK keeps in session information about the filter applied, the field you are using to sort, the results page you are viewing, the number of records per page you want to see. This allows you to find the same settings when you move from one table to another. These settings, however, were preserved even after a logout. Fixed.

Usernames containing single quotes produced errors. Fixed.

The check duplication feature enabled on a table containing file fields can produce errors. Fixed.

Changing permissions for an empty group (no users inside) produced an error. Fixed.

In results grid and details generic_file fields were displayed with a broken icon. Fixed.

In custom_functions.php it has been highlighted that if you need to use a form field value for custom validation, the correspondent field cannot be disabled in the edit form

DaDaBIK produced an error if authentication was disabled and a results template was enabled. Fixed.

Dec 22, 2014
v. 6.3

Fixed bugs and changes

During an edit operation, if the edit form, after having pressed "save", needs to be re-displayed (e.g. because of a missing required field), a select_single field having an hard-coded list of options (non linked table) could loose the value set by the user and got the value stored in the database in that moment. This could lead to save wrong values if the user didn't re-check the whole form before saving. Fixed.

An update_date field didn't work correctly (date set to NULL after update) if $treat_blank_as_null was set to 1. Fixed.

Since DaDaBIK needed, to handle generic_file and image_file types, to upload the files into a folder which is public accessible, those files were accessible to anyone who knows their URL, even without logging in into the system. This could produce a false sense of security because users might think the files are, by default, password protected. The file management has been completely rewritten and it is now possible to protect the upload folder in order to avoid public acces through the URLs. By default, the /uploads folder now 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.

If a field field1 has the edit permission set to "Yes, but disabled" an the edit form, after having clicked on "Save", needed to be showed again because of errors, the value of field1 is not correctly reported in the form. This bug has been fixed with version 6.2 but if the field was a select_single using a linked table, the fix didn't work. Fixed.

If the results template was enabled, DaDaBIK cut the last 6 characters of field values while displaying the data grid and didn't add a line break between values of a select_multiple_* field. Fixed.

Instructions about "Owner permissions" have been improved, in particular it has been highlighted how it works with VIEWS, which don't inherit form settings from the underlying tables.

It is now possible to set in the config file, for MySQL and PostgreSQL, a port different than the default one.

DaDaBIK produced some "undefined index" errors after a search if a date, date_time, insert_date or update_date field were included in the quick search bar; furthermore, the search value related to such a field is not correctly kept in the quick search bar. Fixed.

The queries executed during permission settings (admin) have been optimized in order to avoid (or make it very rare) a potential execution timeout due to the high number of fields and/or users.

DaDaBIK produced a "Notice: Uninitialized string offset" message in some situations. Fixed.

The bug about nested Master/Details views, highlighted in the "Known bugs" section of the on-line documentation, was not included in the documentation file released with DaDaBIK. Fixed.

DaDaBIK ENTERPRISE produced a "[08] Error: during transaction start" error during insertion/update of a record if you chose "other" for a select_single field. Fixed.

The layout of the quick search bar now looks better when a field has just one search operator.

The documentation in config.php said the boolean search worked just for a “contains” search. It was not correct, it works also with other search operators. Fixed.

DaDaBIK didn't work correctly (although it didn't show any error) if a field name was longer than 50 characters. Fixed, now the length of table name plus field name can be up to 254 characters.

If you were working on a details table A (master/details view) and A doesn't have read permissions, clicking on the homepage link produced an error. Fixed.

If a required select_multiple field was not filled during EDIT, DaDaBIK produced a "undefined index" notice. Fixed.

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. This issue has been added to the known bugs.

DaDaBIK doesn't work correctly with VIEWS, if used in combination with SQLite (MySQL and Postgres work fine). We are working on a solution, the issue has been added to the known bugs.

New features

In order to reduce risk of brute force attacks, a user account is blocked if the user types the wrong password for 10 times (you can change the value from config.php). If a user access a DaDaBIK application through a Wordpress authentication, this limit has no effect. This doesn't prevent bruce force attacks made by trying multiple usernames (not more than 10 times for each).

Permissions settings is now much faster: for each permission type (read, create, delete, ...) you can set "Yes" or "No" for all the fields of a table in one click.

It is now possible to fill ID_user fields with the group of the user instead of the username. The option must be enabled in config.php ($use_id_group_for_ownership). This also affects, for DaDaBIK ENTERPRISE, how the owner permissions work (id_group instead of username will be used to control read, delete, update). A DaDaBIK application must keep the parameter $user_id_group_for_ownership always set to the same value (0 or 1), it is not possible to mix the two different approaches.

insert_date and update_date fields are now insert_date_time and update_date_time fields. If your database field is set as DATE, they register date, if it is set as DATETIME, they register date and time.

DaDaBIK now logs not only the update, delete and insert operations executed but also who (user) has executed them (Enterprise only).

Successful login to the application are now logged into a logs table (Enterprise only). The feature needs to be enabled from config.php (parameter $enable_access_logging).

It is now possible to choose the separator which DaDaBIK uses for displaying several data item related to the same select_multiple_* field. By default it's a line break (as it used to be).

June 24, 2014
v. 6.2

Fixed bugs and changes

If you enabled Wordpress authentication, you logged-in (in Wordpress) with User A and then you logged out (from Wordpress), the user was not correctly logged out from DaDaBIK as well and could still access the DaDaBIK application without logging-in until a specific DaDaBIK logout was executed. This was dangerous in particular if you used a shared computer. Furthermore, if you then logged-in in Wordpress using another User B, DaDaBIK didn't update the user logged and his permissions because it still considered User A as the logged user. Fixed.
Please note that 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.
Please note that if you enable 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
The last two issues have been added to the documentation. (unexpected behaviors).

If a field field1 has the edit permission set to "Yes, but disabled" an the edit form, after having clicked on "Save", needed to be showed again because of errors, the value of field1 is not correctly reported in the form.

Setting the edit permissions of a rich_editor field to "yes but disabled" could lead to unexpected results: the field was not disabled and some of the content which follows the field in the page was added to the field content. Fixed.

DaDaBIK now uses the last versions of TinyMCE and htmLawed: 4.1 and 1.1.17; this can fix security problems and other issues that the old TinyMCE and htmLawed versions used could cause.

A new bug has been highlighted in the documentation, know bugs: If an insert/edit form needs to be re-displayed because an error occurred (e.g. a missing required field), file fields don't preserve the values set by the user before submitting the form

It has been highlighted that custom validation functions ARE NOT applied to select_single and select_multiple_ field types.

June 2, 2014
v. 6.1

New features and feature changes

The Admin section is now password-protected even if you disable authentication.

Improved Form Configurator: Yes/No radio buttons are now used instead of listboxes, which makes configuration faster.

The permissions manager now allows to save with one click the permission settings related to all the fields in a table.

When you insert a new item for a master/details view, in the insert form the listbox related to master table is now disabled (because it doesn't make sense to change it).

A new option ("treat_blank_as_null", config.php) allows to get rid of the current NULL checkboxes and to 1) Treat empty form fields as NULL values during insert and update 2) View NULL values as empty form fields during edit This, according to the feedback we have received, should make the use of a DaDaBIK application much more friendly to non-technical users.

In a master/details view the alias of the items table is now displayed more clearly and highlighted in details mode as well (not just in edit mode)

The "classic" date and date time field is not supported anymore, the date / datetime picker is now the only option available.

Fixed bugs

If a select_single or select_multiple field has a "Primary key table" having Browse authorization enabled (or read permissions = MY) and the field is displayed as a "quick search" filter, all the records of the table were displayed and not only the ones inserted by the current user. Fixed.

DaDaBIK corrupted the graphic layout and could in some conditions displayed wrong values for select_multiple_menu and select_multple_checkbox fields in datagrids, details page and CSV when a select_multiple_menu or select_multple_checkbox field value was empty. Fixed.

When using custom formatting functions, DaDaBIK PRO showed in results page wrong values for fields having custom formatting functions: last four characters were cut off and in case of a select_multiple field having several values, no carriage return was displayed between the values. Fixed.

DaDaBIK produced a query execution error if a select_single or select_multiple field has a "Where clause" parameter set and at the same time the "Primary key table" has read permissions set to "My".

When using template, for select_single or select_multiple fields having linked fields, just the last linked field was showed. Fixed.

Quick searches on select_multiple_* fields didn't work correctly and gave wrong results. Fixed. The documentation now also highlights that just a few search operators are compatible with select_multiple_* fields.

DaDaBIK was supposed to produce an error when a search was performed on a date, date_time, insert_date or update_date field using a search operator not compatible but the error didn't show up and the result could be wrong. Fixed.

DaDaBIK, when a CSV was produced, added a carriage return at the end of each cell value. Fixed.

DaDaBIK produced an "undefined variable" error while showing the results grid if a date, date_time, insert_date or update_date field were included in the quick search bar. Fixed. Furthermore, the date_picker search field were always used even if in the configuration file $field_type_for_date was set as "classic".

After having accessed (in edit or details mode) a record with master/details view (master table A, details table B), DaDaBIK showed only the records related to that master record if the details table B was then accessed in "show items" mode. Fixed. This means, however, that now if you perform a search on B, then access (in edit or details mode) a record of the table A, you will then lose the search filter you had on B. This last issue has been added to the documentation as "unexpected behaviour".

DaDaBIK in some cases produced a warning messages if the parameter $field_type_for_date was set to "classic".

Users were supposed to be able to upgrade from DaDaBIK PRO to ENTERPRISE following these instructions:
- Replace all the old files with the new ones (keep your upload folder if you want to save the uploaded files )
- Update your /include/config.php file using your old configuration settings
This upgrade procedure, however, produced a DaDaBIK installation which didn't allow to create PHP custom pages (available since DaDaBIK 6.0). Fixed. It has also been highlighted in documentation that you can upgrade from PRO to ENTERPRISE only if the version is the same (e.g. from 6.1 PRO to 6.1 ENTERPRISE).

If you executed a "DB Synchro" after having changed the name of a field and the field was a primary key, the information about the primary key was not updated in "Table inclusion". Fixed.

In some cases, for DaDaBIK ENTERPRISE, new users (created via DaDaBIK in addition to the default ones) could not log-in because DaDaBIK thought they were LDAP users (even if they were standard DaDaBIK users). In addition, the authentication type field was showed in the insert/edit form while it should not have been (in all versions). This bug was supposed to be fixed but it was not in case of a fresh DaDaBIK installation, now it is completely fixed.

It hase been highlighted that, regardless of the date_format you choose, in edit mode the date in a date picker is always displayed in year-month-day format

select_multiple field types are now better documented in the admin pages.

Fixed some minor issues in the config file.

March 25, 2014
v. 6.0

New features

It is now possible to create custom pages running completely custom PHP code, with the only limitation of some variabile naming rules. This is an experimental feature and need to be enabled from config.php setting $enable_custom_php_pages = 1.

The field type select_multiple has been re-introduced, it is now possible to store in a field multiple values (also coming from another table) handling the field by using a multiple select or multiple checkboxes.

An improved engine allows to display record results datagrid faster; you can notice a dramatic improvement when handling tables having millions of records: as an example the time needed to change the results page for a simple table having 8 millions records is now reduced by 74%.

Date and date time fields are now edited using a Jquery Datepicker.

It is now possible to use AND/OR boolean operators for a field during a search, simply typing the operator in the textbox (e.g. "apple OR banana"). The feature must be enabled from config.php ($enable_user_booleans) and by default is disabled.

It is now possible to show a field in the edit form as DISABLED (not editable). To disable a field, set its permissions choosing "yes, but readonly" for the edit permissions.

It is now possible, when setting the "where clause" of a select_single (or select_multiple) field, to write the related SQL also using PHP variables, which will be evaluated at runtime. For example you can create a select_single showing a list of cities (coming from the cities table) and add a filter which depends on the ID of the current user.

When $show_top_buttons is enabled in config-php, the "Back" and "Back to the main table" buttons are now showed also at the top of the form.

Fixed bugs

DaDaBIK could have problems in handling tables with millions of records, causing the crash of the Web server if the memory was not enough. Fixed. The problem can still arise when using the "previous" or "next" record buttons because DaDaBIK needs to sort the whole table to find previous/next records; for this reason it is now possible to disable the previous/next buttons from config.php.

After an "uninstall table" operation, DaDaBIK deleted the general (granular) permissions related to the table but not the permissions related to each table field; if the table (or a table having the same name) was installed again later, that table got the field permissions that were set for the old one, instead of having all the field permissions set to "NO". Fixed.

The custom formatting functions were not applied individually to linked fields (select_single field type): this bug was supposed to be fixed in version 5.1.2 but it wasn't for DaDaBIK Enterprise. Fixed.

The content type formatting rules were not applied individually to linked fields (select_single field type) for CSV exporting. Fixed.

When adding a new static page, DaDaBIK sometime wrongly detected as possibly duplicated the static page. Fixed.

The upgrade procedure didn't work correctly when a DaDaBIK 5.0 installation needed to be upgraded and the users table name was not the default one (dadabik_users). Fixed.

DaDaBIK produced an error or show empty values in details page if a field had the parameter "Primary key field" set. Fixed.

DaDaBIK could have unexpected results (errors, insertion in the database of the escape character "\" as data, ...) with PostgreSQL and SQLite if magic_quotes_gpc was set to On and magic_quotes_sybase was NOT set to On. Fixed.

In the search form, selecting "is not null" or "is not empty" did not disable the correspondant textbox. Fixed.

In some cases, the previous/next buttons did not bring the user to the correct record, considering the order the records had in the results view. Fixed.

All the operations performed by DaDaBIK on the database are now transactional, which means that it is not possible anymore to end up in an inconsistent state. (E.g. if an operation requires two INSERT statement and the second for some reason does not succeed, the first is also canceled). Please note that on MySQL this requires to set the INNODB engine for all the tables in your database. DaDaBIK can still work with engines different from INNODB as before, but of course the operations will not be transactional.

In the details page, DaDaBIK didn't correctly display the value of a select_single field having value coming from an external table and produced a warning message. Fixed.

DaDaBIK produced an error after a search operation if one of the values inserted in the search form contained the following string ' FROM '. Fixed.

German language is now complete, thanks to Markus Lischer which provided the missing translations.

If, after submitting an edit form, the form itself needed to be showed again (because of one or more errors), files fields seemed to loose their saved values (the values were not lost but were not showed in the form). Fixed.

Other changes

A new known bug has been included in documentation, explaining that upload and deletion of files are not considered as atomic transactions together with insertion/deletion of records.

DaDaBIK had problems with the upgrade of 4.x releases to 5.x; the upgrade procedure now supports the upgrade starting from version 5.0; versions 4.x, at least at the moment, are not supported anymore.

July 23, 2013
v. 5.1.2

New features

The users page (admin area) has now a direct link to the users page (front-end).

Fixed bugs

If a web applications/site X, installed in the same domain as a DaDaBIK application Y, used a session variable name that also the dadabik application used, unexpected and risky effects could happen if the application X or another page set a PHPSESSID cookie valid also in the DaDaBIK application path (e.g. valid in the whole domain '/'). For example, if X (which could also be another DaDaBIK application) used the same session variable name to set the current "where clause" for a search, changing the "where clause" in one application could affect the "where clause" in the other. Now a new parameter (dadabik_session_name) is available in config.php in order to avoid this kind of problems.

In some cases, for DaDaBIK ENTERPRISE, new users (created via DaDaBIK in addition to the default ones) could not log-in because DaDaBIK thought they were LDAP users (even if they were standard DaDaBIK users). In addition, the authentication type field was showed in the insert/edit form while it should not have been (in all versions). Fixed.

If a field had the "Primary key field" set in form configurator but it was not a select_single field, DaDaBIK could produce unexpected results. Fixed.

During insert if, for a select_single field without a linked table, a new element was added to the list ("other...") and the value of this element needed escaping (e.g. contained a '), even if the element was already available in the list it was added (resulting in a duplicated item). Fixed.

The custom formatting functions were not applied individually to linked fields (select_single field type). Fixed (not fixed for CSV export, see later).

DaDaBIK did not work correctly and could produce error messages in the following cases:

Insert or Search in a form having a select_single field whose linked table had read permissions set to MY
Edit of a record having a select_single field whose linked table had read permissions set to MY and having the selct_single field name different respect to the "Primary key field" parameter of the linked table

DaDaBIK could produce a "[08] Error: during query execution." message with some DBMS configurations when trying to install a table. Fixed.

Page separators did not appear in the details page even if the parameter "Separator before this field (details page)" was set in form configurator. Fixed.

In form configurator, the use of separator for options, linked fields and master/details (~ by default) whose length was more than 1 could lead to unexpected behaviours; now it is not possible anymore to save a separator having a length more than one. The bug has anyway been included in the known bugs for DaDaBIK applications which are already installed.

DaDaBIK Enterprise didn't check if the dbms_type parameter was set in config. Fixed.

Hungarian translation is now complete.

The documentation has been slightly improved.

The content of site_path parameter in config.php has been better clarified.

Instructions about table inclusions have been improved, in particular it has been highlighted that if you want to delete a table from your DB you should first uninstall it in DaDaBIK and then drop it in your DB.

New known bugs

A new known bug has been added to the documentation: the content type formatting rules were not applied individually to linked fields (select_single field type) for CSV exporting. It will be fixed with DaDaBIK 6 because it requires core changes that we are going to apply anyway in DaDaBIK 6.

March 20, 2013
v. 5.1.1

Fixed bugs

If two DaDaBIK applications were installed under the same domain (e.g. http://mysite.com/dadabik_one/ and http://mysite.com/dadabik_two/) and another page X set a PHPSESSID cookie valid in the whole domain (i.e. having path / ), a user who visited X and login into one of the DaDaBIK application could access the other DaDaBIK application without logging in. X could be for example a normal php page having a session_start() statement.

While this bug is related to a know bug, already documented:
"Malicious users could use PHP scripts for setting session variables to particular values in order to bypass the login procedure and get unauthorized access to DaDaBIK. These scripts must be hosted on the same domain where the DaDaBIK target installation is hosted." the fact that can occur even without the presence of a malicious script made it even worst.

A new parameters ($secret_key) is now available and required in config.php; its value, which must be secret and different for each DaDaBIK application you create, fixes this known bug, including the case explained above.

The Wordpress plugin has also been upgraded and requires to set a $secret_key variable as well (see installation instructions for details).

January 23, 2013
v. 5.1

New features

A DaDaBIK application can now be integrated into a Wordpress site through a dedicated wrapper plug-in. Users authenticated through Wordpress can also be automatically authenticated into DaDaBIK too, without doing the log-in again . (Pro and Enterprise version only)

DaDaBIK now supports LDAP authentication (both Open LDAP and Microsoft Active Directory). LDAP users are also imported in DaDaBIK to allow permissions setting. (Enterprise version only)

Czech language is now available.

Changes

A user could delete a record (using an appropriate URL) if he had delete permissions, even if the read permissions were set to MY (owner permissions) and he wasn't the owner of the record. Now, in the same situation, he needed read permissions too for deleting. (Enterprise version only)

Fixed bugs

After having accessed (in edit/details mode) a record with master/details view, DaDaBIK will show only the records related to that master record if the details table is accessed in "show items" mode. A "remove search filter" is needed to remove the incorrect filter. This was and still is a DaDaBIK known bug; however, version 5 did not show the "remove search filter" link. Fixed. (Pro and Enterprise versions only)

In some cases the parameter "Field present in the search form?" did not appear in the forms configurator. Fixed.

Tooltip content didn't automatically wrap inside the tooltip. Fixed.

When the edit permissions were set to MY (owner permissions) a user which did not own a record couldn't modify it but it could enter into the edit screen (if he had read permissions). Fixed, now he can't enter the edit form anymore. (Enterprise version only)

After log-in, if the username was correct and the password wasn't, a PHP warning message were displayed.

DaDaBIK duplicated the last field of each table in datagrids and forms (BASIC version) or duplicated the search permission entry of the last field of each table for the default group (PRO and ENTERPRISE versions). Fixed.

The configuration file stated that the groups table was used just if $enable_granular_permissions = 1, which was not correct. Fixed, sentence deleted. (ENTERPRISE version only)

DaDaBIK produced, in some specific cases, one or more "Notice: Undefined index: in" notice messages. Fixed.

DaDaBIK produced warning messages and a "[04] Error: it is impossible to run DaDaBIK, probably because you have decided to disable all the tables or the current user doesn't have any permissions set; go to the administration interface and include some tables / set some permissions." message if the logged user changed his own username. Fixed: while the [04] Error is still displayed, because the current user doesn't have permissions anymore, the PHP warning messages are not displayed anymore.

DaDaBIK could produce a "[08] Error: during query execution" when duplication checking was enabled on table_1, table_1 had a select_single field which linked table_2 and table_2 had a field whose name is equals to table_1's primary key. Fixed.

If a date or date_time dadabik field was hidden from the insert/edit form, during insertion/update DaDaBIK produced some PHP notice messages and the error "You have inserted one or more not valid dates.". Fixed.

With some DBMS configuration, DaDaBIK produced a "[08] Error: during query execution" during installation. Fixed.

In case of error or warning after an insert or update, when the form was re-displayed, a date_time field lost the value for the seconds listbox and DaDaBIK produced a notice PHP message. Fixed.

DaDaBIK didn't show an "Item correctly deleted." message after the deletion of an item in a master/details view. Fixed.

The known bug about master/details view was not explained correctly in the documentation, it affects also accessing a record in details mode, not just edit mode. Documentation fixed.

The documentation "known bugs" section didn't highlight that the "check for duplicate" feature doesn't work not only with file field types but also doesn't work (and produce PHP notice messages) with date, date_time, update_date, insert_date field types and all the fields which are hidden from the insert form. Documentation fixed.

The documentation did not explain how to upgrade from BASIC to PRO/ENTERPRISE or from PRO to ENTERPRISE and in particular did not highlight that it is not possible to move from DaDaBIK BASIC to DaDaBIK PRO/ENTERPRISE keeping the application settings (DaDaBIK must be installed from scratch). Documentation Fixed.

After a DB Synchro -> add fields operation, DaDaBIK lost, for that table, all the form configurator values related to:
- Tooltips
- Separators (form dividers)
- Custom validation function
- Custom formatting function
- Custom CSV formatting function
- Where clause
- New line after this field (edit form)?
Fixed.

The configuration file, in the user and group tables section, stated that "You should leave the following 12 parameters as they are...", the parameters were 9 instead. Configuration file fixed.

November 24, 2012
v. 5.0

New features

New graphical interface

A completely new permissions manager which allows to set, for each users group, which operations (read, delete, update, create and details) are allowed on each form and field ($enable_granular_permissions in config.php).

PHP hooks: for each form-field it is now possible to write a completely custom PHP validation function (used to validate data during insertion/update) and a completeley custom PHP formatting function (used to format data for datagrid and edit views)

HTML templates for data grids: the sytle of a data grid can be customizable using an HTML template, for example it is now possible to get a google-style results view instead of the classical tabular results data grid very easily just by working on the template.

Filter feature: a quick, customizable, search form a the top of the results data grid.

Static pages: the possibility to add static, custom, pages to the DaDaBIK application (e.g. an help page).

Form design customization: the possibility to choose if a form field has to be positioned close to the previous one in the same form row or in a new one (default behaviour).

It is now possible to insert titled separators between sets of fields in a form.

It is now possible to specify for a field, as a default value, a value coming from a custom SQL query.

DaDaBIK can now, optionally, show a details page of the record just inserted after an insert operation (option show_details_after_insert in config).

DaDaBIK has a new field type: date_time.

It is now possible, for select_single field having data retrieved from another table, to specify a where clause to use while retreiving the data.

In a master/details view, the details table is correctly showed below the corresponding master table record not only when the edit function is used, but also when the details function is used.

The admin section has now an "about/check upgrade" page which shows information about the DaDaBIK installation and check the availability of upgrades.

It is now possible to specify the default value even for a field not present in the insert form

It is now possible to separately choose if a field should be displayed in the insert form or in the edit form.

It is now possible to specify help tooltips for text, textarea and file fields.

DaDaBIK provides now a log feature: INSERT, UPDATE and DELETE operations are optionally logged in a logs table. This can help a data recovery procedure in case of data loss.

If database views (instad of tables) were installed in a DaDaBIK application, DaDaBIK allowed to see the data just in datagrid mode and not in edit/details mode. Now it is possible to use the edit/details too; for views you need to specify the primary key of the table in the admin section.

Tinymce version updated to 3.5.7. This can solve bugs and security issues (if any) caused by the version previously provided.

DaDaBIK's footprint drastically reduced: from 400+ files to 100+ files, total size reduced by about 40%.

Three additional search options are now available: "is different", "is not null" and "is not empty".

The parameter enable_delete_authorization_table, enable_update_authorization_table and enable_browse_authorization_table are not global anymore but can be chosen separately for each table.

It is now possible to have a custom homepage for a DaDaBIK application.

Changes

The $ask_confirmation_delete and $edit_target_window parameters now works just with the standard data grid, not with template data grids.

The content type is not taken anymore into consideration for "rich_editor" fields.

For a select_single field, the hard-coded options are not considered anymore if there are also options driven from a table.

For select_single fields, the validation in accordance to content_type is not performed any more.

The field type "password" is not supported anymore, you should convert your "password" fields (if any) to the type "text" before upgrading to DaDaBIK 5

The autosumbit_change_table_control setting in not available any more.

Fixed bugs

If browse authorization was enabled, users could see just the records they inserted; however, through a select_single which takes the items from another table, all the records were always all visible. Fixed.

The documentation did not mention that, with the "Other choices allowed?" option set to Yes for a select_single field, the "other" value is used to insert a new record in the relative primary key table EVEN IF INSERT OPERATIONS ARE NOT ALLOWED IN THE PRIMARY KEY TABLE. The relative help tooltip now mentions this behavior.

When a user, during an insert or update, chose the "other" option for a select_single field, for the new record inserted in the linked table the id_user-type field (if any) was not filled with the username of the user, so DaDaBIK didn't give the user the ownership of the record. Fixed.

Upgrading from versions before 4.5 pl1 produced an error, bringing to an installation which was just partially upgraded to the last version and leaving some bugs unfixed. Fixed.

Because of some uncaught exceptions in the DaDaBIK PDO abstraction layer, there were some database operations that showed, in case of errors, a PDO back trace which could theoretically reveal some sensible information. Fixed. Please note that, using the official DaDaBIK release code, we are not aware of errors on that operations, but still there is the theoretical possibility of producing errors.

Setting a custom users table / custom users table fields didn't work as expected and could lead to unexpected results. Fixed.

In the Italian translation a sentence had corrupted characters. Fixed.

DaDaBIK showed a (wrong) search results even if the search operators choosen were not compatible with the fields, for example using a contains operator with a date field or a greater_than operator with a select_single field. Fixed, now you can see the list of incompatibilities in the documentation and the user gets an unhandled error message in case an incompatible operator is used.

For a select_single field, mixing hard-coded options and options driven from a table could give unexpected results. Fixed. Now the hard-coded options are not considered if the options are driven from a table.

The parameter $dadabik_main_file was not used in two links, where the file name index.php was hard-coded.

Table $table_list_name, which was supposed to follow other tables rules about naming (just the prefix must be changeable from config.php) , was still entirely changable. Fixed, it is now highlighted that the name must be kept as it is.

Setting $autosumbit_change_table_control = 0 produced a "Notice: Undefined variable: submit_buttons_ar" message. The $autosumbit_change_table_control is not available any more.

DaDaBIK produced a PHP notice message if a image_file or generic_file field was SET as NULL during insert or update. Fixed.

The "literal_english" date format displayed the date in a "day month year" format instead of "month day, year". Fixed.

On some combinations of PHP version/Operating System DaDaBIK could produce an error during the MySQL connection. Fixed.

While it was explained in the "Known bugs, limitations and unexpected behaviors" documentation section, the upgrade script did not explicit said that the upgrade does not work correctly with SQLite; a DaDaBIK upgrade using SQLite could bring to unexpected behavior. Now the upgrade script prevent the use with SQLite.

November 3, 2012
v. 4.6

Fixed bugs and other changes

The documentation section about multiple instances of DaDaBIK has been (at least for the moment) removed. That section was not up-to-date and referred to a version of DaDaBIK which still didn't have the authentication feature: the result is that if users followed those instructions having authentication ON, a user authenticated on the first (not admin) instance could also access the /admin instance without authentication. This is not a proper bug but could lead to a false sense of security.

Most of the language translations got corrupted after the 4.6 beta utf-8 move. Fixed.

DaDaBIK could silently truncate some of the parameters values in interface configurator if the lenght of the parameter value length was greater than a threshold which depended on the parameter itself. Fixed.

The null checkbox didn't work as expected (enabling/disabling input fields) because of a javascript error. Fixed.

Prefix and defaut values didn't work correclty if they contained a double quote character. Fixed.

The amount of time before a record is automatically unlocked is now 4 minutes (it was 2).

Authentication is now enabled by default.

The Russian language was not specified in the languages list to choose from (config.php). Fixed.

A re-installation of DaDaBIK on the same database didn't clean-up the table containing the information about the installation itself. Fixed. This bug shouldn't have had any effect on the user side, though.

The importance of the parameter $site_path for security reasons has been highlighted in config.php.

The authentication section of the Documentation was not clear. Improved.

Due to SQLite limitations, the script for upgrading DaDaBIK to a new release is not anymore available for SQLite.

The following fix was implemented in 4.6 beta but the quotes in the sentences appeared corrupted in the change log, so re-post: Table or field names having the string "from" in the name could lead to query execution error with SQLite. Fixed.

The following fix was implemented in 4.6 beta but didn't appear in the change log, so re-post: The installation of views diddn't work with MySQL and PostgreSQL. Fixed.

September 27, 2012
v. 4.6 beta

New feature/fixed bug

DaDaBIK now officially supports UTF-8, allowing the correct handling of content in almost any known language and writing system. While some hacks for adding UTF-8 support have been posted on the forum during the last years, this feature has never been officially introduced because of the drawbacks involved: PHP doesn't offer a complete support for multibyte encoding and using DaDaBIK with UTF-8 content could lead to unexpected and bad results such as content corruption. The new version of DaDaBIK has been completely revised in order to work well with UTF-8 content; there are still some cases in which the correct handling of UTF-8 is not guaranteed, see Documentation-> Known bugs, limitations and unexpected behaviors for further details.

Fixed bugs and other changes

DaDaBIK does not use the ADOdb library anymore for MySQL and PostgreSQL. It just uses the PHP PDO extension, as already did for SQLite.

The new requirements are: PHP >= 5.1 with the mbstring extension enabled and one of the following: MySQL >= 5.0 or PostgreSQL >= 7.4 or SQLite >= 3. The database default charset must be UTF-8 if you need to handle UTF-8 content.

DaDaBIK now uses the last version of HTMLawed, which fixes several bugs affecting the version in use before, for improved security while using the HTML content type or the rich editor field type.

With SQLite, because of some uncaught exceptions, there were some queries that showed, in case of errors, a PDO back trace which revealed some information e.g. the path of the PHP file or the query itself. Fixed. Please note that, due to the nature of the queries involved, it should have been difficult, for a malicious user, to intentionally cause the queries to fail in order to display those information.

While the documentation said that quote characters can lead to problems if used in table and field names, also all the characters which need to be escaped such as ' ` " \ can lead to the same problems, documentation updated.

DaDaBIK didn't create interfaces on views if used with SQLite. Fixed.

A date, insert_date or update_date field having just one search operator prevented the display of a "blank option" in the search operators listbox. This means that it wasn't possible to perform a search without considering such a field, if it was in a form. Fixed.

Table or field names having the string "from" in the name could lead to query execution error with SQLite. Fixed.

Registering a new user having a username or password which contained characters which needed to be escaped (e.g. ') was not possible. Fixed.

The check about the max length of a field value didn't work correctly if the user inserted a value containing a character which needed to be quoted (e.g. '). Fixed.

If a field had a prefix, the check about the field type (e.g. email checking), which was supposed not to be performed if the user just left the field as it was (filled by the prefix) during an insert/upate, was instead performed on the prefix if the prefix contained a character wchich needed to be quoted (e.g. '). Fixed.

If a field had a prefix, the "check for duplicated" and "check requried" feature didn't work correctly if the prefix contained a character wchich needed to be quoted (e.g. '). Fixed.

If a field had a prefix and the user just left the field as it was (filled by the prefix) during an insert/upate, DaDaBIK inserted in the database the prefix instead of a blank value if the prefix contained a character wchich needed to be quoted (e.g. '). Fixed.

The "check for duplicated" feature didn't work correctly if the user filled one of the field to check with a value containing a character which needed to be quoted (e.g. '). Fixed.

The check type (email, url,...) feature could (should be very unlikely) not to work correctly if the user filled the field to check with a value containing a character which needed to be quoted (e.g. '). Fixed.

A select_single field having options set by hand and allowing the choice of additional options added the additional options to the list of the options even if tis was already existent (creating a duplicate) if the option contained a character which needed to be quoted (e.g. '). Fixed.

A master details view didn't show the items record related to the master record and didn't allow to create new items if the primary key field value of the master record contained a character which needed to be quoted (e.g. '). Fixed.

A primary key containing as value a character which needed to be quoted (e.g. ') could lead to unexpected results. Fixed.

If the master/details feature was used, a primary key field name of the master table or its value containing a character which needed to be url-encoded to be passed via querystring (i.e. all non-alphanumeric characters except -_.) could lead to unexpected results. Fixed. Remember that table and field names still have restrictions (see the documentation, known bugs).

A table name containing a character which needed to be url-encoded to be passed via querystring (i.e. all non-alphanumeric characters except -_.) could lead to unexpected results. Fixed. Remember that table and field names still have restrictions (see the documentation, known bugs).

The table menu in the front-end is now always ordered by the table alias.

Some outdated parts of the documentation has been removed.

The setting $enable_word_wrap_cut is no longer available.

August 15, 2012
v. 4.5 patch level 1 (pl1)

Changes

DaDaBIK used to store users' passwords using the encryption provided by md5(). While this approach allows for a first level of security, because passwords are not stored in clear text into the database, it does not prevent some type of attacks which a malicious user can do after having obtained the encrypted passwords, such as attacks based on pre-hashed lists or rainbow tables.

For this reason, DaDaBIK, as other popular Web applications such as WordPress did, moves to phpass for managing the password storage. phpass is a framework which supports three password hashing methods (CRYPT_BLOWFISH, CRYPT_EXT_DES and an md5-based method) and chooses the best one according to what the current system can provide. All three employ salting, stretching, and variable iteration counts. This change makes the attacks much more difficult to be successfully executed.

Fixed bugs

DaDaBIK didn't work correctly and produced a "[08] Error: during query execution" if, for a select_single field, the user tried to select the "other" option. Fixed.

The default language was set to Estonian instead of English. Fixed.

A "unexpected behaviour" about search and formatting tags, which was supposed to be added to the documentation, wasn't actually addedd. Fixed.

June 25, 2012
v. 4.5

Fixed bugs

In some cases you could get a "Specified key was too long; max key length is 1000 bytes" or similar error during installation. Fixed. Thanks to Alonzo for having reported it. Furthermore, in some cases (probably quite uncommon), where a table name or its unique field name or a unique field record value are longer than expected, the record locking feature could work not correctly. Now DaDaBIK produces an error if the lenght is not supported.

Using the rich_editor field type led to incorrect search results because the HTML editor add fomatting tags by default to the search text. Now a normal textearea is used for search forms to avoid this behavior. Thanks to user Funbird for the report. Please note that, still, the formatting tags inserted in a field through the HTML editor are not filtered so if you search "hey good" and you have "hey good morning" in your DB, of course you won't find it. This has been added to the "unexpected behaviors" section of the documentation.

The "refresh installation" operation lost settings about master/details views: table and linked items. Fixed.

DaDaBIK had a typo in the German translation. Fixed. (Thanks Heinz for the report)

A bug about the default date 1968-01-01 was listed in the "Known bugs" documentation section even if it was already solved. Fixed.

Choosing Estonian as language led to a parse error message. Fixed.

Other changes

During installation, a warning message is now displayed about the risks of enabling the CSV export feature in a public site. A note in the documentation has also been added. Thanks to user dh for having reported it.

A minor bug about record editing when an identifier field value is changed has been added to the known bugs section of the documentation.

May 31, 2012
v. 4.5 beta

New features

DaDaBIK now provides a complete record-locking mechanism. When a user U1 enter a record in edit mode, the record is locked and other users can't modify it. The record is unlocked if the user U1 exit the edit mode or after a certain amount of time (configurable in config.php). The feature still work even if two users log into the system using the same username and even if authentication is disabled.
The new feature allows DaDaBIK to avoid unexpected data overwriting: for example imagine user A and user B opening in edit mode the same record about a product. Both the users modify the price, user A from 50 euros to 60 euros, user B from 50 euros to 70 euros. Imagine that user B clicks on the save button a few seconds after user A. Both the users would think to have correctly modify the price, but user A is wrong, the current price is now 70 euros. Another example: user A modify the price, user B the description; in this case user B overrides the price modifications made by user A, the price is therefore restored to its initial value.

DaDaBIK now uses just one internal table to keep all the information about the form settings. Previous versions used one internal table for each form, which resulted in some cases in an annoying number of items per database.

A unique upgrade script (upgrade.php) is now available to upgrade to the last version from any version >= 4.3 final. DaDaBIK can now recognize the version you have installed and if it's >= 4.3 final, upgrade it to the last version.

Fixed bugs

In case of error during the execution of a query AND $debug_mode set to 1 OR $display_sql set to 1, if the query contained HTML code, the code was interpreted and not filtered. This could lead to SECURITY problem because allowed the execution of arbitrary Javascript code. Fixed.

DaDaBIK now uses the last versions of ADOdb, TinyMCE and htmLawed: 5.15, 3.5.11 and 1.1.10; this can fix SECURITY problems and other issues that the old ADOdb, TinyMCE and htmLawed versions used could cause. The very last version of ADOdb is actually 5.17 but since we experienced problems with PostgreSQL using 5.16 and 5.17 we chose to include version 5.15.

Insertion of a record could work not correctly and produce an error if there was an id_user field type and the username of the user contained characters which needed to be escaped (e.g. '). Fixed.

DaDaBIK could work not correctly and produce errors with PostgreSQL and SQLite in the following cases:
1) the username of the user contained characters which needed to be escaped (e.g. ').
2) during a "refresh installation" procedure
3) insert/update of a record, select_single field type, if the user chose "other" and the previous listbox values or the new one contained characters which needed to be escaped (e.g. ')
4) insert/update of a record, generic_file/image_file field type, if the filename contained characters which needed to be escaped (e.g. ')
Fixed.

The DaDaBIK installation procedure, if there was a pre-existent table called users_tab in the database where DaDaBIK was installed, overwrote that table. This behaviour is now highlighted in the installation page.

With $debug_mode set to 1 and SQLite, the SQL statement was not showed in case of error, as it was supposed to be. Fixed.

DaDaBIK could produce a PHP Strict Standards message during installation. Fixed.

For consistency with other configuration parameters, you cannot anymore change the $table_list_name but only its prefix, furthermore in the configuration file it has been highlighted, for the sake of clarity, that the users table doesn't use the table prefix (dadabik_ by default) as the other ones.

DaDaBIK produced an error and failed the installation procedure on PostgreSQL in case of re-installation over a pre-existing installation. Both the re-installation of a single table and the complete re-installation gave the same results. Fixed.

On SQLite, DaDaBIK creates by default an interface also for the table sqlite_sequence, which is not a table managed by users but a system table. Fixed.

DaDaBIK produced an error if, from the admin interface, a user tried to re-install the users table. Fixed.

Other changes

DaDaBIK is now licensed under the DaDaBIK license.

May 5, 2012
v. 4.4 patch level 1

Fixed bugs

DaDaBIK produced an error, if used with PostgreSQL or SQLite, when a search produced more than one results page and the user clicked on one of the pages. The problem could affect MySQL just in some cases. Fixed.

Due to a non correct un-escape process of escaped characters, insert/update of wrong data in the database were possible. Fixed.

DaDaBIK had the wrong HTML generator tag. Fixed.

Other changes

Postgresql <= 6.4 is no more supported.

April 3, 2012
v. 4.4

New features and feature changes

DaDaBIK can now officially handle and create front-end for views, in addition to front-end for normal tables. This can help in creating more flexible database applications.

It is now possible to avoid the display of the NULL column in the insert/edit form. A parameter $null_checkbox is now available in config.php. Note that, if the record you are editing contains a NULL value for one or more fields, the NULL checkboxes are displayed anyway, even if $null_checkbox is set to 0.

The DaDaBIK end-user interface is now available in Russian.

Oracle and MS SQL Server are not officially supported anymore.

German, Dutch and French translations are now complete.

Fixed bugs

Some special characters were not correctly escaped in some situations, this chould lead to errors and/or insert/update of wrong data in the database.

DaDaBIK, with SQLite, didn't produce error messages if an SQL query failed. For example, an insert query which violated a constrain, was reported as "Record correctly inserted." even if the record was not inserted. Fixed.

DaDaBIK produced a "Fatal error: Cannot re-assign auto-global variable _POST" if used together with PHP 4.4. Fixed.

DaDaBIK produced an error during installation with PostgreSQL >= 9.1. Fixed.

If all the fields of an edit form were required but one or more fields were NULL in the database, the corresponding NULL checkbox were displayed but the column label "NULL" were not. Fixed, the column label is now displayed.

A bug prevented to work correctly with date type field and SQLite. Fixed. Thanks to Triton for having reported it (http://www.dadabik.org/forum/read.php?1,14771).

If, for a date field, the value of the month was set to other than [1-12] OR the value of the day was set to other than [1-31] OR the value of the year was set to other than [$start_year-$end_year] DaDaBIK will displayed in the edit view, for the relative field, the first default value available in the listbox. For example if a date field was set 1940-00-00 in the database, DaDaBIK will display, in its default configuration, 1968-01-01 and updated the date to 1968-01-01 if the record is saved. Fixed. Now DaDaBIK produce an error message if a date value is not representable with the day-month-year listboxes.

If, for a select_single field, the user selected "other" and didn't specify a custom value during insert/update, the value "......" was inserted. Fixed, now a "required field" error message is displayed.

If, after a insert/update operation, the form was displayed again to the user because of an error (e.g. a required field was not filled) and the value of a date field was set to NULL, some undefined variable messages were displayed. Fixed.

If, for a select_single field, the user selected "other" and specify a custom value during insert, that new value was not included as additional option. Fixed.

Other changes

A new section, "Unexpected behaviors" has been added to the documentation. It's a list of behaviors which the average user doesn't expect from DaDaBIK but that probably can't be considered real bugs. An important point discussed here is about 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.

The "Known bugs and limitations" section of the documentation has been updated, highlighting two bugs, one related to search operations and the other related to some characters which, for some languages, are incorrectly displayed.

February 14, 2012
v. 4.4 beta

Fixed bugs

The authentication didn't work correctly and prevent users to log-in if the DBMS chosen was SQLite. FIXED.

The date field type didn't work properly during insert/update/search and produced a "Notice: Undefined property" message. FIXED.

Master/details view didn't work correctly with SQLite and produced a "Call to undefined method PDOStatement::MoveFirst()" message. FIXED.

When a new item was inserted in a master-details view, the default "parent" item wasn't selected if the field name of the parent table and the (fk) field name of the items table were different. FIXED.

Other changes

The "Known bugs and limitations" section of the documentation has been updated, highlighting a new date-field related bug; the lack of a locking mechanism during records editing has also been highlighted in the documentation, since the current behaviour could lead to unexpected results and data loss.

February 2, 2011
v. 4.4 alpha

New features and feature changes

DaDaBIK now supports SQLite

A new content type "timestamp" is available. The corresponding field must contain an integer, which is displayed as a date and time according to the format chosen with the paramenter $date_format.

magic_quotes_sybase = on in php.ini is no longer required for Oracle and MS SQL Server

The documentation is now more clear about the master/details view.

A new parameter, $timezone, allows to set the timezone.

The sql logging feature is not available anymore.

Fixed bugs

The authentication didn't work if DaDaBIK was installed in the root of a Website (e.g. www.mysite.com and not www.mysite.com/dadabik).

DaDaBIK produced an error about date_default_timezone_set if the PHP version was < 5.1.

December 8, 2010
v. 4.3 final

Fixed bugs and feature changes

The TinyMCE version used to implement the rich_editor is now the 3.3.9.2 . This can fix security problems and other issues that the old TinyMCE version used could cause.

Some MAC OS not needed files were included in the DaDaBIK release. Fixed (thanks Tobias S. for pointing out).

On Windows Vista (and maybe on other Operating Systems), some warnings about encoding were displayed by the system during the extraction of the zip release file. Fixed (thanks Tobias S. for pointing out).

DaDaBIK showed a "delete all" link for an items table even if the delete operation was disabled for that table. The "delete all" operation, however, wasn't executed. Fixed.

After a "delete all" operation performed on a master/details view, DaDaBIK showed the results view of the details table instead of coming back to the master/details view. Fixed.

DaDaBIK now shows a table alias near to the "insert item" link.

Minor change to the English interface

A small banner is now showed in the homepage of the admin interface.

The changelog didn't contain the changes for DaDaBIK 4.3 beta. Fixed.

November 28, 2010
v. 4.3 beta RC2 (release candidate 2)

New features, fixed bugs and feature changes

DaDaBIK, with some PHP versions and error reporting settings, produced some "Deprecated" and "Strict Standard" warnings. This was due to the ADOdb version used, which was too old. DaDaBIK now uses the last ADOdb version for PHP5 and automatically load the last PHP4 compatible ADOdb library if you are still using PHP4. This can also fix security problems and other issues that the old ADOdb version used could cause.

The single-donation button of the admin section didn't work.

A lot of not strictly-needed files has been removed from the official release, which is now lighter.

It is now possible to to send feedback on DaDaBIK to hotscripts.com directly from the admin section.

The documentation didn't explain how to upgrade to 4.3 rc1. Fixed.

November 23, 2010
v. 4.3 beta RC1 (release candidate 1)

New features and feature changes

DaDaBIK has a new administration section: new look, some improvements in the interface, in-line help for the interface configurator, possibility to send feedback, to donate and to buy email/phone commercial support. The configuration file has been improved in clarity too.

It is now possible to choose if a table can appear in the table list menu.

The "home" button, which had been deleted, is now available again.

If a table is an "items table" in a master-details view, the insert/search/show all/last search results top buttons are not anymore displayed,

The documentation has been completely revised, clarifying some aspects when needed and highlighting some new known bugs/limitations.

Minor GUI enanchements.

Fixed bugs

DaDaBIK 4.3 beta3 in a case-sensitive environment didn't include the htmLawed library because of a mistake in the case of a letter. This leave DaDaBIK exposed to the security risk that version 4.3 beta3 was supposed to fix (see 4.3 beta 3 changelog's entry for details). A "Warning: include(./include/htmlawed/htmlawed.php) : failed to open stream" warning messase could also be produced. Thanks to Kaiya for pointing this out.

With PHP < 4.1.0 and DaDaBIK 4.3 beta, beta2 or beta3 there could be problems with the escaping procedure, this could lead to various problems (even security problems).

The URL validation didn't work as expected.

The enable/disable features control didn't work as expected.

If the first table present in the table list menu was empty (no records), DaDaBIK didn't show the table list menu.

When $enable_browse_authorization was enabled, using the previous-next links DaDaBIK tried to show also non-authorized records; the records details weren't showed but a message "You don't have the authorization to view this record." was displayed.

DaDaBIK, if a table was used as "items" table, didn't correctly take into consideration the permissions (insert, edit, details, delete) set in order to display the corresponding controls.

When a record is deleted, now also the files linked to the record are deleted. Is it possible to control this behaviour changing the new config parameters delete_files_when_delete_record.

November 15, 2010
v. 4.3 beta3

Fixed bugs and changes

If a DaDaBIK application was configured to use at least one html content type field or one rich_editor field type field, a malicious user who had access to the application could insert in the field some arbitrary javascript code, which was then executed by other users just by using the application. Among other problems, this could lead to XSS attack (http://en.wikipedia.org/wiki/Cross-site_scripting), which in turn could allow an unauthorized access to the application (http://en.wikipedia.org/wiki/Session_hijacking) and, if the Internet browser of the user contained security holes, even the execution of arbitrary code in the client machine. The problem is now fixed applying a filter provided by the htmLawed library (http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed) when the output is displayed. You must however keep in mind that, as the documentation states (http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawed_README.htm#s2.8), there are some minor cases in which htmLawed can fail.

Since htmLawed requires at least PHP version 4.3, even the PHP minimum version requirements of DaDaBIK have changed from 4.05 to 4.3.

November 11, 2010
v. 4.3 beta2

Fixed bugs

If in a DaDaBIK application the insert or edit feature was enabled (at least for one table) and a select_single field type was used (at least once, even in another table), a malicious user who had access to the application could in many cases insert in a listbox some arbitrary javascript code, which was then executed by other users just by using the application. Among other problems, this could lead to XSS attack (http://en.wikipedia.org/wiki/Cross-site_scripting), which in turn could allow an unauthorized access to the application (http://en.wikipedia.org/wiki/Session_hijacking) and, if the Internet browser of the user contained security holes, even the execution of arbitrary code in the client machine. This problem have been fixed in version 4.3 beta2.
The problems described above can occur even when the insert or edit feature was enabled (at least for one table) and the HTML content type is used; at the moment there isn't a patch for this second scenario, the HTML content type should be used carefully, as highlighted in the upgraded documentation.

DaDaBIK didn't show the default edit, delete and delete icons.

October 21, 2010
v. 4.3 beta

New features and feature changes

DaDaBIK has now a new and better Graphic User Interface.

Having magic_quotes_gpc set to On is not anymore needed.

The documentation, in particular the "Known bugs and limitations" sections, has been updated.

Fixed bugs

DaDaBIK showed a notice error message when the previous/next button was used after an error on update (e.g. a missing field); now the buttons are not anymore displayed.

DaDaBIK produced a "Undefined variable" notice when showing results and nor records were found.

DaDaBIK could display a deprecated warning related to eregi if used together with PHP >= 5.3

The upgrade file upgrade_4.3.php was not adodb-compatible and therefore probably didn't work with all the DBMS supported.

September 14, 2010
v. 4.3 alpha

New features and feature changes

DaDaBIK now supports a master/details view: for example if you have an albums table and a songs table you can set DaDaBIK to display in the same page the details of an album and the result list of the songs linked to.

The documentation, in particular the "Security" and "Multiple function views" sections, have been updated.

Fixed bugs

DaDaBIK didn't correctly execute a search based on a field if, for that field, you choosed from the interface configurator just one search operator.

DaDaBIK showed a javascript error message when a results view was displayed.

February 18, 2007
v. 4.2

Fixed bugs

The Rumanian language is now complete.

February 8, 2007
v. 4.2 beta

Fixed bugs

Previous and next buttons didn't work correctly after an update operation which caused an error (for example for a missed required field value) and now are not displayed any more in the above case.

New features and feature changes

DaDaBIK now handles the NULL values, it is now possible to insert a NULL value in a field and to search for NULL values.

New search operator available: is empty.

The required fields are now displayed using a * sign, instead of using a different color.

The documentation, in particular the "Known bugs and limitations" section, has been updated.

January 18, 2007
v. 4.1 final release

Fixed bugs

After a login or a "Show all" operation the order type stored for the current table was not cleaned, as expected.

In some particular cases, the previous and next record links didn't work and DaDaBIK produced a "Notice: Undefined index:..." message.

For a linked field, DaDaBIK didn't use its own type and content in order to correctly display it in the results and details view.

January 14, 2007
v. 4.1 release candidate 3

Fixed bugs

DaDaBIK version 4.1 rc2 produced a "[08] Error: during query execution." error message during the installation.

January 14, 2007
v. 4.1 release candidate 2

Fixed bugs

The "refresh installation" admin operation didn't work correctly and could lead to an interface configurator settings loss. Please note that this bug can appear even on a DaDaBIK version >= 4.1 rc2 if the installation is the result of an upgrade from a version < 4.1 rc2; the 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.

DaDaBIK in some cases produced an "[08] Error: during query execution." error message if the user clicked on the previous or next record links.

DaDaBIK lost the "Field present in the details page?" option setting after a "Refresh installation" procedure.

Rumanian language is now complete.

Some CSS style settings were repeated twice in css/styles_screen.css, in some cases using different values.

The documentation has been revisited, in particular the upgrade process is now clearer and a new known bug has been added to the documentation.

If one or more tables name were particularly long DaDaBIK could produce a "[08] Error: during query execution." error message on Oracle during the DaDaBIK installation or during a single table installation.

The default upper limit for the year part of a date is now 2010.

styles_print.css code clean-up.

New features and feature changes

The pdf file extension is now allowed by default for file upload.

November 13, 2006
v. 4.1 release candidate 1

Fixed bugs

If a table was empty and the user selected it, the tables listbox disappeared so it was impossible to choose another table.

The upgrade script upgrade_4.1.php had the name of one of the DaDaBIK tables hard-coded; this could lead to problems during the upgrade process if the $table_list_name (confgi.php) variable value was not "dadabik_table_list".

The upgrade script upgrade_4.1.php didn't work correctly on Oracle.

Portuguese language is now complete.

Croatian language is now complete.

Swedish language was not present in the documentation languages list.

October 24, 2006
v. 4.1 beta

New features and feature changes

Better form errors handling: if an error occurs when the user fills a form (e.g. an URL format is not correct), DaDaBIK will display again the form and point out the type of error.

E-mail notices: DaDaBIK sends an e-mail message to some specified people when a new record is inserted or an existent record modified.

Previous and next buttons are now available in edit and details views.

Also the administration pages are now protected by authentication (if enabled); only administrator users can enter the administration pages. Note that the installation file (install.php) is not protected, should be used only for the first installation and then removed.

DaDaBIK now remembers the last search executed on a table, even if you change table.

It is now possible to choose the number of result records displayed per page on the fly. DaDaBIK also saves the number choosed on a per-table base.

It is now possible to set an alias for each table, the alias is used in the table listbox instead of the table name.

DaDaBIK now uses tinymce 2.0.7 (http://tinymce.moxiecode.com) to implement the rich_editor field type instead of htmlarea. This leads to FireFox compatibily.

DaDaBIK now highlights a results table row when the mouse pointer is over it. It also highlights a results table row when the user click on it, until the user click it again. You can disable this feature by using the new config.php parameter $enable_row_highlighting.

Some changes in the layout element positions to increase usability.

Finnish language is now available.

A link to the administration page is now available and is displayed only if the user is an administrator.

DaDaBIK now display using a small arrow the current type of order (ASC or DESC).

By default, after an insert is now displayed the results view.

Fixed bugs

During an insert, even if authentication and browse authorization were enabled, the similarity check procedure checked not only the records that the curent user owned, but all the records and showed the possible duplicates even if the current user didn't own them.

The documentation has been revisited, in particular it has been highlighted that Oracle needs magic_quotes_sybase = on set in php.ini.

October 04, 2006
v. 4.0

New features

DaDaBIK now uses ADOdb version 4.92. This change fixes the "Notice: Only variable references should be returned by reference in..." messages.

Swedish language is now available

DaDaBIK installation process on Oracle is now clearer.

Fixed bugs

On Oracle, from the record results view, several "Undefined index" notices were displayed, it was not possible to correctly enter the detail and the edit form of the records and the delete record function didn't work.

On Oracle 10, DaDaBIK tried to use the recycle bin tables too.

The documentation has been revisited.

In the install.php and header_admin.php scripts the name of the file index.php was hard-coded, instead of varying according to the $dadabik_main_file config variable.

The configuration file is now clearer about the $host parameter and specify the possible need of the instance name for MS SQL server

January 24, 2006
v. 4.0 beta 2

Fixed bugs

There was some missing information in the documentation.

January 24, 2006
v. 4.0 beta

New features

DaDaBIK officially supports Oracle and MS SQL Server DBMS. A special thanks to Claude Moreau (claude dot moreau dot olom at gmail dot com) for the great work he did on the Oracle porting.

The Hungarian and Slovak languages are now available.

The documentation has been improved and a new section "Coding guidelines" has been added.

DaDaBIK now checks for duplications by default for the username field of the users table.

It is now possible to set the CSV creation time limit; this can fix the problems related to the CSV creation time limit errors.

Two DaDaBIK buttons are now available ("buttons" folder).

Fixed bugs

DaDaBIK didn't display correct search result values when the same field name appears in two linked tables as linked field. This bug, supposed to be fixed in the 3.1 beta release, is now really fixed.

DaDaBIK showed a wrong list of result records for a search if $enable_authentication and $enable_browse_authorization were enabled and the user specified more than one search criteria, setting also "Any of the conditions required".

The required property didn't work properly with file types, now the setting of a file-type field as "not required" is not needed any more. Thanks to alpha2zee (drpatnaik at yahoo dot com) who proposed the first version of the patch.

DaDaBIK produced a "Fatal error: Call to undefined function: newadoconnection()" message if upgrade.php or upgrade_3.2.php were executed.

DaDaBIK produced a "Notice: Undefined variable: upgrade...." message when upgrade.php was executed.

In the login.php script the name of the file index.php was hard-coded, instead of varying according to the $dadabik_main_file config variable.

DaDaBIK didn't display the "create password" after a user adding if $insert_again_after_insert was set to 1.

DaDaBIK displayed some messages in English even if the language set was "Italian".

June 20, 2005
v. 4.0 alpha

Fixed bugs

DaDaBIK produced some "Notice: Undefined variable....." messages and a "[08] Error: during query execution" error message in the details or edit view (if $enable_browse_authorization was enabled) or after a delete (if $enable_delete_authorization was enabled) or update (if $enable_update_authorization was enabled); only if $enable_authentication was enabled and the current table or the ID_user field name needed to be quoted.

If the $autosumbit_change_table_control parameter was set to 1 the tables listbox form in the administration section was not auto-submitted "on change" and a javascript error was produced when the current table was changed.

New features

DaDaBIK uses now the ADOdb Database Abstraction Library in order to support as many DBMS as possible, at the moment it has been tested just with MySQL 4.0.x and PostgreSQL 8.x.

SQL logging: it is now possible to configure DaDaBIK for logging all SQL queries in the adodb_logsql table ($enable_sql_logging parameter in config.php)

The documentation has been revised.

June 4, 2005
v. 3.2

Fixed bugs

If two or more DaDaBIK installations were hosted under the same domain, if a user logged into one of them it was possible to access all the others bypassing the login procedure. DaDaBIK session cookies are now valid only for the directory where DaDaBIK is installed (set through the new configuration variable $site_path).

DaDaBIK produced a parse error if the Portuguese language was used.

Croatian translation is now complete.

DaDaBIK produced a "[08] Error: during query execution" error message in the results view if the table in use or the current "order by" field name needed to be quoted and the current "order by" field hadn't any linked fields.

The possible duplications results view didn't show linked field values and produced a "Notice: Undefined index....." error message if one ore more fields had linked fields (http://www.dadabik.org/forum/read.php?f=1&i=4302&t=4154).

New features

Added two known bugs to the documentation, in particular it has been highlighted a possible security problem of the DaDaBIK authentication model.

March 31, 2005
v. 3.2 beta

Fixed bugs

DaDaBIK produced a "[08] Error: during query execution" error message in the details view if, for a field, the primary key field name of the main table was the same of the primary key field name of the linked table.

All the "Undefined variable" error messages have been fixed, DaDaBIK can now works correctly with error_reporting = E_ALL.

DaDaBIK lost the "Other choices allowed?" option information after a "Refresh installation" procedure (administration interface).

DaDaBIK produced a "[08] Error: during query execution" error message if, during an insert or update, a new option was added to a select_single field with no linked fields and at least one of the preexisting options contained a character to be escaped (e.g. ').

DaDaBIK produced a "[08] Error: during query execution" error message if, during an insert or update, there was at least one select_single field with linked fields, $enable_authentication and $enable_browse_authorization were enabled, the table contains an ID_user field and the linked table doesn't contain any ID_user fields with the same field name.

An Italian sentence was not correct.

DaDaBIK produced a parse error message if the German language was used
(http://www.dadabik.org/forum/read.php?f=1&i=3432&t=3432).

In the footer page the name of the file index.php was hard-coded, instead of varying according to the $dadabik_main_file config variable.
(http://www.dadabik.org/forum/read.php?f=2&i=371&t=371).

Config variable $always_add_blank_option_search didn't work correctly, the variable is not used any more and now DaDaBIK always add a blank option to the select_single fields.

New features and feature changes

The authentication code has been in part rewritten:

The class simpleLogin (http://www.phpclasses.org/browse/package/1492.html) is not used any more
DaDaBIK stores now user information in the database and passwords are now md5 encrypted
It is also possible to use a pre-existent users table
You can use DaDaBIK itself in order to add and delete users, show and modify users information
The admin pages (admin.php, install.php) are not login-protected any more, you have to provide your own protection
A select_single field with linked fields now shows a listbox with all the corresponding linked table records, regardless of the ownership.

Six new languages are available: Croatian, Polish, Catalan, Estonian, Rumanian, Portuguese.

A "top" link has been added to the HTML footer.

The documentation has been updated and improved, in particular a FAQ section is now available.

The installation procedure has now more explicative messages.

July 19, 2004
v. 3.1 beta

Fixed bugs

DaDaBIK produced a "[08] Error: during query execution" when a linked table was referenced more than once in the same table.

DaDaBIK didn't display correct result values when the same field name appears both in a table and in a linked table as linked field or in two linked tables as linked field.

New features

DaDaBIK has now a rewritten engine that perform the select query using joins and aliases (this fixes the bug above)

A basic authorization model is available, it is now possible to allow a user to delete only his own records, modify only his own records, view only his own records. For the authentication the class simpleLogin (http://www.phpclasses.org/browse/package/1492.html) has been (probably temporary) used, but it is possible to easily customize the authentication.

A new field type is available: rich_editor; it is a rich text editor (htmlArea 2.03 by interactivetools.com http://www.interactivetools.com/products/htmlarea/) that allows to easily insert/modify HTML content

A new content type is available: html, DaDaBIK doesn't perform a conversion from special characters to HTML entities with htmlspecialchars for the fields having this content type

DaDaBIK starts now displaying the records of the first table available, without showing the home page menu. All the application (except from the administration area) uses now just one file index.php, easily renameable to embed it in a pre-existent Web site.

An upgrade script is now available, it is possible to upgrade from 3.0 beta or 3.0 to 3.1 beta without loosing the interface configurator settings.

A new parameter $enable_delete_all_feature allows to enable/disable the delete all feature

May 25, 2004
v. 3.0

Fixed bugs

DaDaBIK produced a "[08] Error: during query execution" error when a table name contained blank spaces (http://www.dadabik.org/forum/read.php?f=1&i=2136&t=2136).

DaDaBIK produced a "[08] Error: during query execution" error when the MySQL version was prior to 3.23.06.

DaDaBIK produced a "[08] Error: during query execution" error when a field has some linked fields associated and the primary key field is not numeric (http://www.dadabik.org/forum/read.php?f=1&i=2365&t=2365).

DaDaBIK produced a "Call to undefined function: ob_clean()...." fatal error if the export to CSV feature was enabled and the PHP version was < 4.2.0 (http://www.dadabik.org/forum/read.php?f=1&i=2329&t=2209); the export to CSV now works also with PHP version prior to 4.2.0.

DaDaBIK produced a parse error when the Italian language was used.

Fixed some translations and added a missing sentence in the Italian language file.

The word "home" in the bottom links menu is now available in each language file and no more hard-coded.

DaDaBIK produced a "Undefined variable: mail_feature....." notice.

New features

A new parameter $word_wrap_fix_width allows to choose if $word_wrap_col determines also the width of the column in the results table or not.

Notes

The following two bugs have been discovered during the beta testing:

DaDaBIK produces a "[08] Error: during query execution" when a linked table is referenced more than once in the same table (http://www.dadabik.org/forum/read.php?f=1&i=2374&t=2374).

DaDaBIK doesn't display correct result values when the same field name appears both in a table and in a linked table as linked field or in two linked tables as linked field.

These bugs will be fixed in the version 3.1 because they require to partially rewrite the engine that produce the SELECT statement.

March 10, 2004
v. 3.0 Beta

All the code has been revisited and in some case rewritten in order to increase efficiency and clarity.

New features and feature changes

The primary-foreign key feature is now complete: it is possible to link a field of a table (foreign key) to a number of fields of another table (containing the primary key). The produced HTML select menu will have the linked field values as "options" and the primary key values as "values". This allow to use a normalized db design.

The "export to CSV" feature has been added: it is now possible to export the current result records to a CSV file.

The speed of DaDaBIK when the database managed contains a lot of tables is now dramatically increased.

"Delete all" feature is now available: it is possible to delete all the current result records.

It is now possible to handle all the HTML produced by DaDaBIK by the CSS file, which is now very clear and complete, a new CSS file specific for printing has been also added.

It is now possible to order result records both in ASC and DESC.

The HTML produced by DaDaBIK is now more clean and complete than before.

If no order field is specified, the result records are displayed ordered by the first field present in the results table.

Two new select operators have been added: "starts with" and "ends with"

The confirmation message of a delete operation is now a javascript prompt confirmation message (it is possible to disable it through config.php, however).

After a delete operation DaDaBIK now display again the results page.

The alternate row colors feature is now available. The record results table is now displayed using alternate row colors.

When you save a record, now the edit form is displayed again on the screen.

When you insert a new record, you can now choose (through config.php) if you want to see again the insert form, otherwise the results table is again displayed.

Edit, delete and details buttons are now normal links (not HTML forms as before) and pass all the necessary values via GET, so it is now possible to call the detail page of a record from its own unique URL.

Documentation, administration interface and config.php file are now more clear and complete than before.

Each DaDaBIK error message has now a code, in order to identify it better, especially during bug reports.

DaDaBIK messages are now displayed everywhere needed and are more clean than before.

It is now possible to disable the displaying of the search/insert/update buttons at the top of the form through config.php.

It is now possible to change the select operator names (is equal/contains/greater than/less than/starts with/ends with) according to the language

The function that validate URLs now support port numbers, https protocol and four letters primary domain name (e.g. .info).

The validity of a date field is now checked during insert/update.

The word wrap column choosen in config.php now determines also width of the columns in the results table; the width is now fixed and equal for all column.

It is now possible to choose (through config.php) if always wrap words at the $word_wrap_col column, even if it is necessary to cut them.

DaDaBIK now use the $_GET $_POST $_FILES....variables introduced in PHP 4.1.0

The change table select menu is now an auto-submit one (it is possible to disable this feature through config.php, however).

The update statements now use "LIMIT 1" to ensure that only one record is updated, but only if the MySQL version is >= 3.23.

A blank first option is always added to select_single fields when a search form is produced (it is possible to disable this feature through config.php, however).

The select_multiple field types are not handled any more, at least for the moment.

Linking tables contained in different databases isn't handled any more.

DaDaBIK no more display automatically a column sign (":") after each label.

Fixed bugs:
DaDaBIK didn't update correctly a record when the "Other...." option of a select_single field was used.

DaDaBIK produced an error when tried to display the possible duplicates during an insert operation if some field names need back quotes.

DaDaBIK produced an error when the user clicked on a result page link and the current "order by" field needed to be url encoded.

DaDaBIK produced an error when tried to retrieve values of a select_single from another table if some field or table names need back quotes.

Field order changer didn't work properly: field positions weren't shifted correctly.

DaDaBIK check the similarity of records during and insert operation by using a case sensitive function, this was not correct.

DaDaBIK failed to handle properly the upload when the uploaded file name contained a single quote.

DaDaBIK displayed a broken image link if a record containing an image_file field had no images associated. This happened only with MS IE as a browser.

Fixed the bug that produced a "Warning: stat failed...." message sometimes during an upload.

DaDaBIK lost the value associated with the "Other choices allowed" parameter when, from the administration interface, you clicked on "Refresh internal table".

Upload failed when two files with the same name were uploaded in the same time.

Word wrap feature now works also with email and url fields.

Back quotes were used only if the MySQL version was > 3.23.6, even if also MySQL 3.23.6 supports them, now are used if the MySQL version is >= 3.23.6

It was possible, by maliciously changing the HTML of a form produced by DaDaBIK when possible duplicated were found and post it, to bypass fields check.

DaDaBIK didn't show the SQL statement ($display_sql set to 1) related to a search if no records were found.

March 11, 2003
v. 2.2.1

Fixed bugs

When a record containing an image_file or generic_file field was updated without uploading a new file, the record loosed the link with the old file; this bug has been fixed.

When a user perform a search in a table containing an image_file or generic_file field the "browse" button was displayed by the browser for those fields, this behavior makes no sense; this bug has been fixed.

The field names of the where clause in the update statements were not back quoted, consequently the update failed if the name of the primary key field needed to be escaped (e.g. a reserved word), this bug has been fixed.

The dutch version of DaDaBIK produced a parse error, this bug has been fixed.

New features
It is now possible to choose if you want to delete (both in the database and phisically) a previously uploaded file.

When two or more files with the same name are uploaded, a new name is assigned automatically (e.g. my_file.txt become my_file_2.txt if my_file.txt already exists, my_file_3 if also my_file_2 already exists and so on).

It is now possible to configure DaDaBIK to accept all files (regardless to the extensions) coming from upload.

Since DaDaBIK requires to set magic_quotes_gpc = on in php.ini (which is the default setting), now if magic_quotes_gpc is off DaDaBIK will stop and display an error message.

Novermber 9, 2002
v. 2.2.1 beta

The bug that caused the lost of the correct search results when the user click on a page number, supposed to be fixed in the previous release, is now completely fixed.

The version of the MySQL server is now correctly checked, in this way the "Your database is empty" bug, supposed to be fixed in the previous release, is now completely fixed.

A known bugs document is now available.

October 22, 2002
v. 2.2 beta

Support for file uploading (images and other) is now available.
The bug that caused the lost of the results order when the user click on > has been fixed.
The bug that caused the lost of the correct search results when the user click on a page number has been fiexed.
Fixed the bug that prevented the internal table manager to work correctly when the result order is changed.
The version of the MySQL server is now checked, in this way the "Your database is empty" bug has been fixed.
The numeric type now accepts also float and other numeric fields.

July 31, 2002
v. 2.1b beta

Web and e-mail fields weren't display correctly in the version 2.1 beta. The bug is fixed with tihs version.

July 30, 2002
v. 2.1 beta

A new, lighter and easier to use administration interface (related to the internal table manager) is available.

The form has now a better layout, all the fields are correctly aligned, including dates.

All the translations are now up-to-date.

It is now possible, for select_single fields, to choice "other" during an insert and fill a textbox by hand with an alternative value. That value also update the select options, unless option had driven with a custom query ("SQL:......").

It is now possible to choice if a field has to be displayed in the details page or not.

Completely fixed the bug the caused the warning message: "Warning: Call-time pass-by-reference has been deprecated......" with particular php.ini settings

It is now possible to use the "-" sign and other allowed signs in MySQL table and field names.

Fixed a bug that prevent some text to be displayed if written after a special html char (e.g. <).

Fixed a bug that prevent to choose more than 999 characters as maxlength of a field.

Fixed a bug related to the use of the double quote in the include statements, that can cause error messages.

Textbox and password fields are now checked for max lenght also server side.

Select_single fields are now checked for length and type, this improve security because a malicious user could change the html of the form and then post it.

Jun 28, 2002
v. 2.0.1 beta

DaDaBIK is now compatible with PHP 4.2, and works also with register_global directive set to off.
Added two new date display formats, which fix the problem of displaying dates before 1970
Fixed a bug that caused the insert of a separator if a select_multiple_menu or a select_multiple_checkbox were empty
The "Any/all" conditions menu now appers also in Netscape and other browsers.
Fixed some minor bugs that caused warnings and notices.

Jun 1, 2002
v. 2.0 beta

Support for multiple tables available.
"View all records" feature.
It is now possible to order a group of record by a field clicking on the corrisponding coloumn.
The pages navigation tool has been improved.
Fixed a bug about size of input field in Netscape.
Fixed a bug that about the color of the required fields in the search form.

Apr 21, 2002
v. 1.9.1

Fixed a bug that allowed an attacker to execute arbitrary sql query on the database (e.g. insert or delete records even if insert and delete feature were disabled).

Fixed a bug about double quotes handling in the search function.

All DaDaBIK users are encouraged to update to the latest version.

Apr 15, 2002
v. 1.9

Fixed the bug that caused an error during the insert if you didn't enable the check similiarity for any fields.

Fixed the bug that caused a "Required field" message even if a date field was filled by the user.

Fixed the bug the caused a warning message if allow_call_time_pass_reference is set to false in php.ini.

Added Spanish and French versions.

Mar 18, 2002
v. 1.8

The algorithm that scans existing records during an insert in order to find similar records is now more efficient (e.g. for a table with >8000 records, 2 fields to check, it is now 5 times faster than before).

Update now works also with a MySQL version < 3.23.x

Fixed the bug that caused an error if a date field was initally null.

Feb 28, 2002
v. 1.7

New features:
A new administration interface is now available and allows you to manage the internal table without any other software!! So you don't need PHPMyAdmin any more in order to customize DaDaBIK.

Configuration is now easier.

Debug mode added.

Feb 11, 2002
v. 1.6

New features:
It is now possible to disable the functions: insert, update, delete and details; in this way you can safety use DaDaBIK in a public site.

New administration interface for the internal table.

The installation procedure is now more explicative.

New customizable graphic icons for edit/delete/details buttons.

You can now choice the coloumn at which a text, textarea, password or select sinlge field will be wrapped in the results.

It is now possible to choice the target window for edit/details (self or new).

The graphic layout of the form looks now better with Netscape.

German translation added.

Jan 27, 2002
v. 1.5b

In the version 1.5 I missed the code line that allow to use the dutch version, the version 1.5b include a fix to that bug together with a config.php file more precise.

Jan 26, 2002
v. 1.5

DaDaBIK is now considered out of beta and has some important new features, for this reason I decided to call this release 1.5 (the last was 1.1 beta)

New features
Partial foreign key support: it is now possibile to drive the possible options of a "select_multiple" or "select_single" field from another table, even with a customized SQL query!!

It is now possible to select between any/all the conditions during a search

It in now possible to display a select_multiple field also with a menu (HTML select multiple tag)

For each field you can now specify a prefix value (e.g. http://) and a default value

For each field you can now specify which operator the user can use, including exactly, like, >, <

A Dutch version of DaDaBIK is now available

An on-line demo is now available

Minor bug fixed
The results of a search are now displayed taking the carriage return (\n) into account.

Jan 14, 2002
v. 1.1 beta

New features:
According to user's needs, now the internal table and the main table are in the same database, so you don't need two databases in order to run DaDaBIK.
It is now possible to specify the order of a field in the form.

Fixed bugs:
Required fields message now apper only if there are at least one required field.
Search of a "select single" field with exact/like feature enabled now works.
Some updates didn't work, now the bug has been fixed.
Bug about searching by date fixed, now you can search properly a record by date using < or >.
Time generated by insert_date and update_date are now in 0-24 format.

Dec 9, 2001
v. 1.0.5 beta

Documentation:
The configuration file is now more explicative.
The readme file is now more explicative.
A new document about the internal database is now available.
New features:
Now you can select between an "exact match" or a "like" search also in the form, on the fly. (You can also disable this feature)
Hints are now visible even during the update procedure
Bugs fixed:
The maxlength property in the internal database now works

A very small part of the function build_form() rewritten in order to make DaDaBIK more flexible.

Dec 5, 2001
v. 1.0.4 beta

The readme file is now more explicative.
Two HTML-related bugs fixed:
the background of an empty cell now appears even with Netscape
the select input field now appear correctly even with Netscape

Dec 1, 2001
v. 1.0.3 beta

Italian version added
Some english mistakes fixed
Configuration option (display the "I think that x is similar to y......" statement during duplication check) added

Nov 24, 2001
v. 1.0.2 beta

One bug fixed (creation of the internal database didn't work due to bug in db_functions.php)

Nov 24, 2001
v. 1.0.1 beta

Several bugs fixed (creation of the internal database didn't work, navigation buttons didn't work)

Nov 21, 2001
V. 1.0 beta

The first release of DaDaBIK.

DaDaBIK Change Log

August 26, 2026 V. 13.6 Levanto

July 7, 2026 V. 13.5 Levanto

March 18, 2026 V. 13.4 Levanto

January 20, 2026 V. 13.3 Levanto

October 29, 2025 V. 13.2 Levanto

September 10, 2025 V. 13.1 Levanto

July 29, 2025 V. 13.0 Levanto

May 21, 2025 V. 12.7 Aveto

March 20, 2025 V. 12.6 Aveto

January 14, 2025 V. 12.5 Aveto

December 14, 2024 V. 12.4.1 Aveto

November 21, 2024 V. 12.4 Aveto

September 12, 2024 V. 12.3 Aveto

July 25, 2024 V. 12.2 Aveto

June 3, 2024 V. 12.1 Aveto

May 8, 2024 V. 12.0 Aveto

November 30, 2023 V. 11.12 Elba

September 27, 2023 V. 11.11 Elba

July 13, 2023 V. 11.10 Elba

March 23, 2023 V. 11.9 Elba

December 5, 2022 V. 11.8 Elba

August 18, 2022 V. 11.7 Elba

June 14, 2022 V. 11.6 Elba

April 28, 2022 V. 11.5 Elba

February 28, 2022 V. 11.4 Elba

January 17, 2022 V. 11.3 Elba

November 16, 2021 V. 11.2 Elba

September 14, 2021 V. 11.1 Elba

June 16, 2021 V. 11.0 Elba

Jan 26, 2021 V. 10.6 Manarola

Jan 14, 2021 V. 10.5 Manarola

Dec 10, 2020 V. 10.4 Manarola

Aug 26, 2020 V. 10.3 Manarola

July 15, 2020 V. 10.2 Manarola

March 9, 2020 V. 10.1 Manarola

December 12, 2019 v. 10.0 “Manarola”

July 23, 2019 v. 9.4 Monterosso

May 29th, 2019 v. 9.3 Monterosso

March 5th, 2019 v. 9.2.2 Monterosso

December 19th, 2018 v. 9.2.1 Monterosso

November 7th, 2018 v. 9.2 Monterosso

September 12th, 2018 v. 9.1 Monterosso

July 5th, 2018 v. 9.0 Monterosso

Apr 11, 2018 v. 8.3 Lerici

Dec 19, 2017 v. 8.2 Lerici

Sep 5, 2017 v. 8.1 Lerici

Apr 24, 2017 v. 8.0 Lerici

July 26th, 2016 v. 7.3.3

July 6th, 2016 v. 7.3.2

June 7th, 2016 v. 7.3.1

May 24th, 2016 v. 7.3

March 16th, 2016 v. 7.2

December 14th, 2015 v. 7.1

October 5th, 2015 v. 7.0

Dec 22, 2014 v. 6.3

June 24, 2014 v. 6.2

June 2, 2014 v. 6.1

March 25, 2014 v. 6.0

July 23, 2013 v. 5.1.2

March 20, 2013 v. 5.1.1

January 23, 2013 v. 5.1

November 24, 2012 v. 5.0

November 3, 2012 v. 4.6

September 27, 2012 v. 4.6 beta

August 15, 2012 v. 4.5 patch level 1 (pl1)

June 25, 2012 v. 4.5

May 31, 2012 v. 4.5 beta

May 5, 2012 v. 4.4 patch level 1

April 3, 2012 v. 4.4

February 14, 2012 v. 4.4 beta

February 2, 2011 v. 4.4 alpha

December 8, 2010 v. 4.3 final

November 28, 2010 v. 4.3 beta RC2 (release candidate 2)

November 23, 2010 v. 4.3 beta RC1 (release candidate 1)

November 15, 2010 v. 4.3 beta3

November 11, 2010 v. 4.3 beta2

October 21, 2010 v. 4.3 beta

September 14, 2010 v. 4.3 alpha

February 18, 2007 v. 4.2

August 26, 2026
V. 13.6 Levanto

July 7, 2026
V. 13.5 Levanto

March 18, 2026
V. 13.4 Levanto

January 20, 2026
V. 13.3 Levanto

October 29, 2025
V. 13.2 Levanto

September 10, 2025
V. 13.1 Levanto

July 29, 2025
V. 13.0 Levanto

May 21, 2025
V. 12.7 Aveto

March 20, 2025
V. 12.6 Aveto

January 14, 2025
V. 12.5 Aveto

December 14, 2024
V. 12.4.1 Aveto

November 21, 2024
V. 12.4 Aveto

September 12, 2024
V. 12.3 Aveto

July 25, 2024
V. 12.2 Aveto

June 3, 2024
V. 12.1 Aveto

May 8, 2024
V. 12.0 Aveto

November 30, 2023
V. 11.12 Elba

September 27, 2023
V. 11.11 Elba

July 13, 2023
V. 11.10 Elba

March 23, 2023
V. 11.9 Elba

December 5, 2022
V. 11.8 Elba

August 18, 2022
V. 11.7 Elba

June 14, 2022
V. 11.6 Elba

April 28, 2022
V. 11.5 Elba

February 28, 2022
V. 11.4 Elba

January 17, 2022
V. 11.3 Elba

November 16, 2021
V. 11.2 Elba

September 14, 2021
V. 11.1 Elba

June 16, 2021
V. 11.0 Elba

Jan 26, 2021
V. 10.6 Manarola

Jan 14, 2021
V. 10.5 Manarola

Dec 10, 2020
V. 10.4 Manarola

Aug 26, 2020
V. 10.3 Manarola

July 15, 2020
V. 10.2 Manarola

March 9, 2020
V. 10.1 Manarola

December 12, 2019
v. 10.0 “Manarola”

July 23, 2019
v. 9.4 Monterosso

May 29th, 2019
v. 9.3 Monterosso

March 5th, 2019
v. 9.2.2 Monterosso

December 19th, 2018
v. 9.2.1 Monterosso

November 7th, 2018
v. 9.2 Monterosso

September 12th, 2018
v. 9.1 Monterosso

July 5th, 2018
v. 9.0 Monterosso

Apr 11, 2018
v. 8.3 Lerici

Dec 19, 2017
v. 8.2 Lerici

Sep 5, 2017
v. 8.1 Lerici

Apr 24, 2017
v. 8.0 Lerici

July 26th, 2016
v. 7.3.3

July 6th, 2016
v. 7.3.2

June 7th, 2016
v. 7.3.1

May 24th, 2016
v. 7.3

March 16th, 2016
v. 7.2

December 14th, 2015
v. 7.1

October 5th, 2015
v. 7.0

Dec 22, 2014
v. 6.3

June 24, 2014
v. 6.2

June 2, 2014
v. 6.1

March 25, 2014
v. 6.0

July 23, 2013
v. 5.1.2

March 20, 2013
v. 5.1.1

January 23, 2013
v. 5.1

November 24, 2012
v. 5.0

November 3, 2012
v. 4.6

September 27, 2012
v. 4.6 beta

August 15, 2012
v. 4.5 patch level 1 (pl1)

June 25, 2012
v. 4.5

May 31, 2012
v. 4.5 beta

May 5, 2012
v. 4.4 patch level 1

April 3, 2012
v. 4.4

February 14, 2012
v. 4.4 beta

February 2, 2011
v. 4.4 alpha

December 8, 2010
v. 4.3 final

November 28, 2010
v. 4.3 beta RC2 (release candidate 2)

November 23, 2010
v. 4.3 beta RC1 (release candidate 1)

November 15, 2010
v. 4.3 beta3

November 11, 2010
v. 4.3 beta2

October 21, 2010
v. 4.3 beta

September 14, 2010
v. 4.3 alpha

February 18, 2007
v. 4.2

February 8, 2007
v. 4.2 beta