S24 privacy combined profile

[jsenning]

This PR replaces #2031 and is linked to PR gordon-cs/gordon-360-api#1060 in the API repo.

@ArabellaJi began working on this in 2023 and did most of the heavy lifting. She began with the intention of giving FacStaff a mechanism to optionally display their mobile phone number. This then expanded to provide privacy controls for other items on the FacStaff personal profile. Before she handed it off at the start of the summer, she had also expanded her work so that student data (currently mobile phone and home address) used the same mechanisms.

In the past weeks we have continued this work to more completely integrate the new privacy settings and adjusting profile view models to allow individual profile elements have individual boolean values to indicate the user has requested they be private. Doing this meant that many of the profile fields have changed from strings to objects that contain a string and a privacy flag. For example, in both the UI and API the mobile phone field is now has type ProfileItem that is a class with two fields value and isPrivate. The value field is the string representing the phone number, and the isPrivate field is a boolean that is true if the should be treated as confidential (and shown in red). Of course, data the viewing user is not allowed to see is not sent from the API, so the isPrivate field being true means that the viewing user is authorized to see the information but the color reminds them that the information is restricted and should be treated as such.

This change deprecates the use of the "KeepPrivate" profile field for faculty staff accounts and the "isMobilePhonePrivate" field for student accounts (although one outstanding issue is the need to ensure that student mobile phone privacy settings here are appropriately reflected in the Jenzabar database.)

Some profile information still use other types of privacy controls. One example is Clifton Strengths (although this might be an easy fix). Another is the privacy settings for alumni. We hope that in the near future these can be modified to use the new privacy settings.

[jsenning]

July 3, 2025 -

Concerns: Our privacy system is fragile. The way privacy is handled depends on both the class of the viewer and the class of the user whose data is being requested. Values that are stored in the database are also hardcoded (e.g. a KeepPrivate value of 'Y' or the visibility group 'FacStaff'). With this PR most privacy restrictions are applied during the construction of the user's profile, but how that profile data is used (e.g. during user searches) is handled in different parts of the API code.

Prior to the changes in this PR data privacy is handled differently for each class of user (student, facstaff, and alumni):

• students have a KeepPrivate flag (we believe this is for FERPA protected students). This flag is either 'Y' or 'P' if the student should not be shown in the directory or search and no profile information will be shown.
• faculty-staff also have a KeepPrivate flag that is either '0' or '1'. A '1' indicates that personal information (phone number, address, etc.) will not be shown but does not prevent the user from showing up in the directory and their campus location and contact information is still shown.
• alumni have ShareName and ShareAddress flags which are either 'Y', 'N', or null. Alumni will show up in search results if ShareName is 'Y' or null. Alumni with ShareAddress set to 'N' will not be included in searches specifying a specific home city.

The changes introduced in this PR provide additional flexibility for users with access to 360 (which excludes most alumni).

• The student FERPA KeepPrivate flag continues to be honored for students independently of any user chosen privacy settings. Personal data that students mark 'Private' is hidden from other student but still visible to authorized users. For example, faculty-staff can see mobile phone numbers.
• The faculty-staff KeepPrivate flag is used when the user has not made any privacy settings in 360. Any privacy settings made by the user will be used instead of KeepPrivate.
• Faculty-staff have the option of making some personal data 'Private' (hidden from students and other faculty-staff), 'FacStaff' (hidden from students but visible to other faculty-staff), or 'Public' (visible to all 360 users).
• As was previously the case, certain authorized users can see data that is not public, but this data is marked as being private or otherwise restricted.

[russtuck]

Since this PR isn't trying to modify quick search, I'm concerned that this might be undoing an old fix. I'd feel better not changing this file, unless we know of a reason.

[jsenning]

I agree with you. I have no idea why this is in the PR!