Handle segmentation when segment alias includes underscore character(s) #19782
+32
−54
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ran into this one when working with segments in Engage - segmentation fails in the backoffice (ie split-view editing) when the segment alias includes underscore characters (which it does by default in Engage, and legacy uMarketingSuite installs, and by extension, in any segmented property data).
This is due to how string splits were handled in the various workspace elements when extracting culture and segment from the path:
See the issue? Splitting on
_
only works correctly whenfolderPart
contains a single_
. If the segment includes_
, we have incorrect segments:en-US_my-segment
=>en-US
,my-segment
💚en-US_my_segment
=>en-US
,my
🟥This PR changes the split handling and relocates some common code from different workspaces into the split view manager. There's a big chunk of duplication in these workspaces, around creating the split and single-view routes, but I've left that untouched (seems like an opportunity to add a
UmbContentDetailWorkspaceEditorBaseElement
or similar).Instead of splitting on
_
, we now find the first index of_
and take the corresponding sub-strings. I've moved the split handling into theUmbVariantId.FromString
function to ensure this can be reused easily.This does potentially change the culture in
handleVariantFolderPart
, where invariant cultures are now returned as null rather than 'invariant' - this is consistent with howUmbVariantId.FromString
has always worked, so I figured it's better to handle invariance consistently. When the resultantUmbVariantId
object is stringified, null cultures are set toinvariant
, so behaviour will not change from previous.Tangentially related, have also updated the preview app to show segment selector if any segments exist - previously this element only displayed if more than one segment, which meant documents with one segment could not switch to the segment from within the preview app (could preview from the backoffice only).