Until you set privacy roles, 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 roles 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 role is composed of two things:
The condition. This defines if a role 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 role 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 to show up, but using conditions makes it more secure and readable.
These are the permissions that a role (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 role can see. If you check the box, all fields will be visible. Unchecking all the field boxes will ensure that users in that role 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 role to see search results for this type.
Allow auto binding. Check this box to allow users in this role to modify things through autobinding. You'll have to pick the different fields that can be modified by users in the current role.
Using privacy roles 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 roles, 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 roles for reading data and modifying it through auto-binding.