- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi,
The documentation is scant, but I understand from this post that access rules for data collected by PA uses the tab Access control on the indicator or or on breakdowns.
I have configured this both in my instance and in a PDI but there are no changes to what users can see in the [pa_scores_l1] table.
Clearing the cache or logging out didn't change anything either.
Am I misunderstanding something here, or is it not possible to filter out specific indicator scores on [pa_scores_l1]?
Regards,
Kim
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Thanks for the clarifications, I ended up creating a simple Deny Unless read-ACL for the Element field of [pa_scores_l1] with the data condition Indicator IS NOT <My indicator>. Will create a similar ACL for [pa_scores_l2] and that should take care of the problem.
Regards,
Kim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Kim,
The behavior you're seeing is expected. The Access Control configured on the PA indicator controls access to the indicator in Performance Analytics; it does not filter or remove the underlying records from pa_scores_l1.
pa_scores_l1 is the physical table where PA stores the collected scores. So, even if a user is not allowed to view a particular indicator through PA, the corresponding score records can still exist in pa_scores_l1.
Please test the restriction from the Performance Analytics UI instead:
- Open the indicator as the restricted user and verify whether it is available.
- Test the indicator in the relevant visualization/Analytics experience.
- If the restriction is based on a breakdown, configure the access control on the breakdown/breakdown elements as well.
The Access Control setting on the indicator is the supported way to control which roles can access an indicator.
So, if the requirement is specifically “don't allow this user to query/read certain rows directly from pa_scores_l1”, that is a different requirement from restricting the indicator in Performance Analytics. In that case, the indicator Access Control will not provide row-level filtering on the physical score table.
The post you referenced is useful here because it confirms that PA-collected data does not inherit ACLs from the underlying source tables and that indicator/breakdown access control should be used for PA access.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Kim,
Sachin's covered the split - adding the specifics I confirmed in my PDI.
Indicator visibility lives on pa_indicators_definition (role_override + roles). It gates the indicator inside PA surfaces, nothing else.
Breakdown elements aren't controlled there at all - that's the Elements Security List on the breakdown source (pa_dimensions.security_type / pa_dimensions_acl).
pa_scores_l1 is an ordinary table with its own ACLs - 75 pa_scores* ACL records ship OOB - so list and report access is plain ACL plus before-query business rule territory. That's exactly why the indicator setting never moved it.
If you need genuine row-level separation of the scores themselves, domain separation is the supported route.
If that answers it, could you mark it as the recommended solution? Helps me support these better for the community.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Thanks for the clarifications, I ended up creating a simple Deny Unless read-ACL for the Element field of [pa_scores_l1] with the data condition Indicator IS NOT <My indicator>. Will create a similar ACL for [pa_scores_l2] and that should take care of the problem.
Regards,
Kim
