Forum Academy Marketplace Showcase Pricing Features

Granting permission based on shared item in a list?

Hey guys,

Working on an app that is catered towards athletic organizations. I have a field on the type user of “teams” which includes a list of all the teams a given user is a part of. I also have a field “role” on users that can be Admin, Coach, or Athlete (the basic user).

I’m trying to make sure that Coaches are only able to see users that are members of teams that appear in their list of teams. i.e. I don’t want the soccer coach who is a member of the JV soccer and Varsity soccer teams to be able to see an athlete’s profile unless they’re on one of those teams.

That puts me in a weird situation for the data privacy rule - trying to scope it to “current user’s role is Coach and this user’s teams contains (this is where it breaks down) at least one team that is also contained in current user’s teams.”

Hope that makes sense. Any ideas? I’ve thought about breaking out team membership into a separate table/type which might help here but thought that the multiple items in a list thing could make it easier.

Hey @zenter :slight_smile: I’m not 100% sure but I think creating a new table would help, as you said. Can you share a link to the editor?

What is your limitation exactly with the privacy tab? Can you share a screenshot?

Sure, here’s the closest I can get (using stuff that obviously won’t work :))

Any other ideas for how I could do that? They can see this user if at least one of this user’s teams is also contained in the coaches teams.

Could you share a link to your app? May be able to help get the syntax right (or determine the need for a separate type) using your actual stuff.

1 Like

Sorry @romanmg and @fayewatson, because this is a site for a client I’m trying to keep it private. From everything I can see there’s no way to create a rule giving access to a user if the current user has a common item in a list with a given user.

e.g. User 1 has a “role” attribute of coach, and has a “teams” attribute that includes team a and team b, user 2 has a “role” attribute of athlete, and has a “teams” attribute that includes team a and team c. I want the privacy rule to grant users with a role of coach access to users who have a role of athlete (which is simple enough) but who ALSO belong to one of the teams the coach belongs to.

Thanks for all of your help and sorry that I’m complicating things a bit by not sharing :slight_smile:

One way I think would work would be to create the data privacy role on the Team data type (instead of the User data type). For example, you could have a privacy role such as:

If a Coach has multiple teams, you can have a repeating group which does a search for Teams. Within the first cell of that repeating group, place another repeating group there (Type: Users, Data Source: Current cell’s Team’s Players). As long as you have the outer repeating group data type as Team (or page or group data type as Team) - this would make sure that Coaches can only view information on Users within their List of Teams (I think! :slight_smile: Let me know if this works for you.)

Then you can create another role for Players to view other Users also on their Team:

Thanks, that’s a great idea. That’s actually exactly how I have team access restricted for coaches right now.

The concern I still have is that even with this restriction these users could still have access to users they shouldn’t (if they manipulate things or play with the API, etc.). I’d really like to put privacy restrictions on users if at all possible.

Right, I wish I could be of more help but I’m not entirely sure of the best way to do this. As I understand it, the limit is that you can’t do “When Current User’s Role is “Coach” and Current User’s Team’s (list of Teams) Player’s (list of Users) contains This User” or any expression where it’s “Current User’s List of X’s List of Y’s contains This User” for creating a privacy role.

I’m sure you’ve thought of this, and it may be too repetitive, but you could create another field on the User data type called “Players” (Type: User, List: Yes). This way, only coaches would be able to view information on all of the Users stored within their Players field. Then remove the ability to view all of the fields/find in searches for Everyone Else (default permissions).

Yeah that’s the only way I can think of, but you’re right that there’d be some repetition there.

It’d be kind of tricky to maintain that list of players since administrators can freely change the teams a coach works with (adjust the coach’s teams field by adding or removing teams) which would need to kick off bulk changes to that players field. The reason I ultimately shied away from that approach was because removing a coach from a team would require the app to check which of the players on that team had no other common team with the coach, and only be removed from the coach’s players list if they didn’t. Doable but seems overly complex?

In your app, can a player belong to more than one team at a time?

Yes they can, which adds some complexity :slight_smile:

Indeed :slight_smile: If I can think of any other ideas I’ll definitely let you know!

Thanks so much!

Have you found a solution for this? I have a very similar need. I only want users to be able to view the profiles of users that are in the same group as them. Users can be in multiple groups.

Unfortunately no… still just scoping the views, and the data api provides stuff people shouldn’t have access to.

Bummer. I think I am going to put this off for a bit and work on general functionality until I am ready to publish.

I wonder if we could add a new list of users for each user called “Friends” or “teammates”, and then set the value of that list to equal a merger of the list of users of each team they belong to? Then in privacy we could just test whether This User’s Teammates contains Current User.

I don’t know how to set the value of teammates, though. Maybe something like “Teammates set list Current User’s Teams’ TeamMembers”?

I actually think this will work. I just need to figure out when to run the workflow to perform the “set list”. Maybe on user login. I think doing it on each page load is excessive.

This still isn’t ideal (it would be better if we could just write more complicated expressions in the Privacy tab), but at least it isn’t hard to maintain. Whenever the composition of a team changes, the list of friends with access to view all profile data will be updated upon the user’s next login.

Yep, that’s exactly what I was planning to do as a contingency plan. It’s pretty tedious to maintain, agreed that each page load is probably unnecessary. The other option is to just update the list every time a change takes place.

That’s a bit trickier but will involve a lot fewer extraneous calls.