How to data privacy with 2nd degree database thing?

We want to setup a privacy rule where the user has to be a member of the team to which the ticket is related. So I was expecting to do: When do a search for team member where user = current user and topic = ticket’s topic >0

However, there is no do a search here. I can only make the rule directly related to the ticket or the current user.

How do we achieve the security config we’re looking for?

The rule should be: When This Ticket’s Team is Current User’s Team

(if you don’t already have a Team field on the Ticket datatype, then you’ll need to add one).

A user can belong to many teams. So it’s not as simple as User’s Team = Ticket’s Team.

We have Team Member entities that are the relationship between Team and User. Then The ticket is associated to a Team/Topic.

Hence we need to find whether the User is among the Do a Search for Team Members where Team = Ticket’s Team and User is Current User.

You can’t do searches in privacy rule conditions…

Privacy rules can only relate to the current user or to the object in question.

So you need to set up your database structure to suit.


Yup, what Adam said. So, you could add a teams field (list of teams) to the User data type, and then create a rule on the Ticket data type that says when Current User's teams contains This Ticket's team.


I see. It’s not the solution I hoped for. Thanks.

This is likely the best DB structure for the app even if you could configure privacy rules however you want… If you’re doing searches for something like this then it’s going to cost heaps of WU and run slowly.

Right I get it but roles and security are complex. In our app our tickets have various degrees of data visibility depending on the relationship of the current user with the ticket. We have various teams each with different roles within the team, we have ticket shares with guests who can view the ticket and all these are managed via related data tables. They’re not as simple as 1:1 relationship between current user and data thing.

So now I’m kind of trying to fit a round peg in a square hole. Let’s see if I can work that out.

Okay sure, what’s your current DB structure for handling tickets/visibility? We can try and work something out.

OK so we got:

  • Ticket
    • Domain
  • Ticket Attachment
    • Ticket
    • File
  • Team
  • Team Role
  • Team Member
    • Ticket Domain
    • Team Role
    • Team
    • User
  • Ticket Share
    • Guest User
    • Ticket


  1. Team Member User can view the Ticket data and if Current User is member of team related to ticket domain.
  2. Team Member User can view Ticket Attachment if Current User is member team related to Ticket Attachment’s Ticket’s Domain
  3. Guest User can view the Ticket data and if User Share is related to Ticket and Current User.
  4. Guest User can view Ticket Attachment if User Share is related to Current User and Ticket Attachment’s Ticket.
  5. If ticket is made publicly shared, all users can view ticket data and files.