6

It is absolutely the right approach in my mind and should be a best practice followed by every developer as it does speed up development time as it removes slow downs caused by silly privacy rule errors, such as not logging in while testing. Also reduces the chances that other mistakes do not go uncovered prior to deploying to live.

If you set these up properly before implementing privacy rules, or at least do proper testing and debugging prior to implementing privacy rules, this will not happen anyway…best way is to use ‘current user’ and not some text field representing email address. In Bubble, all roads lead by to user…this is because every single data type has a built in field of ‘creator’ which is related to User data type. The created by field should not always be utilized though since there are use cases of a need to have another field, like ‘user-owner’ that you create (for example, employee created data, when employee leaves, the data can be transferred) but also because of Bubbles’ not fully realized feature of ‘cookies’ (when a user is not logged in and is not a registered user, any data they create, Bubble properly maps the ‘creator’ field to them when they return to register within 72 hours, - however, absurdly, Bubble did not make this same functional possible for a registered user, who is logged out and comes back within 72 hours and logs into their existing account).

This should be a field that is related to User and not a text field

Your privacy rules could be either ‘this things creator is current user’ or ‘this things user-owner is current user’.

1 Like