1

Seeking to Apply Security to End Users on 'Analyze Further' option for discovery

 I am working on a discovery for a client-facing presentation that I want users to use the 'Analyze Further' feature to explore.

Within the matrix grid discovery, users have access to two rows of data: 1) a row corresponding to their unique logins and 2) a general aggregate row of all users' data.

To protect user anonymity, my team has implemented a background filter that only applies to the aggregate row and if the user creates a query such that the amount of observations forming the aggregate row is < 3 (For example: the user applies so many filters that only two non-aggregate rows of data match its criteria so data in the aggregate row is only comprised of two observations),  it will filter out the data.

The issue is that the users can easily turn off this background filter in the 'Analyze Further' screen in the Discovery. Is there a way for my team to lock this background filter on or maybe apply it to the discovery in a way that users cannot disable it, while still using the other parts of the 'Analyze Further' screen ? 

Added in post for additional context: 

 

We are already using row level security measures, exactly as recommended by the Pyramid team. It works perfectly. Our users, upon logging in, only have access to their own data and the aggregate data of all other users. 

What we want here is a way to limit the given aggregate row when queries are so specific that its data is essentially no longer anonymous.  Here is the PQL script we were using in the formula: 

if(([TABLE_A].[SMALL_CELL].CurrentMember)=([TABLE_A].[SMALL_CELL].[true]) &&([measures].[TABLE_A CLAIMCOUNT] <3),"Restricted",(AllMembers([TABLE_A].[SMALL_CELL]))  )

The CLAIMCOUNT measure serves the number of entries that form the aggregate column.  Is there a way to implement this formula into the Model's security measures ?

2 replies

null
    • Senior Director of Product
    • Ian_Macdonald
    • 3 days ago
    • Reported - view

    Hi 

    Rather than restricting the content based on calculated filters etc., where you need to restrict access to specific rows based on the user id, you should really be using the model security features that deliver row level security. In this way any one user can only ever see their own data and no amount of creative filtering will enable them to see any other users' data.

    Take a look at our Help on this topic. Member security can be driven explicitly, via a script, or dynamically using security tables. This is a much more robust mechanism and will allow full analytic freedom while preserving the security required.

    Hope that helps,

    Ian

      • Alexander_Khater
      • 3 days ago
      • Reported - view

      Hello   , I appreciate the prompt response. Let me elaborate more on our problem:

      We are already using row level security measures, exactly as recommended by the Pyramid team. It works perfectly. Our users, upon logging in, only have access to their own data and the aggregate data of all other users. 

      What we want here is a way to limit the given aggregate row when queries are so specific that its data is essentially no longer anonymous.  Here is the PQL script we were using in the formula: 

      if(([TABLE_A].[SMALL_CELL].CurrentMember)=([TABLE_A].[SMALL_CELL].[true]) &&([measures].[TABLE_A CLAIMCOUNT] <3),"Restricted",(AllMembers([TABLE_A].[SMALL_CELL]))  )

      The CLAIMCOUNT measure serves the number of entries that form the aggregate column.  Is there a way to implement this formula into the Model's security measures ? We have not been able to find a way, but we are also still learning Pyramid.

      Thanks! 

Login to reply

Content aside

  • 1 Likes
  • 2 days agoLast active
  • 2Replies
  • 30Views
  • 2 Following