Data access within a client/org
28 April, 2016
Each of our clients run a series of events/conferences. Some of the people who will work on the individual events/conferences should not have access to all of the events running in the system, and therefore should only be able to create and view reports that are relative to the events they have access to. Right now we separate the data from one client to another using the client reference code. We could do the same for events and groups of events, but that would require us to have a much higher client/org allotment in the license. Is there a different way to handle this and segregate data access? We can put additional conditions in our view to filter down by event, but how can you dynamically control the value passed into the condition based on the logged in user. Up to now we have only been able to do this with the client reference code.
Hi Travis,
unless I've misunderstood your scenario, it sounds to me like you should be using the Yellowfin feature for row-level security called Source Access Filters.
Please read through the above wiki page and see if that doesn't meet your requirements.
regards,
Dave
unless I've misunderstood your scenario, it sounds to me like you should be using the Yellowfin feature for row-level security called Source Access Filters.
Please read through the above wiki page and see if that doesn't meet your requirements.
regards,
Dave
This looks like it is close to the right functionality, but I think we need it to be a little broader. Many of our users will also be creating reports and we would like to limit the data they see not just when running a report but also when creating a new report. In addition, the person may switch between the data groups they are working on. Here is a use case:
Person A is working on Project A in our system, clicks to the embedded yellowfin instance, we want to only allow reporting on project A.
Person A later comes in and is working on project B, clicks to the embedded yellowfin instance, we want to only allow reporting on project B.
Through the APIs and SSO right now we are able to set the person's client org and restrict data access that way and would like to do something similar. We have some users that have access to multiple client orgs and they choose the org they are working on in our software and we pass that in when they go into Yellowfin. We are looking for the same type of functionality for the projects underneath a client org where we can pass in the client org and pass in the project and tie that to some data restrictions in Yellowfin. In my reading of the source filters, it doesn't seem like it has all the capability we need to do this but I may be wrong. Thanks!
Person A is working on Project A in our system, clicks to the embedded yellowfin instance, we want to only allow reporting on project A.
Person A later comes in and is working on project B, clicks to the embedded yellowfin instance, we want to only allow reporting on project B.
Through the APIs and SSO right now we are able to set the person's client org and restrict data access that way and would like to do something similar. We have some users that have access to multiple client orgs and they choose the org they are working on in our software and we pass that in when they go into Yellowfin. We are looking for the same type of functionality for the projects underneath a client org where we can pass in the client org and pass in the project and tie that to some data restrictions in Yellowfin. In my reading of the source filters, it doesn't seem like it has all the capability we need to do this but I may be wrong. Thanks!
Hi Travis apologies for the delayed response.
It does sound like you need a client ref source filter (so this is a source filter that is automatically applied and cannot be turned off on the report), and then a separate source filter, which would be your 2nd layer of security.
E.g. Client ref id = Company Name
Source filter 2 = State code
So each client only sees the data relating to that company , and then different users will have different values for their state filters.
Tf you would like this to apply to the report data page also, you need to ensure that the source filters are set up as default filters at the view level, and the user does NOT have the role 'Access Filter' ticked. This is will ensure that all reports based on that view will have both source filters applied and that they cannot turn it off.
I hope this makes sense and gives you what you were after!
If not, please let me know.
Thanks,
David
It does sound like you need a client ref source filter (so this is a source filter that is automatically applied and cannot be turned off on the report), and then a separate source filter, which would be your 2nd layer of security.
E.g. Client ref id = Company Name
Source filter 2 = State code
So each client only sees the data relating to that company , and then different users will have different values for their state filters.
Tf you would like this to apply to the report data page also, you need to ensure that the source filters are set up as default filters at the view level, and the user does NOT have the role 'Access Filter' ticked. This is will ensure that all reports based on that view will have both source filters applied and that they cannot turn it off.
I hope this makes sense and gives you what you were after!
If not, please let me know.
Thanks,
David
