Question about use case: Multiuser access management

Feature Ideas
#1

Hi,
I was just wondering whether the following use case could be eventually be used with baserow, as I am not sure about the planned functionalities.

Let’s assume there are several users and they have to send data to a central db table. The users would send the data through baserow. But the users are not allowed to see what the other users have inserted. Actually the users are only allowed to see what they inserted themselves in the past.

So one db with one table that is valid (in its shape, data types) for everyone. But the access is restricted only to “own” data of each user.
The admin only is able to collect the data from all the users for further processing.

Kind regards
Christian

1 Like
#2

Yes that is possible.

image

If you have a list with unique identifiers you can filter the contents of the table. So users would only see themselves.

In the Baserow extension for Kodular or App Inventor it would work like this. Remember what you see is an api call translated into a block.

image
image936×407 42.6 KB

So if I would search for “Peter” I would get 2 rows returned, if I would search for “r” I would get 4 rows returned.

3 Likes
#3

Thank you, for your answer!

So, if I understand correctly, baserow would serve as the db-api. An additional app is necessary to make the api-calls. The frontend for the users for typing in data than would go, in your example, over an app made through Kodular or App Inventor, and not over the frontend of baserow. User management and so on would go over the other frontend app, as far as I understood.

#4

No, you can also filter directly in Baserow. I was just explaining how i use Baserow and would do it.

image

image

You can have multiple filters.
image

Reminder: I am also still learning the possibilities of Baserow :wink:

1 Like
#5

Your described use is currently not possible by just using Baserow. You would need some external tools to make it happen. If multiple users have access to the same table and you add a filter that only shows the rows that have been created by a certain user, the other users can easily remove that filter or create a new view to get access to all the rows. All users that have access to a group have the same permissions currently.

In the future we plan on introducing role based access control. If we’re going to do that on row level, it should be possible to only give read access to a certain user. Not sure yet how it would work practically, but it should be possible to only give users access to the data that they have created. As an admin, you would be able to see everything of course.

2 Likes
#6

So users who for instance use Kodular to make an app that fills the Baserow database and get filtered data back should do what the OP wants. Or am i missing something?

#7

What I mean is that it would not work by just using Baserow. In combination with another tool like Kodular it could be possible, but if you only work with Baserow directly it’s not yet possible.

2 Likes
#8

I was thinking about how this could work in the future in Baserow, here is one possible idea:

  • We add a collaborator field which lets you reference actual users in your group.
  • When used on a form view you can make a collaborator field always be set to the user submitting the form
  • We add the ability to share a particular view to only certain people in a read only fashion, and hide the rest of the table
  • We add a filter which is “filter this collaborator field down to only rows which contain the user actually looking at the view”

Then in combination these various features could be used to implement a table in the way described by Christian. You would make a private table with a collaborator field, make a form view for that table only select users can see which sets the collaborator field to the user who submitted, then you share a view with the users which has the “only see your own rows” filter.

Alternatively instead of having some sort of “only show rows which have your user” filter you could instead build a proper row based permissions system. However an idea I like is that what if you could use an actual Baserow column to define the row level permissions.

So for example, you could have a “permissions” field which is just like the collaborator field but you also can select what permissions the user in the field. E.g. you could create a permissions field and select just the “can view” permission. Then when the owner/admin of the table can add a user to a particular row and now they will be able to see that row.

The advantage of a permissions field approach is, it is just a normal field so everything else that you get for free with fields in Baserow you get with it. So you can export it, filter by it, sort by it etc. Also you can use it in form views in the way described above. Also because its just a normal field I hope this makes it much more intuitive for users to understand and work with compared to having some sort of separate GUI for row level permissions.

Anyway these were just some random ideas I had in this area!

2 Likes
#9

Hi @bram any news about the role based access control?
We had an issue today because of this. One of the sales guys (non tech) has access to baserow to update, create rows… He clicked on edit field and changed field type and we lost some data because of this and there was no way to restore it.
I wanted to give them access as a data entry role only, but not access to create or edit tables, and fields

#10

Hi @mahmouds12, we expect to release role based access control between late September and half October. We have undo/redo functionality in Baserow. When something like this happens, you can do ctrl/cmd + z or click on the undo icon the bottom left corner to undo any action. If a field conversation resulted data loss, it can be undone. Unfortunately, it’s a bit too late now, because the undo history is permanently deleted after two hours.

#11

Hello @mahmouds12! Role-based access control is now available in Baserow: 1.13 release of Baserow // Baserow :raised_hands: