Possible UI bug? Mapped variables shown are different from actual mapping.

[leejon]

How it shows up as a preview:

What's actually mapped when you click into it:

Anyone else experienced this before or is it a fluke?

[UnknownJ]

Yeah, we had something like this happen to us too..

@adrian_browning fixed it for us, with the following script run in the console:

var map = utui.data.manage[1].map;
for (var mapId in utui.data.manage[1].map) {
  var mapObj = utui.data.manage[1].map[mapId];
  if (!utui.data.manage[1].map.hasOwnProperty(mapId)) {continue;}
  if (!mapObj.dsID) {continue;}
  var result = _.where(utui.data.define,{name : mapObj.key, type : mapObj.type});
  if (result.length === 0) {continue;}
  [result] = result;
  if (mapObj.dsID === result._id) {continue;}
  
  
  mapObj.dsID = result._id;
  console.log(mapId, mapObj.dsID,mapObj.key, result._id,result.name);
}

[mitchellt]

This is really interesting @UnknownJ - more discussion would be great, as well as commentary from Tealium folks.

[UnknownJ]

I can't rule out having caused our corruption in the first place - one of our team had gone through creating and mapping like 100 data items as Page JS Variables instead of UDO Variables, so I ran an update to utui.data.define to change the types of everything (as opposed to deleting, recreating, and then remapping), and it was after that that I first saw the issue...

In terms of what that code does, for the curious, I believe it iterates over tag ID 1's mapping, excluding keys that fail a hasOwnProperty check, excluding relationships that don't have a dsID (data source ID?), and then for each entry checks the UDO definition for the variable mentioned in the mapping. If the data source ID in the mapping object matches the corresponding UDO variable ID, then it skips the rest of the loop. If not then it updates the data source ID in the mapping to the ID for that variable in the UDO.

So my assumption is that the mapping object within the tag correctly identifies the variable name (so when published, it comes out correctly) but gets its source ID corrupted, and the UI is powered by a lookup on that ID rather than the name, which is why the UI doesn't match either the intended mapping, nor the published output.

In my experience, mismatched IDs have tended to be the result of issues with library inheritance, but at this point it's all just idle speculation.. :o)