Feature #18467


"Positions" migration to new CV editor

Added by Boone Gorges 5 months ago. Updated 8 days ago.

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


Estimated time:
Deployment actions:

Deactivate cacap-cac and cac-advanced-profiles


Breaking this off from the primary tickets (#18194, #18193, #17768) to keep the conversation organized.

"Positions" is a variant of the cac/cv-row block, but it needs special logic to account for the three dropdowns (Campus, Department, Title), the way that information is formatted on the front end, syncing with user taxonomies, autocomplete, etc.


Peek 2023-07-17 10-52.gif (399 KB) Peek 2023-07-17 10-52.gif Boone Gorges, 2023-07-17 12:53 PM

Related issues

Related to CUNY Academic Commons - Feature #18194: Migration routine for CVsNewBoone Gorges2023-05-09

Related to CUNY Academic Commons - Feature #18193: CV "bottom" sectionNewBoone Gorges2023-05-09

Related to CUNY Academic Commons - Feature #17768: CV Editing and PublishingNewJeremy Felt2023-03-04

Actions #1

Updated by Boone Gorges 5 months ago

Actions #2

Updated by Boone Gorges 5 months ago

Actions #3

Updated by Boone Gorges 5 months ago

Actions #4

Updated by Boone Gorges 5 months ago

A first pass at this feature is ready in Some implementation notes:

1. We store College, Department, Title values in taxonomies. The main purpose for this is to power the autosuggest feature. Previously, these were defined in the cacap-cac plugin, but I've moved them into cac-cv-editor/includes/taxonomy/index.php. Jeremy, feel free to move this around if you think it's appropriate elsewhere.

2. The Campus dropdown is powered by a global JS variable CACCampusData defined in a wp_add_inline_script() call. I didn't see a need to use an AJAX call to get this static data, and I didn't know of a better way to provide it within the context of the block editor. Jeremy, if you have ideas about how this might be improved, feel free to suggest them.

3. As mentioned above, we have autosuggest/autocomplete for the Department and Title dropdown. IIRC we originally built this so that we wouldn't end up with a half-dozen misspellings of "Political Science" etc. I built a little component TaxonomyTermSearchController that powers the search, including logic for debouncing multiple requests and so forth. I'm flagging it here because WP doesn't really have anything out of the box that can be used for this, and it could be useful elsewhere in the future.

4. I didn't do much with the styling, because I'm unsure how much work Jeremy has done with the general styling of CV rows. Sara's mockups have a two-column display (title at left in bold, content at right) but I don't see this in the current working branch. Yet I could swear I saw it once, so it's possible that I'm not running the build correctly or something.

5. I added two new blocks, cac/cv-positions and cac/cv-position. Then I changed the default `innerBlocks` of the `positions` cac/cv-row variant so that it has a single `cac/cv-positions` block. I think this is the best approach, but Jeremy, I'd welcome your feedback if there's a better way to set this up.

A gif is attached that shows how the Positions block works.

Actions #5

Updated by Boone Gorges 5 months ago

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

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?

Actions #6

Updated by Colin McDonald 4 months ago

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.

Actions #7

Updated by Boone Gorges 4 months ago

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
    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:
    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

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.

Actions #8

Updated by Boone Gorges about 2 months ago

  • Target version changed from 2.2.0 to 2.3.0
Actions #9

Updated by Boone Gorges 8 days ago

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.


Also available in: Atom PDF