Question

Photo of Ross Li

0

Person History of merged records showing hidden extended attribute values

We have created a few Extended Attribute fields that are meant to be for a small group of staff only (such as finance department). It works well in controlling who has view rights of the field on the person's profile, if we merge a person with a duplicate, every field that is moved from the merging profile is displayed in the Person History section with all the values listed in plain site. By default this category of person history Demographic Changes) is viewable by all Staff Workers. 

1) is there a way to limit who can see person history. If yes, is it possible to sub divide who can see what category of person history entries.

2) we have a plan to purge some of these sensitive extended attributes using work flows from time to time. However I am assuming the copy of these data in Person History will continue to remain, is there a way to delete data fields without it listing the field data in Person History?

Thanks

  • Photo of Jim Michael

    0

    You can limit who can see person history altogether by modifying the security on the various history blocks on the security tab of person details page.

    You can get a bit more granular by modifying the security of the History Categories under Admin | System Settings | History Categories, which all have child categories representing the different kind of history events and they can be secured separately. To meet your current need you would allow rights to the Person | Demographic Changes category (where attribute changes are stored) for only the role that needs to see those and denying the rights to that category for staff.

    I'm not aware of any way to "purge" history without resorting to SQL, though there could be some functionality I've missed. I am however going to ask the core devs why person attribute security is not honored in history  (why, if I have no view rights to an attribute, am I able to see that attribute's changes in history?) as I believe that would be the correct behavior and none of this would be an issue.

    • Knolly Shadrache

      Hi, has this issue been addressed at all please? we're applying the new General Data Protection Regulation to our Rock installation that we plan to go live with ahead of the regulation coming into force later this month

    • Jim Michael

      If you're referring to purging above, no.. Rock is not and does not claim to be GDPR compliant. You can't even delete a person record in Rock. The best you can do is merge a "person to be deleted" with an existing "Deleted person" record, then wipe out that person's history with a simple SQL command. But the person still technically exists (so things like linked finances won't be incorrect) and is just now merged into a conglomeration-of-deleted-people to obscure their data.