Privacy Rules - OVERARCHING HIDE/do not load records

Hi,


tldr; my app correctly filters fields that are supposed to be filtered out by privacy settings. However it loads the unique id, and my rg’s display white space for every item, even if the user isn’t supposed to be able to see it. I’d love a way to filter database access with privacy rules to COMPLETELY forego data retrieval with privacy rules.

My privacy rules are super well set up, I’m using them with a data type (“thing”) to load or not load based on a user field called role. If the user’s role and the thing’s role match, they should load.

Initially I was filtering all my rg’s, but that’s super intensive. So I removed all my :filter conditionals and migrated the display rules to the “privacy” section, which functions super well BUT ----

My app is still able to pull records from the database and displays them in the rg’s as loaded items. The rg loads the unique id, but nothing else (which is the intended behavior, I assume). But since the RG has no access to other fields, all my user gets is whitespace in the rg.

  1. Idea - restrict access to all fields including the unique id so that the record doesn’t even load into the app. I’m assuming this would make bubble both faster and possibly safer.

  2. Current hack I use: I put an extra collapsing group holding records and if the main field (name) is empty or access is blocked, the record will hide. This is not ideal because it actually ADDS a step and many conditionals for the app to load.

@neerja do you have any suggestions?

Sorry I forgot to upload a screen of my setup. Normally this should prevent users who aren’t signed in (roll 100 by default) from even retrieving records menunavitems when roles != 100 .

Is this a bug?

How about removing “find this in searches” if the user is not supposed to be able to search for\see these items unless he has a right role? :slight_smile:

Thanks for your answer :slight_smile: Yes, I had forgotten to upload a screen, that is where this whole thing started… The thing not fitting any roles shouldn’t get loaded into the app right? But check it out.

User is logged out (role 100). User can see log in (role 100) but not Profile or Sign Out (role 99). In the screenshots below you can see that the debugger accesses at least it’s unique id. Therefore loads the RG cell for this unique id, but not the data in the actual fields. That’s where I’m getting whitespace.

I “manually” checked the conditionals and either it’s not working as expected, it is a bug, or it is an idea that I think should be implemented…

EDIT: in the screenshot the unique id’s don’t match, that’s my bad - but you can see in this one:

The RG is loading two menu items, one is allowed one is not. But it still loads the unique id of the second one and populates a cell.

Hm, ok.

Kinda hard to debug this like that, but it seems that you’re trying to overprotect it, or so to say :slight_smile:

What I mean - your condition to see if the user is allowed to see the contents of this role are dependent on the contents of this role.

Meaning, the user should not see the current menuNavItem numRoles, if it’s not his current numRoles.

But first he still has to see the numRoles first to understand whether it’s his role, right?
So which one comes first?

In short - I think this sequence may just not be working like you expect :slight_smile:

To validate this, I would suggest to create exactly the same condition in your app (for a random element), and check it with Inspect tool to see if it actually works - since you cannot Inspect the privacy rules in run mode. Most probably you will see that it fails, since both conditions are dependent on one each other, creating a “loop”.

The way I would do this is I would make the privacy conditions as simple as possible.

Meaning, if the user role=100, allow to see this.
If it’s not - not allow to see that.

I understand your logical construct here, but obviously this has an issue with the way Bubble is processing it, so I would try to break this down into something simpler and see if it solves the problem.

Usually privacy rules are used a bit more “horizontal”, meaning, either to see\edit that particular field, or not - depending on the role.

But not depending on the content of that field - that’s more flexible to do it in the front end.

So shortcut to get this solved is to remove privacy for the display value attribute use a front end query (either Do a Search or Filtered, depending on the amount of items in the list) to get this shown properly.

As for the privacy based solution - one would need to understand your data structure better to dig in suggest something smarter :slight_smile:

But from what it looks like now - you cannot remove the uniqueID from the search results.
Removing the unique ID would be equal to removing the “find this in searches” tag.

2 Likes

Yes, thank you. Your response clarifies a lot and gives me direction.

I read that privacy rules were checked server-side and I didn’t even consider the “loop” you mention.

I assumed that filtering with privacy instead of conditionals would be more data-efficient, as less data would be transferred from the server to the client. But I’m still not sure. Anyway I’m going to have to rework my structure because as you mentioned, the logic is there but it’s probably just not stable.

Thanks for your help :slight_smile:

1 Like