CUNY Academic Commons

I realized that the old Positions system was used in places on the home page as well as during registration. Thus my most recent changes were triggering some fatals. I've worked around them in https://github.com/cuny-academic-commons/cac/commit/94455b7441fdfdeb4e75abbfbb13f9c289393bc3.

This is a good opportunity for us to rethink the way that the College/Campus field is used throughout the Commons. An overview of where things stand:

- Originally, 'College' was a profile field that was required during registration. At the time, I believe it was a multiselect field.
- When we introduced Positions, we removed College from public profiles. The thinking was that Positions subsumed College.
- We continued to ask for College during registration, but in the background, this was actually created a Position.
- When we needed to pull a user's College affiliation in other places on the site, we first tried to get it out of Positions. Then, we looked in the legacy College xProfile field.

In the new system, we will continue to have Positions. But they'll be part of the CV, which is optional and is thus somewhat different from the existing Public Portfolio, which everyone has. So we should take a bit of time to talk through the following:

a. What are we using College for?
b. Is it necessary that every user be affiliated with a College?
c. Should it be possible for a user to affiliate with more than one College?
d. Should College be independent of Positions?

In the spirit of the independence of CVs, I wonder if perhaps this is a good time to rethink the way that Positions and College interact. Perhaps we should have a separate College field on the Commons Profile, which would appear during registration and would be required for all users. We'd use this in directories when we need to show college affiliation. The Positions section of the CV would be totally separate, and would just be for display on the CV. (This naively makes sense: someone might be associated with a few campuses at CUNY, but only want a subset of them to appear on the CV.) What do others think?

Thanks for thinking through all of this and writing it out so clearly, Boone. I agree that separating the CV Positions section from the way College is used elsewhere on the site makes sense, both for improving usability and our own technical complexity. The required College (or Campus? or College/Campus? not sure of the best CUNY nomenclature) field during registration would power the directories and other places where we show an affiliation. Then the separate CV area for Positions that show a college/colleges wouldn't need to be tied back, and would be voluntary like the rest of the CV.

I suppose the real issue from here could be untangling the data we're currently using for those directories, but at least it will be more clean for new signups.

Thanks, Colin. Based on this, here's a proposed path forward:

1. The Positions widget will be displayed and editable only on the CV. No Positions information will be collected during registration.
2. We will create a new standardized way of storing each user's Campus affiliations
  a. We'll use a user taxonomy, which will speed up queries around the site, and make it easier for users to have more than one campus affiliation
    i. The use of a user taxonomy will require us to rework the way that the Campus filter works at https://commons.gc.cuny.edu
    ii. Because in the past we've had to deal with changes to campus names, we will likely not use the 'name' field from the taxonomy tables when displaying campus affiliations around the site. Instead, the taxonomy system will use the immutable campus slug/key from cac_get_cuny_campuses(), and we'll use the centralized strings at cac_get_cuny_campuses() for display purposes.
    iii. The function cac_get_user_campuses() will need to be rewritten to pull data from the new location: https://github.com/cuny-academic-commons/cac/blob/5d784ab321f53011e5ad5b50f73977557fed5592/wp-content/mu-plugins/cac-functions.php#L3750.
    iv. There may be other places where internal refactoring is required. For example, cac_get_user_ids_matching_college_xprofile_field() and the corresponding 'positions' function would probably no longer be needed, or would need to be rewritten.
  b. A new Campus field will be introduced during registration and user edit.
    i. The field will be powered by Select2 or similar to allow for multiple selections
    ii. When editing your profile, the Campus field must appear outside the CV. Probably in the same place where you edit your Full Name.
    iii. This will be a required field. To accommodate non-CUNY members, we could have a 'non-CUNY' or 'none' option.
3. When we roll out the new CV system, we'll migrate existing users into the new Campus system
  a. Positions taxonomy data will remain untouched.
  b. cac/cv-position blocks will be generated as part of the more general block-migration routine #18194
  c. Each user on the site will have Campus data migrated to the new taxonomy system using the same logic found at https://github.com/cuny-academic-commons/cac/blob/5d784ab321f53011e5ad5b50f73977557fed5592/wp-content/mu-plugins/cac-functions.php#L3750

Another change I propose, which I suppose would be (2)(c) above, is that we should display this new Campus data somewhere on the user's Commons Profile. Currently, we don't really display a user's campus affiliation in an obvious way because it would be redundant with Positions, but I think this reasoning changes with the proposed changes. I break this out because I don't have a clear idea of how or where this information should appear on the user's Commons profile/header. Maybe Sara or others has an idea.

I've made changes so that you can now do free-entry text into any of the College, Department, or Title fields, with the autocomplete serving as suggestions that can be selected, but can also be ignored in favor of your custom text.

I also added a bit of interface so that it's clearer what to do when you don't yet have any Positions entered, as when you're creating a new CV.