Centralized mechanism for storing Campus affiliations
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.
Updated by Boone Gorges over 1 year 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.