Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

History does not honor Group Security when someone is added to a group #5332

Closed
1 task done
atamburino opened this issue Mar 3, 2023 · 3 comments
Closed
1 task done
Labels
Fixed in v16.1 Type: Bug Confirmed bugs or reports that are very likely to be bugs.

Comments

@atamburino
Copy link

atamburino commented Mar 3, 2023

Please go through all the tasks below

  • Check this box only after you have successfully completed both the above tasks

Please provide a brief description of the problem. Please do not forget to attach the relevant screenshots from your side.

Similar to #5043 & #5043.

When viewing the attendance history for a person, if they have been added to that the current user is not authorized to view, they can still see that the user was added to that group. This is a sensitive issue for people who may be attending a recovery-type group or other care-focused groups.

image

Expected Behavior

Because the member we impersonate is not in the Rock Administration role, they should not see that the new member was added to the care/recovery group.

Actual Behavior

The none admin can see that the new member was added to a recovery/care group.

Steps to Reproduce

  1. Go to a site running Rock McKinley 14.1 (1.14.1.1).
  2. Create a new member and add them to a group that has a security set where only an admin security role can view."
  3. Impersonate any other member that can see the history section on a person's profile page but not the group
  4. As this person, view the history tab on the new member you created on step 3's profile

Rock Version

Rock McKinley 14.1 (1.14.1.1)

Client Culture Setting

Client Culture Setting: en-US

@bobrufenacht
Copy link
Contributor

Note that this issue is not just a duplicate of #5043. The issue remains for Group Security but it is also an issue with Attendance as attendance in those groups may be displayed as well.

@sparkdevnetwork-service sparkdevnetwork-service added the Type: Bug Confirmed bugs or reports that are very likely to be bugs. label Apr 27, 2023
@sparkdevnetwork-service sparkdevnetwork-service added the Status: In Dev Queue This issue is being worked on, and has someone assigned. label Oct 17, 2023
@Kwame-Agyei Kwame-Agyei added Fixed in v16.1 and removed Status: In Dev Queue This issue is being worked on, and has someone assigned. labels Nov 14, 2023
@tpeera
Copy link

tpeera commented Mar 15, 2024

@Kwame-Agyei would a practical work around for earlier versions prior to v16.1 be to use the Person History block under the category CRM > Person Detail? (and then secure the History Log block until v16.1)

@Kwame-Agyei
Copy link
Collaborator

Hello @tpeera,

Well, the PersonHistory block is now considered outdated and hasn't been updated for quite some time. It basically serves the same function as the HistoryLog block on the Person history page, but there's a chance it might have bugs. If you plan to switch to it, we would advise you to make sure to set a reminder to remove or replace the block once you upgrade to v16.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fixed in v16.1 Type: Bug Confirmed bugs or reports that are very likely to be bugs.
Projects
None yet
Development

No branches or pull requests

5 participants