Yes an on premise solution is quite important for place in hired in. To add to this I’ve been doing a lot of looking into products like this and explored nocodb as a use case. Here are some limitations I’ve run into.
1) Granular user roles/permissions. Nocodb has this but it’s a little awkward with different bases. For example it’s hard to see which tables that user is limited to as you create new bases.
2) Forms. The form needs to have flexibility in required fields which nocodb (and not just based on schema) does but it’s missing a key feature. That would be “created by” field which doesn’t work on external database with different bases for different permissions. As in if you have a different base per user group (to have different permission on table access) adding a new record does not populate created by correctly.
3) relational data. The goal of these products is for non-technical people to use these and none have the option of clicking into the relation to bring up that record on its table. As in all you see is the description/id of the relational record.
4) at some point you want to possibly use the database for user management. Because you may want to write an internal tooling that scans a qr code or something or the form is client based. But then you have users that may live on a different database interacting with your main database. And then you would need to match the users with what they view and what they can create.
Essentially what I found is that with nocodb is that it is good for viewing data but to add data I need to create forms.
But then nocodb lacks in “dashboard” statistics and graphs
Sorry if this is not clearly explained. I’m on holiday and tired rn.
Regarding permissions, I think we meet your requirements. End users do not have permission to tables directly, they can only enter data through forms and sheets.
Regarding "created by", do you mean a field that is automatically set, based on who created the record? That's on our todo list.
Regarding relational data, we meet your requirements. Any time there is a foreign key, we display a "..." button which shows up with records from the foreign table you can select the row you want. This is fairly sophisticated... you can display all records from the foreign table (default), our you can have a query, and you can even have cascading dropdowns (for example you select Region in the first dropdown, then it shows Cities in that region in the next dropdown and so on), then matching rows are shown.
Regarding user management we store users and permissions separately from databases, and the permissions you applies to all databases in the application. Permissions are set at the application level and you can create a different application (with connections to same databases if needed) if you want different permissions.
Thank you for taking time out of your holiday and writing this.
2) If you create the tables from noco interface you get those fields else not as these fields are abstracted fields on top of your DB fields.
3) not sure what you mean here - noco is known for abstracting these IDs away and are hidden as system fields (see field menu). The role of lookup etc is what you need.
1) Granular user roles/permissions. Nocodb has this but it’s a little awkward with different bases. For example it’s hard to see which tables that user is limited to as you create new bases.
2) Forms. The form needs to have flexibility in required fields which nocodb (and not just based on schema) does but it’s missing a key feature. That would be “created by” field which doesn’t work on external database with different bases for different permissions. As in if you have a different base per user group (to have different permission on table access) adding a new record does not populate created by correctly.
3) relational data. The goal of these products is for non-technical people to use these and none have the option of clicking into the relation to bring up that record on its table. As in all you see is the description/id of the relational record.
4) at some point you want to possibly use the database for user management. Because you may want to write an internal tooling that scans a qr code or something or the form is client based. But then you have users that may live on a different database interacting with your main database. And then you would need to match the users with what they view and what they can create.
Essentially what I found is that with nocodb is that it is good for viewing data but to add data I need to create forms. But then nocodb lacks in “dashboard” statistics and graphs
Sorry if this is not clearly explained. I’m on holiday and tired rn.