Forum Academy Marketplace Showcase Pricing Features

Bubble Pro's and Admin Team: Major Privacy Settings issue

Hi all. Before I get started, this is an issue I don’t believe most people would face using Bubble.io. It’s just the position we’re in. Bubble is AMAZING. Such a great product that gives you the ability to create things most would think impossible on a low code platform. I couldn’t recommend it enough. Shoutout to y’all at the Bubble team!

In this thread I’m going to break down a major issue with Bubble’s Privacy Settings. I’ve been looking for a way around this, speaking to a few professional and highly respected Bubble developers over the course of 2 months, and there seems to be no fix. I tried to create a fix, but I’ve had no luck. Let me break it down.

Issue #1. Scalability.
We have developed an application of ridiculous size. It’s kind of insane what we’ve pulled off with Bubble, which shows just how great of a product Bubble is. I’ve been told by many people it’s the biggest application they have ever seen and they don’t even think Bubble thought it was possible, lol. Shout out to The UPstarters for helping us create it, and specifically @AliFarahat he is the MAN. While almost every aspect of our application is scalable, (customizable at every account owner level) this is not possible for Privacy Settings.

Currently, there is no way to allow users to customize their own Privacy Settings. You cannot access this through workflows, thus, it is up to Developers to create the settings, and no one else. We need a role-based Privacy system. Account owners (Restaurant owners will create an account, their entire organization will use it daily) need to create their own employee roles based on their own restaurant hierarchy. Thus, I need Privacy Settings to work with this.

Example: Let’s say an Account Owner makes a Team Member role and it’s below their Director role in the hierarchy. Account Owners choose where their roles sit in the hierarchy through a hierarchy chart that assigns a numerical value, let’s say 1 through 10. Let’s say Team Member is Level 1, and Director is Level 8. A Team Member should not see a Directors Disciplinary Action/Write up data.

In Privacy settings, it would look like this: “Current User’s Role’s #Hierarchy < This Disciplinary Action’s #Hierarchy” = do not show.

and: “Current User’s Role’s #Hierarchy > This Disciplinary Action’s #Hierarchy” = show.
I really thought this would work.

However, Privacy Settings is extremely limited. Instead, I can only do: “Current User’s Role’s #Hierarchy IS/IS NOT/ IS EMPTY/ IS NOT EMPTY This Disciplinary Action’s #Hierarchy” = do not show.

Scalability does not exist for Privacy Settings.

Issue #2. Cluttered and inefficient.
My only other option I can envision is to make permanent roles that ship with the product. This is not an option for us, as it’s nowhere near feasible. We are aiming at a market with thousands of locations that all have their own employee hierarchy and it needs to be specific for them, but i’ll still break down the issues.

Let’s say we have 6 roles that ship with the product in order of lowest to highest hierarchy. Team Member, Team Leader, Shift Leader, Director, Executive Director and Owner. Now, lets look at what we’d need to do for Privacy Settings. Strap in, this is a wild ride.

First, this is something we can’t do either, reference “This Disciplinary Action’s X’s Y” . Example: “Current User’s Role’s Role Title is Team Member and This Disciplinary Action’s User’s Role’s Role Title is Team Leader” No bueno. EDIT: this has been a reported issue for at least 3 years now, see Rules that use "This Attendee's X's Y" can't grant search access right now

Now let’s attach the role title to Disciplinary Action and try again…
Example: "Current User’s Role’s Role Title is Team Member and This Disciplinary Action’s Role Title is Team Leader " = do not show.

Now all I need to do is copy this 4 more times for do not show, then make the workflows to show at their level and below. Now just repeat this for all 6 roles. Sweet, i’m not doing that math, but now I have something like 100 conditionals for Privacy Settings for one Data Type. Annnndddd it’s not scalable, so none of our customers can fit the product to their specific needs.

Conditionals on repeating groups would work great, but that’s not secure enough. Data is still visible within inspect element, and we’re taking Privacy very seriously.

I’m sorry this was a lot. I’ve been struggling with this for months. Is there something I’m missing? How can I make this scalable?

1 Like

I agree, there’s gotta be a better way for us to set up conditionals. I’m using tons of conditionals as well, the possibilities just multiply on top of each other. Does anyone know a solution for this? Is regular code more efficient in that sense?

bump :confused:

I’ve implemented a permission management functionality in an SaaS.
I’ve created data type “Role” that includes Permissions (CRUD - y/n) for every asset in the app. Admin can create different Roles as needed and assign the Roles to users.

In the UI the elements have conditionals that check current user Role Permissions and show/hide based on it. For instance, if the current user’s Role doesn’t have permission to delete tasks, the delete button will not be shown for this user.

1 Like