I’m new to bubble and currently building an MVP of a sourcing tool.
I’ve recently run into the limitation that you cannot set privacy rules based on things child records which was already talked about extensively on the forum. Unknowing of this limitation, I planned my Database so that the Things privacy rules should be set based on user roles (another thing) in Users organisation & projects.
Without a workaround, as I understand it, I would have to represent User in each Thing (e.g. one Field with List of Users for view + A field for Edit + a field for Delete) which would aggregate a lot of imo redundant data and could lead to many mistakes.
I am currently thinking about a workaround on which I would highly appreciate the thoughts of more experienced users on the platform…
I’ve come up with the following:
All user relevant things have an additional ID Field
All users logged in can see all Things ID Field but nothing else. Do search for data in groups would then be possible based on user roles (or would the fields relevant for the check, which data is loaded would also need to be visible by user?) and wouldn’t display any sensitive data.
A backend workflow checks, If a user, based on user role, should be able to do a CRUD operation on a thing. If yes, the backend workflow would run to perform the CRUD for the user in the backend and would only relay the relevant data to the user, not loading the rest.
Would that work (and be feasible in terms of speed und computing workload) or am I missing something?
here’s a simplified version of the Database I have currently planned out:
Users should be able to have multiple roles in multiple projects. A user e.g. could be the one who makes Request for Proposals in one project i.e. the project admin and in another, be a potential supplier to an RFP who needs to answer the request from another Org. Therefore, role & project / org need to be connected and that’s why I made seperate user role & org role tables.
I think because of that it is not possible to have the user role represented in one field of the user.
An org will typically have around 1-10 users, the project will have around 5 users on the admin (demand) side, and up to 300 user / orgs on the supplier side (the user & orgs who will participate in the request for proposal).
btw: thanks to both of you for participating in the discussion
Honestly I’m pretty lost on what you mean can’t set privacy rules on child records. This simply isn’t the case. With correct/optimized db structure and roles you shouldn’t have an issue at all.
You can set based on user roles if a user can edit/view records with privacy rules.
From initial post I believe your preconceptions may be inaccurate. Can you maybe record a loom to give more context?
Basically, what I intended to do is set a rule like: Current Users’s User Role’s Project contains this Project AND Current Users’s User Role’s Role Type contains Admin → Can view & edit etc. This is apparently not possible and each ‘Thing’ would need to have a field with ‘User’ represented in it.
I’ll have to test a few things in the morning and respond but off top of my head you can inverse this if you want by adding “view access” & “edit access” fields onto project. Which are “lists of users”.
And the privacy rule would just state current user is in project “edit access” they can edit and similar for view.
I don’t think it’s the most optimized way to go but I’ll check into it tomorrow and elaborate.
No need to test it out, it works like this.
It’s just that this approach is my least-favoured one as it leads to a lot of redundant data and is prone to many errors that are harder to fix later on.
If there is another workaround that is more rule based (e.g. the one I proposed in the initial post with reading data in the backend based on roles and then displaying it to the user), I want to go for that. Do you have experience with circumventing privacy rules in Backend like this?
In the sense of building an MVP I’m going to build it the not so proper way with just view & edit fields. If in the future we’re going to build it out more properly trying to work with backend Workflows, I’m going to report how it went.
