Database Structure and Privacy Rule Challenge

Hi,

I have structured my database so that all users belong to:

  • a company (data type)
  • and one or more user groups (data type)

I use this to define permissions and access.

Now, I have created a data type that contains files. Each file is similarly linked to:

  • a company (data type)
  • and one or more user groups (data type)

When I try to create privacy rules that define different permissions, I encounter a couple of problems.

What I want is the following:

WHEN
this file's company is the current user's company 
AND
this file's user group contains the current user's user group 
THEN

However, I am encountering an error with this rule. To troubleshoot, I have split the rule into two parts, and the first part before the AND operator works, but the part that comes after the AND fails. Can someone guide me in the right direction on what I need to do to get this work?

1 Like

Seems that the user belongs to a list of user groups which is not possible for the operator contains to handle.

1 Like

Yeah, you’d have to restructure the schema but why do you need the first part at all?? what’s wrong with just the user group? And if its because the user group can be associated with multiple companies, then that’s a spotlight on what DB changes need to be made.

1 Like

@cmarchan So a user can not have multiple user groups? Why not?

@code-escapee

I´m using “current user” with the “constraint company = current users company” to always only show the users company data…

1 Like

Of course they can, but you’ll have to change the privacy rule to accomodate.

The problem is the ‘contains’ operator returning True only if the left hand side contains ALL of the right hand side. It is not an ‘intersect’ operator, which determines whether there is an intersect between the two options. It must be fully contained.

Does a file have one or many user groups?

1 Like

@Rallis

It can as @nico.dicagno points out. Why it cannot in this context? It is a question for Bubble. My take …. It is by design (restricting operators) to make things lean/performant on such a foundational aspect of the platform.

It is up to the developer the choice to structure or not the schema considering the options offered in this context.

The file having a list of userGroups while the user also having a list of userGroups and aiming for privacy rules to accommodate this. Does not work due to the absence of operators to handle this schema.

Given the operators available, if the fileDataType belonged to one userGroup then the 2nd part could work. Where currentUser userGroups contains this fileDataType userGroup. But it is likely that you do not want this.

The first part ensures that theUser’sCompany fileDataTypes are served to the browser. If this is not enough …. the schema likely needs a change.

2 Likes

A file

A file can have more than one user group. How should the privacy rule look like to achieve this?

As @cmarchan says, sadly you’ll have to change your database schema to accommodate for this privacy rule. Privacy rules operators are very limited on Bubble and do not work well with many to many relationships (users have many usergroups & usergroups have many users). In your case its even worse because file-usergroup is also a many-to-many.

The most straight-forward bubble solutions are the following:
On every file, save a list of users that have access to that file
On every user, save a list of files that the user has access to.
Pick the one that would lead to shorter lists.
Once the database is changed, you shouldn’t have problems with the resulting privacy rules.

I hate using long lists but sadly with privacy rules of many to many relationships it seems like the most straight-forward way.

Thanks for the clarification! This was cumbersome. I’ll have to try to figure out a better way to do this without too much manual work.

/Rallis

I agree its cumbersome, but it wouldn’t need any manual work. You dont need to list them manually.
You can create a backend workflow that automatically populates the list for all existing things by running a search.
You would also need a workflow which adds/removes users/files from the list when they gain/lose privacy access.

The thing that would simplify your usecase a lot would be if you Users only belonged to one user group. This is standard practice; giving users a single role such as admin,developer,marketer, or even Office 1, Office 2, Office 3.
If i may ask, why do you need users on multiple usergroups?

I understand. I will take a look at backend workflows. I haven´t used that before.

I have multiple modules in my solution, so I need to differentiate access, not only at the role level (admin, manager, standard, guest, etc.). These roles essentially control whether they have rights to edit/delete or only have read access.

I use user groups to assign access to different modules and pages.

For example, I have users within the same company where:
person 1 should have the role of manager but only have access to module 1, while person 2 should also be a manager but only have access to module 2 and 3.

To avoid having too many different user groups, I think it seems neater to have one user group for each module, such as one for Module 1, one for Module 2, one for Module 3, etc. Users can then be assigned to individual modules, rather than me having to create many different ways to match this. For example:

User A: Module 1 and 2
User B: Module 2 and 3
User C: Module 1
User D: Module 1, 2, 3, and 4
User E: Module 2 and 4

Another example is that I have some external users who should have access to 1 module. These users are only associated with ONE user group. I want to distinguish these users from internal users who also need access to this module. Therefore, I have duplicated this group, named it differently, and given the group slightly different permissions. Person 1 in the example should, for instance, have access to this group as well.

Was that understandable?
Maybe one should do this completely differently. But if so, I’m not quite sure how."

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