Just playing around with a form and realised it would nice if you could make a button (or other object) conditional on a data query result, as a way to show or hide elements depending on the user. I don’t think I can see a way to do this unless someone can illuminate me. 
My immediate use case. Having a form display without an update button for a standard user, and with the button for a editor user. I realise this is kind of like roles, but more granular to a page. Otherwise I fear I need to duplicate pages to cover this situation. 
I could have missed something obvious though.
I’ve shared this with the Application Builder team! We’ll get back to you soon, @DataGecko—thank you for the feedback!
Not sure I understand exactly what you want but you can define roles for your users and this role can be used to decide if a certain element should be displayed for this user with this role.
You can have something like that:
Is it what you meant?
Ah, I see.
Role based access control is an Advanced tier capability, so not currently something I have to use on the premium tier sadly. I can see how that could be used to control visibility of some objects, like you can hide or show the whole form based on the role, or fields within the form, but their is no control of the submit button for a form using Visibility. I’m just thinking that its a common situation where you want to show the contents of a record in a form layout to all users, but not necessarily allow all users to submit the form. Saves on page elements and build effort. I can think of possible workarounds, though all require a lot more work to setup.
While I think of it, conditional access control to columns within a table is another use case where adding something like Visibility would open up a lot of options for dynamic content control. (Its probably already on your road map?)
Which takes me back to the original idea of the data element as a conditional access control mechanism (which I can now see that Roles is kind of designed to do for you). The thought was that a data element could be used to return a true or false flag (returned rows or not) that could also be used to set the visibility of an item. Like a Role but it can use any filter condition to set the flag making it highly flexible. Probably some performance overhead in using a data element this way though, which may make it impractical, but that was my thinking at the time.
Roles would be serviceable if you can extend them to more page sub-elements, such as a form buttons or table columns, etc.
(Also gotta admit that for me doubling the subscription cost to get Role functionality is a bit of a disincentive for a non-for-profit application. I can see the value of course, just drowning in subscriptions already. 
)
For now roles for application builder applications are freely available to everyone. You can find it in the user source configuration:
May be you are mixing up with Role based access control for the database? The pricing model for builder application will be completely different.
That’s true. For now you have to duplicate the elements to have one inside the form and one outside the form and set a different visibility. That’s also true for the table. That’s something that will come at some point but it’s not a priority right now unfortunately.
I think we already have that in the roadmap: Add complex conditions to element visibility tab (#2472) · Issues · Baserow / baserow · GitLab
However these conditions are frontend only and don’t have effect on security. For most use cases it would work but using the role is a security feature and can change the data access depending on your role so I would really recommend to use it as much as possible, what do you think?
1 Like
Ok, well colour me a bit dim, but yea, I did think the Role based access was the database feature and had not realised the application builder Roles were different. Thanks for pointing that out! That is kind of cool to know its available… for now. Just an observation from a potential long term user, when it comes to App pricing models I hope Baserow will consider a consumption based approach and not a feature tier based model (unless the features are very much targeting enterprise use, and not just core functionality). Just saying the later would send me looking elsewhere.
I would certainly like to upvote adding role visibility functionality for columns in a table. That alone would unlock a world of options. 
Thanks again for providing the feedback. Appreciate it greatly!
1 Like