Project

General

Profile

Actions

Feature #18194

open

Migration routine for CVs

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

Status:
New
Priority name:
Normal
Assignee:
Category name:
CV
Target version:
Start date:
2023-05-09
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

When we introduce the new CV feature #17768 we will need to migrate over existing user data. Some initial thoughts for discussion:

- We should not create CVs for all existing users. How do we decide? I propose that we should only create them for users who have at least one "bottom" section filled in - Education, Positions, Publications, etc. Does anyone else have suggestions for how this should work?
- We'll have to build block markup using a pipeline like serialize_blocks(). This is likely to be subject to all sorts of issues with character encoding, etc, so we'll have to find some outlier profiles to use for testing. Ones with lots of fields built in, etc.
- Should old data - ie the BP profile data - be deleted or kept? It depends in part on whether we will continue to use the BP profile data. I'm thinking in part of directory search. If we do this, we'll need a mechanism in the regular CV save routine that syncs the relevant fields to BP's profile data system.

The migrator will have to be one of the last things built, since it'll depend on the specifics of the CV block implementation. See #18192, #18193.


Files

Social Icons.zip (6.6 KB) Social Icons.zip Sara Cannon, 2023-09-19 05:18 PM
Social Icons.zip (8.4 KB) Social Icons.zip Sara Cannon, 2023-09-19 06:04 PM

Related issues

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

Actions
Related to CUNY Academic Commons - Feature #18467: "Positions" migration to new CV editorNewBoone Gorges2023-07-17

Actions
Actions #1

Updated by Boone Gorges 5 months ago

Actions #2

Updated by Matt Gold 5 months ago

It would be good to discuss this at the team meeting, but I think your proposed metric ("at least one 'bottom' section filled in") is reasonable

Actions #3

Updated by Jeremy Felt 4 months ago

We'll have to build block markup using a pipeline like serialize_blocks(). This is likely to be subject to all sorts of issues with character encoding, etc, so we'll have to find some outlier profiles to use for testing.

Is any of the existing data in HTML? Dealing with arbitrary tags while importing into a block structure would be the most annoying.

Actions #4

Updated by Boone Gorges 4 months ago

Is any of the existing data in HTML? Dealing with arbitrary tags while importing into a block structure would be the most annoying.

Yes, though it's a pretty limited subset. Aside from inline elements like <em> and <a>, there are paragraphs and, IIRC, lists. So I don't think it'll be overly finicky to translate.

Actions #5

Updated by Boone Gorges 2 months ago

  • Related to Feature #18467: "Positions" migration to new CV editor added
Actions #6

Updated by Boone Gorges 11 days ago

Work-in-progress migration routine https://gist.github.com/boonebgorges/60467a056ec9f26a044ace3e4d52fdc9

It's not fully rigged up in that it doesn't yet create the CV post type, but this is trivial to add. I've run this with various types of profiles and it seems to handle most types of content pretty well.

Some outstanding issues, for my own reference:
- The following social-ish fields exist on the Commons but are not yet being migrated: ORCID ID, Google Scholar, Academia.edu, Delicious. We may want to scrap Delicious. The other three aren't natively supported by WordPress, so we need to write our own custom variations.
- A couple cac-cv-editor blocks aren't properly rendering for me. Not sure yet whether this is a bug in my migrator or in cac-cv-editor. These are: cv-last-active and cv-profile-navigation.
- When we come up with the placeholder text for various fields, I'll have to update the script.
- There's no logic built in yet for determining whether a user should in fact have a CV created, ie my suggestion that we create if a user has at least one "bottom" section.

Actions #7

Updated by Boone Gorges 11 days ago

Quick follow-up that I figured out non-rendering blocks. The block-renderer requests were 403ing, which was happening because no postId was being sent by ServerSideRender. I've added the necessary urlQueryArgs: https://github.com/cuny-academic-commons/cac/commit/956c123d765c73db2f7506224cf0ee11d286de59

Actions #8

Updated by Colin McDonald 6 days ago

Regarding the fields like Delicious to be scrapped, it seems that we never closed the loop on ticket #17018 and the data we pulled on how active these fields are. Here's the main takeaway:

I don't have the ability to determine when people added the data. As you'd probably guess, things like IM, Flickr, Delicious have been defunct for years, and all existing instances are probably ancient. Here are current raw numbers for each (again, out of ~39,000 user accounts):

- IM: 272
- Flickr ID: 227
- Delicious ID: 194
- ORCID ID: 152
- Google Scholar: 161
- Blog URL: 804
- I don't see an RSS field, but the Website field has: 2343

All of these except Blog URL and Website seem like candidates for removal to me. People could always add this info in a freeform block/field. But perhaps we can ask Luke/Matt/Laurie/etc on an upcoming call if things like ORCID and Google Scholar are particularly important in an academic setting to offer.

Actions #9

Updated by Sara Cannon 5 days ago

Ray - Here are some SVG's of social icons to refresh. Should we remove the IM, Flickr, and Delicious fields?

Actions #10

Updated by Boone Gorges 5 days ago

Sara, we're not going to remove anything for this interim release - it's a reskin only. We'll discuss whether and how to remove other fields as part of this ticket.

Actions #11

Updated by Sara Cannon 5 days ago

Sounds good. I've re-attached the zip file with the icons so it include those. (it was pretty funny trying to find a modern Instant Messenger icon)

Actions

Also available in: Atom PDF