DaDaBIK 10.6 is here.

Dear all,
DaDaBIK 10.6 is here.

This is a maintenance release containing two important fixes related to sqlserver and Wordpress and some other general fixes.

Check the change log to see the complete list of fixes and changes:
https://dadabik.com/index.php?function=show_changelog

If you are using DaDaBIK with sqlserver or as a Wordpress plugin, it's particularly important for you to upgrade.


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

As usual, if you already have a license, get your v. 10.6 copy from the upgrade page: https://dadabik.com/index.php?function=show_upgrade_new

Best,


Eugenio Tacchini
DaDaBIK founder

DaDaBIK 10.5 is here.

Dear all,
DaDaBIK 10.5 is here.

This release contains some bug fixes and a few new features.

Bugs fixed: the most important one is probably an issue with "copy permission" that in some particular case didn't work as expected. For all the details, check the change log: if you are in the situation described in the changelog, your permissions might be not correctly set.

The most important new feature: you can now use "conditional" fields logic even in the results grid. Let's say you have a products table with many fields and you wan to show, in the results grid, only a subset of those fields, according to which "product type" the user selects as a search filter. You can now do it. Check the documentation for all the details.

Thanks for all your feedback related to the new upgrade procedure, very much appreciated. Upgrading DaDaBIK is now easier than it used to be and hopefully it will improve even more in the future; I've improved the procedure a bit already, considering some of the suggestions I've received from you.

I suggest to check all the change log anyway to see fixes, new features and changes:
https://dadabik.com/index.php?function=show_changelog

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

As usual, if you already have a license, get your v. 10.5 copy from the upgrade page: https://dadabik.com/index.php?function=show_upgrade_new

Best,


Eugenio Tacchini
DaDaBIK founder

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

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

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

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