Forum Academy Marketplace Showcase Pricing Features

Privacy rules are not dynamic


I come with a new bug

Let’s start with the links this time.


When using the privacy feature (which is a good thing), and avoiding the refresh to have faster apps (which is also a good thing), if the predicates for privacy have changed, this won’t be reflected on client side.

Steps to reproduce

  1. Start as logged out. See public items
  2. Log in. List of visible items did not get updated, even though we should now be able to see the private items as well. Note the value in the text Input (= number of items + 1).
  3. Refresh. Now we can properly see all the items.
  4. Log out. We can still see the private items.

As a comparison, there’s a second type, which doesn’t use the Privacy but uses Conditional instead, to change the source, depending on the logged in status.
In that case, it’s pretty straightforward to convert, but it could become a true spaghetti mess when the privacy settings are more complex. And I’m pretty sure it’s a security hazard to trust the client-side to fetch one source or the other :roll_eyes: .

So, as it is now, Bubble encourages us to trust the built-in features and here, we have “Privacy” and “Dynamic binding (no refresh)”. And we have the choice to either lose (reimplement ourselves / hacking around) the Privacy (:scream_cat:) or to slow the whole user experience (:crying_cat_face:) by adding tons of refresh. And to be noted that in many cases, it’s not so obvious when the predicates of the Privacy Rules would change value. So, even adding game-breaker refreshes doesn’t guarantee that we would display the correct data.

As usual, I’ll open a bug report. In the meantime, if anyone can reproduce and confirm / infirm the bug, that’d be great.


1 Like


Thanks for the detailed post and demos here! This is actually expected behavior as Bubble evaluates privacy rules and what data can be retrieved on page load.

I would recommend against not using privacy rules as any users with some know how could technically access unprotected data even if it’s not being called on the page. Instead, you might be able to show / hide entirely different groups based on if a user is logged in our not. Since the dynamic expressions aren’t evaluated until a group is made visible on the page, I would expect that any subsequent groups displayed after the user logs in should be able to retrieve the expected level of data based on the privacy rules they qualify for.

Give it a try and feel free to reach out to us with any additional questions / bugs you find! You can get us directly at [email protected]

Hi @AndrewV

Thanks for your reply.

Indeed, the hide/show can be a solution… sometimes (that’s my current workaround). But once it has been shown once, it will not reevaluate the predicate. And sometimes it’s not as obvious as “is logged in” (used in my example).

Moreover, that encourages code duplication. If later, the Privacy gets changed, the dev needs to remember to also change every element that uses this.

I’m aware this is an expected behaviour. However, I think it’s working against the Bubble philosophy. People should be encouraged to do it “the right way” ( → using the built-in Privacy).

A potential fix would be to add a new workflow action “Refresh Privacy rules” (or any other name :stuck_out_tongue: ). This way, this would give the dev the power to refresh them (and without the need to refresh the page), only at specific times.


  • can continue to use Privacy the right way.
  • No code duplication.
  • No full page reload (refresh), faster app overall.


  • Dev needs to be aware of this possibility (can be documented, maybe even have it included in one of the tutorials…).

What’s your opinion about this suggestion, @AndrewV ?


This topic was automatically closed after 14 days. New replies are no longer allowed.