Hello team, We detected an issue regarding user permissions (RLS) and calculated metrics in the workspace. Case: A user with RLS applied at CompanyID level (ID = 1036) when creating a new Insight and chooses to use a calculated metric he bypasses security and is able to see data from other CompanyID's and that shouldn't happen because we have CompanyID attribute spread across our datamodel. Calculated Metrics: Sum of Report Time to Submit = SELECT SUM(Report Time To Submit) Sum of Report Time to Approve= SELECT SUM(Report Time To Approve) Sum of Report Time to Control= SELECT SUM(Report Time To Control) Is it a requirement to filter the metrics by CompanyID? Example: Sum of Report Time to Submit = SELECT SUM(Report Time To Submit) BY Company Id

Hello Luis, It is bit difficult to assist you here without better knowledge of your model and actual User permission. Could you share with me and ID of affected user and link to the report in question, please? You can use DM for that.

PM sent. Thank you.

Hello Luis, I work alongside Ivana here, and we are looking into this. You are correct that you need to make the connection in the LDM with the BY clause. However in user permissions it is a bit different. You will want to use an OVER...TO clause. Please check out the provided doc here and let us know how you get on.

Hello @Joseph Heun, thanks for replying. Does this mean that a user with editor rights that can't create metrics bypass the row level security applied on the workspace. Imagine that we have data from multiple companies in a single workspace with user permissions to company A and another group of permissions to company B data. A user "A" (editor rights) will be able to see data from company B when creating a new metric if he doesn't apply the OVER..TO clause in the metric.

It doesn't have to do with how the user is creating the metric. It has to do with how you define the data permission itself. You need to use the over..to clause in the data permission definition; not the metric itself. If you have not applied the over...to clause then it is possible that the user could see data they are not supposed to

Hello @Joseph Heun, Getting back to this. So what's the difference between using LCM User Filter bricks and defining data permissions on the data model itself?

These are just two methods to accomplish the same thing. Essentially, using the User Filter Brick allows you to manage many users and filters at once. Whereas, managing them individually in the workspace would require a lot of manual work.

Ok, so thats the issue we are currently encountering. In this case we have an user filter permission applied (via LCM brick) to a specific CompanyID but that user can see data from other CompanyIDs when using a calculated metric and the permission seems to work if he uses a metric from the model.

I'm afraid I don't really understand the issue. You have applied the same user filter in a workspace, and also via user filter brick, but it doesn't work correctly when applied by the brick?

No, we only have the filter applied by the brick.

Then you will still need to write the user filter definition correctly using the over...to clause

But if both methods accomplish the same thing why do we have to use the over..to clause?

Indeed they do accomplish the same thing. You still need to define all of the data you are looking to exclude for the user. You are saying some datasets are not being included in the statement. to include those datasets, you need the over...to to make the connection and exclude the connections that you are looking to exclude.