Handle private students in involvement membership and requests

[EjPlatzer]

Students who are private (have a value 'P' in the KeepPrivate column of CCT.dbo.Student) are not visible to other students on 360. Private students won't appear in searches made by other students, and trying to navigate to a private students profile as a student returns a 404 Profile Not Found. Faculty and Staff are still able to see such students, but they are shown privacy disclaimers. When a FacStaff person views a private student's profile, the student's personal info is marked with a red disclaimer specifying that the student's info is private and not visible to other students.

However, when such a private student joins involvements, their visibility is increased in at least two ways, which may constitute a violation of their expected privacy:

1. We currently show private students who are members of an involvement to other members of that involvement, both students and FacStaff. This is inconsistent with private students being hidden from other students across the site otherwise. There is a question of whether involvements are a trusted and known group that students are okay being visible with (since only members of the group can see other members). However, this decision should be left up to the student, and we ought to default to not exposing them at all. The solution seems to therefore be two-fold:

   1. ASAP, filter the list of group members so that students marked as private are not shown to other students. They can still be seen by super admins and FacStaff group members, but there should be a clear visual indicator (similar to the one on PublicProfile) that FacStaff are seeing privileged, private information that should not be shared.

   2. Potentially allow students to make themselves visible to the group if they so choose.

2. When a private student requests to join an involvement, their membership request is visible to all group admins of the involvement they requested to join, including other students who are group admins. This is an issue because a student who asks to join an involvement currently has no way of knowing that they will be made visible, much less to whom. There are two obvious solutions, but there may be other, better ways:

   1. One solution would be to only show membership requests from private students to Faculty/Staff. However, in some cases, the student leaders are the only ones actively administering an involvement. In such cases, this approach would risk hiding the private students request such that they are never able to join certain involvements.

   2. Another solution is to allow student leaders to see requests from private students, and warn private students ahead of time that this is the case. For example, when a private student requests to join a membership, they would be shown a dialog informing them that submitting their request may show their name and email to the group leaders, including [list of student group admins]. They would have to confirm that they understand and are okay with that before their request is submitted. If they decide they aren't comfortable with that, they could email the group's FacStaff advisor or 360@gordon.edu and directly request to be added. This way, the student is informed and in control of their own privacy.

[EjPlatzer]

Notes from Team Meeting, 2022-10-18

Privacy Levels

Students have three privacy levels currently:

1. Not Private (default)
2. "Semi-Private" (KeepPrivate = 'S')
3. "Private"/"Protected" (KeepPrivate = 'P')

Of those three categories, only the third is impacted by Involvement membership (semi-private students have some sensitive info protected, but none of it is shared through the involvements system).

Private/Protected students are expected to have even their directory info (name, mailbox#, etc.) hidden. This means that even showing their name or photo to students is unacceptable.

We have not yet decided how best to enable private students to access involvements without breaking their privacy expectations - see Open Questions below. But, we have identified some immediately actionable steps to take in the meantime.

Action Steps

1. Warn private students when they are requesting to join (or subscribing to) an involvement. This will not solve the issues detailed above, but will at least make the system more transparent and give the user more agency immediately in how their data is protected. When a Private/Protected student subscribes or requests to join an involvement, we should show them a disclaimer that doing so will reveal their name (and currently photo, mailbox number) and participation level to the leaders/ other members of that involvement. The user will have to confirm that they understand that before we process their request. We might include a note about emailing the involvement FacStaff advisor directly to request membership, as an alternative option.
2. Redact least necessary info from Involvement roster. Currently, every member of an involvement has their photo, name, participation, and mailbox number shown on the Involvement Roster to other members. At the very least, we can remove the mailbox number and photo of Private/Protected students from this view. We might also consider obfuscating their name and participation to all but group admins.

Open Questions

1. Are we legally allowed to let a Private/Protected student knowingly and purposefully lessen their privacy in our system - e.g. by requesting to join an involvement, making their info visible on a roster, etc.?
2. Should Group Admins be able to add Private/Protected students to their involvement?

[bennettforkner]

@sharonpatta is going to take care of solution # 1-i from the description:

ASAP, filter the list of group members so that students marked as private are not shown to other students. They can still be seen by super admins and FacStaff group members, but there should be a clear visual indicator (similar to the one on PublicProfile) that FacStaff are seeing privileged, private information that should not be shared.

I would say that the first step could just be to not show them to anyone except themselves (and maybe site admins). That would be a simple first step that would comply with the privacy aspect, then we can address what would be nice to have.

[bennettforkner]

I have prevented "private" users from appearing in involvements by filtering the "MembershipsView" in the database.

[bennettforkner]

In assigning myself as I have completed the first step but do not have intentions on going further as of yet.