Until you set privacy rules, all data created by your users or yourself can be read by anyone. Anyone with some programming skills can view all your app's data, even if there isn't a page in your app that explicitly shows the data to users. That's where privacy rules are important, they guarantee data is only shown to people to meet some criteria. Privacy rules are enforced on the server, which makes them secure.
When you create a new app, all data is open to the public. This is appropriate for things such as comments on a blog, where you want to share it with the world. However, many apps involve users submitting information that you don't want to share with the world, such as their names and emails, or comments meant only for people they already know. Privacy rules are the tool Bubble gives you to protect that information and make sure it is safe.
If you haven't explicitly created privacy rules for a given thing, then the data is not secure.
Any data type (the types you define and the User type) can have some privacy rules. A privacy rule is composed of two things:
The condition. This defines if a rule applies to a specific situation or not.
The permissions. These are the type of things a situation that meets a condition enables a user to see.
A privacy rule also has a name, which is only used for editing purposes.
The condition is a dynamic expression that should evaluate to yes or no. The Issue Checker will flag expressions that aren't evaluating to yes/no as an issue and should be fixed.
See an example below that makes sure that only the sender and the receiver of a 'message' can see its content.
The first role lets the sender and the receiver of the message see all the fields, see attached files if there are any, and will ensure that search results include messages that fit the role. The second role, the standard one, hides all fields and files from other users, and makes sure messages cannot be found in searches. You can add some constraints in your searches to avoid some results showing up, but using conditions makes it more secure and readable.
These are the permissions that a rule (when met) grants. When multiple rules apply, the user has access to an object if any one rule grants access to it.
View all fields. If you uncheck that box, you will be able to pick the fields that users in that rule can see. If you check the box, all fields will be visible. Unchecking all the field boxes will ensure that users in that rule cannot see any field.
View attached files. If this box is unchecked, users won't be able to see uploaded files that are attached to a thing of this type. You attach files to things when the files are being uploaded, at the file upload element level.
Find this in searches. Uncheck this box if you want to prevent users that are in this rule to see search results for this type.
Allow auto binding. Check this box to allow users in this rule to modify things through autobinding. You'll have to pick the different fields that can be modified by users in the current rule.
If you have multiple privacy rules, there's a chance that a user could fulfill multiple of them. So what happens in that case?
The privacy rules are essentially additive. If a user fulfills multiple privacy rules for a given type, they will have the highest level of permission in each parameter out of all the rules they fulfill.
If a user fulfills no custom privacy rule, they will, of course, default to the "Everyone else" rule.
Using privacy rules can make debugging harder, as some data may not be visible in your workflows. The debugger has a special mention for things that have been altered by privacy rules, see the relevant chapter for more details.
Privacy rules do not apply to modifying data through workflows. The way you control who can do what in terms of data modifications is through conditions on the workflows' events and actions. As the conditions are checked on the server, this is as secure as setting up privacy rules for reading data and modifying it through auto-binding.