DaDaBIK 10.4 is here: faster, more secure and with a new easy upgrade procedure

Posted by Eugenio on 10 Dec 2020

Hello everybody,

I am glad to announce the availability of DaDaBIK 10.4 Manarola.

The aim of this release is to provide a faster, more secure and easier to upgrade DaDaBIK.

New upgrade procedure

Upgrading DaDaBIK is way easier now. If you have any DaDaBIK starting from V.5, you just have to copy two files (up.php and up2.php) in your DaDaBIK folder and run up.php. DaDaBIK will ask you to put the ZIP package you downloaded into a specific folder and then it will start copying/deleting the right files by itself and applying the correct updates to your DB. If you edited config.php, DaDaBIK will tell you which config.php parameters you might have modified, so you can add them to the config_custom.php file (which, starting from this version, is the only config file you should edit).

Performances

The code that takes care of the granular permissions has been optimized in various sections. This has an impact on the performances (time to load a page in DaDaBIK) if you are running a database having a very huge number of tables/fields. You should notice the difference if you are still running PHP 5: in this situation, for certain pages, you could get even a 5x speed improvement. My suggestion, however, is to move to PHP 7, to get better security and performances.

Security

A new input check, called "Dropdown security form check" has been added to prevent the registration of wrong data, check the change log for details.

Many libraries used by DaDaBIK have been updated to the latest stable version, this fixes bugs and security issues that versions previously used by DaDaBIK had.

Other bugs have been fixed, in particular you should check carefully the change log if in your environment you have session.auto_start = 1 in php.ini or if you are using select_multiple_* fields.

The documentation has been improved and a general chapter related to custom code (best practices and rules) has been added.

I suggest to check anyway all the change log

You can buy your license here https://dadabik.com/download.

As usual, if you already have a license, get your v. 10.4 copy from the upgrade page.



Best,

Eugenio Tacchini
DaDaBIK founder

Best practices for DaDaBIK applications development, part 2/2

Posted by Eugenio on 17 Nov 2020

Hello everybody,
in the first part of this blog post (if you missed it, https://blog.dadabik.com/post/112 ) I discussed how important is a correct database design when you want to build a complex DaDaBIK application.

In this second part, I'll discuss other aspects you should consider during DaDaBIK apps development. I am a software developer with tens of years of experience but when I have to develop a typical enterprise application (business processes automation, dashboards/analytics, ..), I don't code it from scratch, I use DaDaBIK: typically I can finish the work in a fraction of time, avoiding repetitive tasks and focusing on the code that matters. That's why I think I can give some general advice to developers who are not expert low-coders yet.

Here are my suggestions. 

1. Avoid, unless it's really, really the only way, to modify the DaDaBIK core code to customize the layout of your applications. There are some PHP core files that you can, if you want, modify (for example /views/results_grid.php or /views/form.php). If you are a coder, it's tempting because a little modification on form.php can render the form exactly as you like. However, when a new version of DaDaBIK comes out and you want to upgrade, your modifications will be overwritten and you have to re-apply them, maybe to a slightly different code.
   
   You can avoid that: not only the form configurator is now a quite complex tool that allows you to customize your forms in great details, but there are at least three other ways to impact on the DaDaBIK layout without editing the DaDaBIK core code:
   
   
   
   • CSS: you can edit the styles_screen_custom.css file, a file dedicated to CSS customizations
     
     
   • Layout hooks: you can write your own code (PHP, HTML, Javascript) that will be executed when a particular part of the layout is rendered; for example, the customers before edit form header hook - long name, I know :) - is executed before displaying the header of the customers edit form
     
     
   • Datagrid templates: DaDaBIK, by default, creates standard reports: results grids representing the records you have in your table/view (or the results of a search). In case you want to represent your records using a different layout, you can optionally write your own HTML template.
     
     
   Custom CSS, layout hooks and datagrid templates are NOT overwritten during a DaDaBIK upgrade.
   
   Finally, if in your application you need a page that is very different from the classic DaDaBIK pages (forms, tabular grids, charts, …) , you should think about creating a custom page that, again, is not overwritten during a DaDaBIK upgrade.
   
   


2. VIEWS are very powerful, you should really learn how to use them. Views can be used in DaDaBIK to create pre-defined reports or filtered versions of a table (e.g. I can create a view italian_customers that shows only the customers whose country is "Italy" and add it to my main menu, just after the "standard" "Customers" menu item), but this is just the basic use. More in general, it often happens that you can overcome a DaDaBIK limitation using a VIEW, creating a "virtual" data structure that represents the information in the way that DaDaBIK expects.
   
   Let me give you an example: let's say you have three tables:
   • products (id_product, name_prodcuts id_brand, price_product)
   • brands (id_brand, name_brand, id_country)
   • countries (id_country, name_country)
   
   When you display your products, you might want to see the name of the corresponding brand: easy, you should just declare id_brand in products as a lookup field and "link" the table brands. But IF you want to see the country of the brand as well, you are stuck, the country's name is in the table countries and DaDaBIK doesn't find it.
   
   The easy solution is the following: you create a brands2 view that joins brands and countries and use it as a source of your lookup field instead of brands. You kept your database normalized and, at the same time, you gave DaDaBIK what it wants.
   
   DaDaBIK treats a VIEW exactly as it treats a table and don't forget that, despite what most of the people think, if your VIEW is updatable (see what it means for MySQL, for example: https://dev.mysql.com/doc/refman/8.0/en/view-updatability.html) you can also INSERT records in a VIEW (the records will be inserted in the underlying base table).
   

   If you learn some basic SQL and how to create VIEWS, this can really make the difference if you need to create a complex applications and you can probably learn the basics in a couple of hours just by following my tutorials:
   
   
   
   
   

   
   


