Modernization: Termstore mapping model

[jansenbe]

Allow specifying a term mapping that can be applied during page transformation

[pkbullock]

Morning @jansenbe ,

I can look to build this?

I'm thinking in terms of spec:

• Mapping similar to user mapping/URL - using a csv of source and destination
• Mapping by TermId or TermName
• Terms follow Parent/Child e.g. TermSet/Term/ChildTerm or the way SP shows this when setting the show full path in column settings (cannot remember off top of head)
• On-Prem/Online support
• PowerShell script for TermSet replication between on-premises term store and online

Have i missed anything? Or was there something you envisaged in this feature?

[jansenbe]

Hey @pkbullock ,

Sure, would be great if you could work on this! I'm also able to spend some cycles on this, but feel free to own this feature.

Your list already is fairly complete, the only thing I was thinking of some kind of auto mapping which is on by default. Looking at your high level spec:

Mapping model

• Yes, let's use a CSV file format as with user and url mapping
• Mapping via Id and TermName is fine. TermName might not work in all cases as there can be duplicates but in those cases folks can use Id's. A sample file format would look like below, id mapping is simply 2 guids, path mapping requires specifying path with names

96c933ac-3698-44c7-9f4a-5fd17d71af9e,6142d2a0-63a5-4ba0-aede-d9fefca2c767
souregroup|sourcetermset|sourceterm|sourceterm,targetgroup|targettermset|targetterm 

Onprem vs Online

• Mapping should work for both on-prem and online
• Mapping only applies to cross site transformations

Auto mapping

If customers have already migrated their taxonomy data then they could have done this in 2 ways: they could have kept the same id's or they could have generated new id's. If the same id's are kept then we can automatically map source to target. The same applies for the same termgroup, termset and termnames....if we can find the needed term by following the "path" then we can auto map.

Term stores

For the source we either use the global termstore or the site collection termstore of the source site, for the target we do the same: global SPO termstore of the site collection termstore of the target site

Performance
Taxonomy API's are not the fastest, so it's important that we cache both source and target termset's whenever we encounter them the first time. As we can't cache SPO objects (so objects inheriting from ClientObject) I propose to cache as follows:

• Use a source and target Dictionary
• Key=Id, Value = Path (e.g. termgroup|termset|term)

TermSet replication tools

Having a script, or a pointer to an existing PnP PowerShell script for this would be nice.

[pkbullock]

Cool, sounds good, similar pattern as the other mapping features. 😊

[pkbullock]

@jansenbe I'm working through this one and plan for a another coding push tonight, but its not looking likely to be in the Feb release, is that an issue?

[jansenbe]

np, Feb release is almost out :-) Better to have this in early for the March release so we've a couple weeks test exposure. Thanks for the work on this!

[pkbullock]

@jansenbe for cases where the source taxonomy field is single and target tax field is set to allow multiple values, ill skip the field form transform and display warning in log. that ok?

[jansenbe]

Why would you do that? A single value can fit into a multi value field...the opposite flow however can pose a problem

[pkbullock]

lol brain to github comment fail... thanks for the feedback - i was thinking about multi to single, the potential data loss so will block and report back to user. You have highlighted another scenario i believe the code does not yet support is the single-to-multi, making sure that scenario is working.

[pkbullock]

Update to development on this, taxonomy mapping now working for publishing pages SPO cross-site and converted page from on-premise (2013), worked fine first time. I will look at enabling this for wiki/web part pages but should be quicker as the code is similar, then submit a PR soon aim for end of month.

[jansenbe]

Flagging this one as implemented now that the first PR got merged. Thanks a ton for the great work here @pkbullock !!