Make it easier to update/audit the PDP rules associated with a page
I'm retrofitting a page to use PDP. It's pretty helpful for us and I expect that we'll add PDP policies to all, or nearly all, of our DataSets going forward.
I've got a page with ~40 cards and ?? DataSets behind them.
I'd like a way to quickly identify all of the DataSets used on a page.
I appreciated that a page is little more than a collection of cards and that it's the cards that are bound to the DataSet. That's okay, but it would sure be helpful report in my case. If there are 3, 5, 8 DataSets to review - I only know by checking each card individually right now. It's not impossible, it's just time-consuming and super easy to mess up. I'd rather not let data leak through on my watch...and it's hard to be certain.
A related way of thinking about this is to ask for an audit view of a page. What you would get is a listing of each card and what PDP policies are in in place for each. That would be a very helpful and reassuring view to have.
Thanks.
Comments
-
I'm back. I went back today to update some policies to assign access to a group rather than a user as that's easier to maintain. Unless I'm missing something PDP is going to be time-consuming and error-prone to maintain. I already found something I'd missed the first time through, and I'm hoping that I've missed more. Can anyone suggest best practices, features, or strategies to make PDP easier to do correctly and maintain easily.
At a start, here's what I'm looking at:
- Set up the data itself to make for simple filter rules. Ideally, each rule is a one-value match. This may mean including natural or synthentic grouping columns. Like a "Waseca" FacilityGroup for the FaciliyNames "Waseca North", "Waseca South" and "Waseca Main." Add a new FacilityName like "Waseca West"? It doesn't matter as long as the FacilityGroup policy is already in place for FacilityGroup = "Waseca"
- Assign policies to groups or roles (a user name tied to a role rather than a specific human) instead of users (a specific person) as much as possible.
- Make rules that are self-maintaining, like the FacilityGroup example above.
That's it so far. Comments and suggestions much appreciated!
0 - Set up the data itself to make for simple filter rules. Ideally, each rule is a one-value match. This may mean including natural or synthentic grouping columns. Like a "Waseca" FacilityGroup for the FaciliyNames "Waseca North", "Waseca South" and "Waseca Main." Add a new FacilityName like "Waseca West"? It doesn't matter as long as the FacilityGroup policy is already in place for FacilityGroup = "Waseca"
