Dynamic Filtering based on user permissions
I am trying to write some PDP policies. An example use case of my problem is that, all the users in my application have access to school names. Some users have access to multiple schools, while others have access to 1-2 schools. The schools these users have access to are defined on my backend. My DOMO dashbaord has a filter with a list of schools and I want each user to ONLY have access to their schools. I looked into
but I was wondering if I could get some more direction as to how I would implement it. How would I go about implementing something like this? Would I have to use writeback connectors based on which user logs into my application. Would this logic be more suitable on the frontend where the DOMO dashboard is being called or the backend where the access token is being sent? I have mulitple DOMO dashboards, and each have a filter for schools, so is there a way I can implement this globally?Best Answer
-
There are several ways to implement PDP scalably/programamtically. Can you help me understand the use case a little better, is the end product dashboards in Domo or an application (app) that is embedded somewhere? If its the former below are your best options:
- The easeist to use is the PDP Automation tool in Governance Toolkit (premium add on). This let's you provide a configuration file based on the backend logic usually using an ETL flow to create the output configuration. The file is formatted as a row for each user (user id or email) along with a list of pipe seperated values (schools) that they are able to see (see details here: )
- You can also use the API you linked to achieve this, basically creating a similar set of rules defining the schools the person can see but using User IDs rather than names. You can download user details from this endpoint: or export a governance report dataset. Then create rules for each user-shool as follows as follows:
{ "name": "filter_for_John", "filters": [ { "column": "School name", "values": [ "Highgate School" //if School name is Highgate School ], "operator": "BEGINS_WITH" //this is the operator suported for Strings }\ "There are several ways to implement PDP scalably/programamtically. Can you help me understand the use case a little better, is the end product dashboards in Domo or an application (app) that is embedded somewhere? If its the former below are your best options: The easeist to use is the PDP Automation tool in Governance Toolkit (premium add on). This let's you provide a configuration file based on the backend logic usually using an ETL flow to create the output configuration. The file is formatted as a row for each user (user id or email) along with a list of pipe seperated values (schools) that they are able to see (see details here: https://domo-support.domo.com/s/detail/ka05w000001230EAAQ?language=en_US)You can also use the API you linked to achieve this, basically creating a similar set of rules defining the schools the person can see but using User IDs rather than names. You can download user details from this endpoint: https://developer.domo.com/portal/n7f7swo7h29wg-user-api or export a governance report dataset. Then create rules for each user-shool as follows as follows: { "name": "filter_for_John", "filters": [ { "column": "School name", "values": [ "Highgate School" //if School name is Highgate School ], "operator": "BEGINS_WITH" //this is the operator suported for Strings }, "column": "School name", "values": [ "Highgate School" //if School name is Highgate School ], "operator": "BEGINS_WITH" //this is the operator suported for Strings } ], "users": [ 10416 ] //User ID for John } column": "School name", "values": [ "Highgate School" //if School name is Highgate School ], "operator": "BEGINS_WITH" //this is the operator suported for Strings } ], "users": [ 10416 ] //User ID for John }
0
Answers
-
There are several ways to implement PDP scalably/programamtically. Can you help me understand the use case a little better, is the end product dashboards in Domo or an application (app) that is embedded somewhere? If its the former below are your best options:
- The easeist to use is the PDP Automation tool in Governance Toolkit (premium add on). This let's you provide a configuration file based on the backend logic usually using an ETL flow to create the output configuration. The file is formatted as a row for each user (user id or email) along with a list of pipe seperated values (schools) that they are able to see (see details here: )
- You can also use the API you linked to achieve this, basically creating a similar set of rules defining the schools the person can see but using User IDs rather than names. You can download user details from this endpoint: or export a governance report dataset. Then create rules for each user-shool as follows as follows:
{ "name": "filter_for_John", "filters": [ { "column": "School name", "values": [ "Highgate School" //if School name is Highgate School ], "operator": "BEGINS_WITH" //this is the operator suported for Strings }\ "There are several ways to implement PDP scalably/programamtically. Can you help me understand the use case a little better, is the end product dashboards in Domo or an application (app) that is embedded somewhere? If its the former below are your best options: The easeist to use is the PDP Automation tool in Governance Toolkit (premium add on). This let's you provide a configuration file based on the backend logic usually using an ETL flow to create the output configuration. The file is formatted as a row for each user (user id or email) along with a list of pipe seperated values (schools) that they are able to see (see details here: https://domo-support.domo.com/s/detail/ka05w000001230EAAQ?language=en_US)You can also use the API you linked to achieve this, basically creating a similar set of rules defining the schools the person can see but using User IDs rather than names. You can download user details from this endpoint: https://developer.domo.com/portal/n7f7swo7h29wg-user-api or export a governance report dataset. Then create rules for each user-shool as follows as follows: { "name": "filter_for_John", "filters": [ { "column": "School name", "values": [ "Highgate School" //if School name is Highgate School ], "operator": "BEGINS_WITH" //this is the operator suported for Strings }, "column": "School name", "values": [ "Highgate School" //if School name is Highgate School ], "operator": "BEGINS_WITH" //this is the operator suported for Strings } ], "users": [ 10416 ] //User ID for John } column": "School name", "values": [ "Highgate School" //if School name is Highgate School ], "operator": "BEGINS_WITH" //this is the operator suported for Strings } ], "users": [ 10416 ] //User ID for John }
0 -
Sorry I didnt quite finish the answer:
The code for the API should look like:
[ { "name": "filter_for_John", "filters": [ { "column": "School name", "values": [ "Highgate School" //first School name is Highgate School ], "operator": "BEGINS_WITH", "not": false }, { "column": "School name", "values": [ "Another School Name" //second school ], "operator": "BEGINS_WITH", "not": false } ], "users": [ 10416 ] //User ID for John } ]
Once you apply PDP rules to each dataset powering the dashboards, all dashboards will filter for each user.
If on the other hand you are embedding there is a different approach to programmatically filter content per user. Does the above answer the question? Let me know if I misunderstood.
0
Categories
- All Categories
- 1.8K Product Ideas
- 1.8K Ideas Exchange
- 1.5K Connect
- 1.2K Connectors
- 300 Workbench
- 6 Cloud Amplifier
- 8 Federated
- 2.9K Transform
- 100 SQL DataFlows
- 616 Datasets
- 2.2K Magic ETL
- 3.9K Visualize
- 2.5K Charting
- 738 Beast Mode
- 57 App Studio
- 40 Variables
- 685 Automate
- 176 Apps
- 452 APIs & Domo Developer
- 47 Workflows
- 10 DomoAI
- 36 Predict
- 15 Jupyter Workspaces
- 21 R & Python Tiles
- 394 Distribute
- 113 Domo Everywhere
- 275 Scheduled Reports
- 6 Software Integrations
- 124 Manage
- 121 Governance & Security
- 8 Domo Community Gallery
- 38 Product Releases
- 10 Domo University
- 5.4K Community Forums
- 40 Getting Started
- 30 Community Member Introductions
- 108 Community Announcements
- 4.8K Archive