3. Spend an appropriate amount of time thinking about your validation functions. As you know, with DaDaBIK, you can rely on built-in validation functions (e.g. if you declare a field as email, DaDaBIK checks if the value inserted is a valid email) but you can also add your own validation function, written in PHP. Weather you rely just on built-in validation or you use your custom validation function, the validation of your users' input is very important.
   
   You might think that you have trusted, tech-savvy final users who won't add garbage to your database but in my experience this is ALWAYS a wrong assumption, at some point someone, by mistake or on purpose, will add some content that is not allowed and this can have an impact on your whole application.
   
   


4. Permissions: if you care about your data (and you should), when you grant permissions to your DaDaBIK users you must follow the Principle of least privilege (https://en.wikipedia.org/wiki/Principle_of_least_privilege) and give to each group only the permissions the users need to work.
   
   With DaDaBIK it's easy to copy permissions from one group to another so, for example: if only Bob and Alice of the group Red need some additional privileges, don't add the privileges to the whole group, create another group Green, copy the privileges from Red to Green, add the additional privileges and move Bob and Alice to Green.
   
   


5. Audit/Revisions & logs are extremely useful, and they can help you manage critical situations. Even if you think to have planned everything well, in my experience at some point you might end up in situations where you don't understand why your data don't look as expected:
   
   
   
   “how can this order be in APPROVED status if the corresponding product is not available? ”
   
   
   If you have enabled Audit/revisions and logs, you can check the history of a particular record, see when the status has changed and who (or what) made the change. DaDaBIK, by default, tracks in the logs table only the Insert, Update, Delete operations executed using the standard, built-in, interface.
   
   You can, however, log also your own custom operations! Let's say, for example, that you created a custom button "APPROVE" for the orders table, when a user clicks on it, the status of the order is changed and some other operations are executed. Inside your custom function, you can manually call the log_operation function using a specific label, e.g.
   
   
   
   log_operation('approve_order', '');
   
   
   this function call will create an entry in your logs table containing information about who and when approved the order, that, together with the Audit/Revision entries, can help you understanding what happened.
   
   


6. Row-level custom filters is another very powerful feature, in particular when you have to deal with Multi-tenant applications: let's say you want to use the same DaDaBIK application to serve several different organizations and you need each organization to see only its own data: you can add a field to your users table that defines the organization each user belongs to (e.g. id_organization), use this field also in all the tables you want to "partition" and then add a row-level custom filter that show, to each user, only the records belonging to their organization.

That's it, I hope this second part has been useful to you!

Best,

Eugenio Tacchini
DaDaBIK founder

Best practices for DaDaBIK applications development, part 1/2

Posted by Eugenio on 16 Oct 2020

Hello everybody,
during the last years, I have been involved in the design and development of some big and complex Web applications created with DaDaBIK.

They are BPM (Business Process Management) applications that typically:

• automate some enterprise business processes / workflows in order to improve efficiency 


• provide analytics / dashboards to keep monitored some aspects of the business.

While they are not open to the public (typically they are internal applications), they might have thousands of users that log-in daily to accomplish their jobs and quite big databases where all the related information is stored.

I would like to share with you what I consider some best practices when it comes to developing these kinds of applications. In this first blog post, I will only talk about database design suggestions, in a second and last blog post I will talk about all the rest.

So the first rule is the following: spend an appropriate amount of time designing your database before starting the DaDaBIK configuration.

A lot of problems I see on complex DaDaBIK applications depend on poorly designed databases. I know that sometimes you just get a legacy database and you have to deal with it but maybe the creation of a new application is the right moment to do some adjustment/refactoring. Here are my suggestions:

1. Choose the right field types: this helps data integrity and makes the DaDaBIK configuration faster (DaDaBIK uses the field type info to automatically set some parameters in form configurator). So, it sounds obvious but if you know that a field will only contain integer numbers, set it as INT (or SMALLINT, BIGINT, …) !


2. Choose the right field names: if you are consistent with field names, you will never wonder how you called that particular field when you are adding some custom code, you just know it. It can also help the DaDaBIK configuration, not only because you immediately recognize the goal of your fields in the form configurator / permission managers but DaDaBIK also uses the names as an additional information (have you ever noticed that if you have a field called email_customer DaDaBIK automatically chooses email as content type?). 


3. Set referential integrity constraints (foreign keys): again, this helps both data integrity and DaDaBIK: for a foreign key, DaDaBIK will automatically set a lookup field, without additional manual step in form configurator (this automatism, however, only works with MySQL at the moment).


4. Indexing: this can help a lot with the performances of your final application. There is a lot to say about indexes but if you don't know much about the topic, here is a general and simplistic rule that works most of the time: if your users, for a table X, frequently search or sort for a particular field Y, you should index such a field.


5. Normalization: for this point, there would be a lot to say, but in a nutshell:
   
   
   
   • For each object (or, better, entity) of your application, create a table (e.g. products and customers are two entities, you need two tables)
   
   
   • If you have a 1-to-many relationship between two entities, add the primary key of the first table as an additional field of the second table and set the corresponding referential integrity constraint (foreign key); e.g. for each customer you can have many invoices, for each invoice one customer, so in the table invoices, you add the field id_customer as foreign key.
   
   
   • If you have a many-to-many relationship you need to create a new table to represent it, e.g. each author can write many books, the same book can be co-authored by many authors so you create a books_authors table having as fields id_author (foreign key) and id_book (also foreign key); the two fields, together, should be the primary key of the table books_authors (check, however, what I say in the last point "use auto-increment fields").
   
   
   • If you end up having a table with a huge number of fields, this might be the sign that something in the design of your db was wrong. This is not a rule, if your fields all describe properties of a specific entity, that's fine; however what I have seen several times in the real world with legacy databases is that a table schema having many columns is the result of a bad design and the table can be split into two or more tables .
   
   
6. Double check that you are actually using UTF-8 character encoding.


7. Use auto-increment fields as primary keys. This is not a general database design advice, this is a DaDaBIK specific advice. This might change in the future but at the moment there are some features, such as after insert hooks or (insert) revisions that correctly work only if your table has an auto-increment field as primary key. Furthermore, if you have a table having a composite primary key (such as a table derived from a many-to-many relationship, see normalization before), consider that DaDaBIK cannot use it as unique field so you need to add an additional auto-increment field (for MySQL, this can be done automatically).

I hope this first set of simple rules can help you!

Best,

Eugenio Tacchini
DaDaBIK founder

V. 10.3 is out + Summer Survey

Posted by Eugenio on 26 Aug 2020

Hello everybody,
I am glad to announce the availability of DaDaBIK 10.3 Manarola.

This is a maintenance release, fixing a few issues. In particular, a security issue related to the use of a shared computer and two additional issues, the first related to select multiple fields and the second related to the less_equal_than search operator are something you should definitely go through. As usual, I advise to check all the change log

You can buy your license here .
As usual, if you already have a license, get your v. 10.3 copy from the upgrade page.

Since only a few files have been changed and since the new fast upgrade procedure is not ready yet, please find here the list of the files (program_files folder) that have been changed respect to version 10.2. This should make the upgrade process easier (you don't need to replace all the files, only the ones in the list, you still have to execute the last two steps of the upgrade instructions starting from running the upgrade.php script). This works only if you don't change edition (Pro, Enterprise, Platinum ... e.g. if you upgrade from 10.2 Pro to 10.3 Enterprise, this can't work).

/apps (the whole folder)
/include/business_logic.php
/include/header.php
/index.php
/install2.php
/upgrade2.php
/pwd.php
/version_first_installation
/views/details.php
/views/form.php
/views/results_grid.php

One more thing: the community of DaDaBIK users is growing year by year and I feel the need to understand something more about how you use DaDaBIK, in order to take better decisions in the future. I have created a very short (4 multiple choice questions) survey that you can access here:

https://dadabik.com/forum/list.php?3

Please have a look and spend two minutes to answer the four question!


Best,

Eugenio Tacchini
DaDaBIK founder

V. 10.2 is out: new calendar/date picker, new permissions copy feature, many important fixes

Posted by Eugenio on 16 Jul 2020

Hello everybody,
I am glad to announce the availability of DaDaBIK 10.2 Manarola.

This version contains two important new features, some other improvements and the fix for many issues.

Here are the two big features:

1) We have a new, modern and powerful calendar/date picker: 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).

2) Table-to-Table permissions copy. This was the most upvoted feature in our canny and therefore I decided to implement it.
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, or a subset of them) and you want to assign the same permissions.
This feature is for Enterprise/Platinum version only.

You can see both the new features in the sales management online demo (check the table orders to see an example of the new date picker)

Other improvements in the change log

About the issues fixed: the bug related to group-to-group copy permission (you probably heard about it if you are registered to this newsletter) made me go for a complete code revision (related to wildcard escaping) so in the changelog you will see a more complete description of the bug (that has been fixed) and the description of several other (related and not related) issues that have been fixed.

I strongly suggest to go through the change log ( to understand which issues your current DaDaBIK application might have) and to upgrade to this latest version.

Among the other things, a known bug, not fixed yet, has been added to the documentation, related to records having, has unique field value, a string containing particular characters. I would say that the vast majority of typical dadabik applications are not affected, but it is important to check that out.

You can buy your license here

As usual, if you already have a license, get your v. 10.2 copy from the upgrade page .

I hope you will have a great and safe summer!

Best,

Eugenio Tacchini
DaDaBIK founder