Condition for fields in a database query

[Mr.Rubi]

Conditions for fields are in Database Insert:

Conditions for fields are in Database Update:

But it is not clear why conditions for fields are missing in Database Query:

This feature helps you easily configure data security. With it, you can easily restrict access to fields when inserting a record and updating it, for users who should not be able to change the fields. If this function were in Database Query, it would also be easy to work with restricting access to fields when reading.

This feature is very necessary so that you can easily configure data security.

[Mr.Rubi]

I will explain a little why this function may be useful to you, for those who did not understand it.

This is a security setting in nocodb (open source, free analog of airtable). As you can see from the screenshot, there is a flexible configuration of access by table fields for all operations. This is a very flexible and convenient security system.

If you try to recreate such a security system in Wappler now, you will face difficulties when restricting read access to the fields of your database tables. But if you implement the discussed function, then it will become very simple and easy to recreate this security system in Wappler.

[Mr.Rubi]

@George, could you answer my question? How hard is it to implement this function in the Wappler and is it possible to see it in any of the upcoming updates?

The answer to this question is very important to me for the following reason:

I am developing a CRM system for a client in which I needed the ability to dynamically set access rights to tables separately for each field. To do this, I will need to create a lot of requests with access rights checking for each field. I can implement this through a custom query to the database right now. However, in parallel, I am developing a CRM kit for sale on marketplaces, created on the basis of a Wappler, and it would be very cool to include a flexible security system in this kit. This would make it more attractive to the majority, because everyone would be able to create their own set of roles inside such a system, and give each role the necessary set of accesses for each field. For such a CRM kit, it is very important that the maximum functionality is implemented on the basis of a Wappler. Because it will make it easy to change and customize this CRM with the help of a Wappler for those who are not familiar with the code. For this reason, if the requested function cannot be implemented in the Wappler quickly, I will have to abandon the implementation of a flexible security system in a CRM kit designed for a wide audience.

[George]

Yes this is indeed difficult to implement and also not really practical from the Wappler usage perspective.

This is because the queries all have fixed columns output to pick from with the data picker dialog.

If those columns are all conditional which one do you want to pick? And what will be the values…

[Mr.Rubi]

Perhaps I did not correctly explain why I want to use the conditions in the db query builder?

I’ll try to give an example. Imagine that we have three roles in the system. And each role has a different set of rights relative to this table:

Role 1 - should only see the id and make fields
Role 2 - can see the id, make and model fields
Role 3 - sees the data of all fields

And when I say data restriction, I’m talking about getting this data in a client-side request.

In order to implement this functionality now, I need to do such a server action, in which first there is a determination of what role the user has, and then, depending on the role, one of three different database queries will be used. In fact, you need to create three different server actions. At the same time, all roles must be defined in advance, and their rights are rigidly fixed in server actions.

In the event that the requested functionality is implemented in the Wappler, you would not have to create different server actions. It would be enough to have one server action that can serve requests from any number of roles. The role check could be included in the condition for each column. Therefore, the request would have all 4 fields, but in each field there was a check whether the user belongs to a role that can have access to the field. This would result in the same server action returning a different amount of data, depending on which user made the request to the table. It’s very convenient and very flexible!

With this functionality, you can create systems in which administrators themselves can create any number of roles, and configure access to data for each field for each role.

The current implementation of the database query builder in the Wappler does not allow creating such a security system in the application, because conditions cannot be created and all requests are static.