Feature #14184


Centralized mechanism for storing Campus affiliations

Added by Boone Gorges about 3 years ago. Updated over 2 years ago.

Priority name:
Category name:
Public Portfolio
Target version:
Start date:
Due date:
% Done:


Estimated time:
Deployment actions:


User campus affiliation is currently determined in two ways.

1. We have an xprofile field called 'College'. For a few years, this field has only been available during registration, not for existing users editing their profiles.
2. Our Positions widget system stores college affiliation in the 'cacap_position_college' taxonomy.

When users update their Positions, that data is synced back to the xProfile College field, because the member directory College filter used to require the xProfile data. No syncing takes place in the other direction.

This means that, when we want to pull up a list of a user's campuses, or pull up a list of users affiliated with a campus, we have to cobble together a couple different types of information. In short, it's a mess.

Because campus affiliation is going to be a critical part of the way that the new homepage tools work (see especially #14181), this is a good time to clean things up a bit. I propose that we migrate away from using the xProfile field in favor of the taxonomy (which performs better and is better for handling multiple campus affiliations):

a. Stop using the College field during registration. Instead, show the same dropdown interface, but create a partially-filled Position based on this information. Users can clean this up manually, if they wish, after registration.
b. Migrate existing College data over to the cacap_positions_college taxonomy.
c. Stop referencing College when doing member directory searches, and rely solely on the taxonomy.
d. Build a wrapper for the taxonomy function that makes it easy to fetch a list of the user's campuses, and then use that wrapper where possible.

Related issues

Related to CUNY Academic Commons - Feature #14181: "Suggested" tool for members, groups, sitesResolvedRaymond Hoh2021-03-16

Actions #1

Updated by Boone Gorges about 3 years ago

  • Parent task set to #13998
Actions #2

Updated by Matt Gold about 3 years ago

this sounds like a good move!

Actions #3

Updated by Colin McDonald about 3 years ago

Sounds great to me too, especially if it helps with multiple campus affiliations. Would users still go about changing their affiliations in the same way post-registration, or would that change too?

Actions #4

Updated by Boone Gorges about 3 years ago

Nothing would change for users. Everything I'm proposing here is related to the way that data is stored and accessed behind the scenes. If you've got thoughts about user-facing changes, please feel free to share them and we can talk about feasibility.

Actions #5

Updated by Colin McDonald about 3 years ago

Ok, thanks for the clarification. I don't see anything on the user side worth changing right now.

Actions #6

Updated by Boone Gorges over 2 years ago

  • Related to Feature #14181: "Suggested" tool for members, groups, sites added
Actions #7

Updated by Boone Gorges over 2 years ago

  • Target version changed from 1.19.0 to Future release
Actions #8

Updated by Boone Gorges over 2 years ago

  • Parent task deleted (#13998)

Removing the #13998 parent.


Also available in: Atom PDF