Strongly recommend we allow viewers and especially editors to be able to create filters. I think it is also important to allow editors to be about to “share” the filtered views.
We have a “team” that is allowed to edit a Baserow database. The team is called “librarians”. We don’t want them to have any more power as the database structure has been intentionally locked-down. However, we want to be able to have them both filter and share filtered views. Filtering is a basic viewing function that anyone with access should be able to do.
In terms of “sharing” a view, I would also like “editors” to be able to have this function. We really like the way the sharing capability was designed, but we don’t want to have to give people admin authority to use it.
Sorry if I’ve misterpreted or there is a setting, but I looked around and didn’t see any options for this.
Sorry if I’ve misterpreted or there is a setting, but I looked around and didn’t see any options for this.
We don’t allow custom configuration of these options in the interface yet. Although it is technically possible to reassign what role can do what if you are self hosting and fork the repo.
We have a “team” that is allowed to edit a Baserow database. The team is called “librarians”. We don’t want them to have any more power as the database structure has been intentionally locked-down. However, we want to be able to have them both filter and share filtered views. Filtering is a basic viewing function that anyone with access should be able to do.
The ethos with editors vs builders is that an editor can change the content of the data but can’t change the structure of the data. You could argue that filtering is a change in structure more than a change in content even though this wouldn’t be as clear as the operation of changing a field type.
This is a security feature ultimately and different people have different ideas what each role should do, I do doubt a bit that we can have a system that will satisfy all use cases, meaning if we make the proposed change now there is a good chance somebody else feels like an editor shouldn’t be able to do that.
In terms of “sharing” a view, I would also like “editors” to be able to have this function. We really like the way the sharing capability was designed, but we don’t want to have to give people admin authority to use it.
This is a bit different since sharing a view exposes the data to an undefined number of people. In my opinion that should be a highly regulated operation since data can easily be leaked (even by accident) if you allow people to share the data.
The proper solution here is to be able to configure role permissions yourself, which if I remember correctly should still be on the roadmap (I joined a different team at the start of the year so don’t quote me on that :D).
@deet, it’s already possible for editors to filter and sort in their personal views. At some point, it will also be possible for editors to share their personal views publicly, although there are some security concerns to consider. Maybe we’ll make this a configurable setting for admins to decide.
In the near future, it will also be possible for editors to filter and sort in collaborative views, but those filters will not be saved. This means that if they reload the views, the original filters and sorts will be applied. This is because of what @Alex described about not having the permissions to change views.
That would be great. We have 2 databases right now. One is a document library. Another is self-identified audit issues. In both cases, we really like the idea of being able to create a filtered view to send to a non-user (for example an auditor or some other stakeholder within our company that we want to selectively share info with). I can appreciate the security concern depending on the set-up but in our case our server is only accessible internally.
Maybe build in a feature to revoke a shared view and also optionally create time limits for specific shared views. That would help manage security.
Yes, I was testing role based user accounts today. And I agree, possibility to have filter and sort options accessible for editors would be helpful. And agree with the “locked” or predefined filter/sort configuration when reloading the page with table or re-opening it again (by editor user).
We could go even further - there could be the option for bulder or admin to restrict or allow these functions if needed. Also restricting/allowing hidden fields function in a similar way. And even more: what if me as an builder or admin want to allow for editors and lower user roles (or certain user group) to allow to play with hidden fields function (f.e. them may want hide some more fields while they will work with the database and rows), but want to restrict to see and unhide fields once hidden/disabled by me?
Yes, I know, this can be a bit complicated to implement, but it would make the whole thing even more flexible and configurable in terms of what I want allow to display by certain users, while still giving them possibility to use these useful functions (filters, sort, hidden fields).
Ultimately, IMHO the underlying issue is that some people want to customize permissions per role i.e. have custom roles. I don’t know whether that’s currently possible. In any case, to be able to extract the maximum value out of that feature, the permissions need to be very granular.
