Duplicate selected IDs appearing in raw value of checklist field after deleting an item and linking to other (already selected) item

Question

I ran into an issue when cleaning up two pairs of items like so:

• Parent item
  • Reference Item 1
  • Similar Reference Item 1 [delete and relink to Reference Item 1]
  • Reference Item 2
  • Similar Reference Item 2 [delete and relink to Reference Item 2]

The above items are part of a list of items which are used as options for a checklist field; specifically, a list of timezone items which are the source for a checklist field on an event item.

Prior to the cleanup, I had an event item that had all of the timezone options selected. The image below is what that checklist field looks like after performing the cleanup. Notice how the last two options say [Not in the selection List] and that they are already selected as the 3rd and 4th options. After inspecting the raw value of the field, I can see that those two IDs are in fact selected twice. Normally, the UI wouldn't let you selected the same option twice in a multilist-type field, so this is a problem:

It seems that relinking during item deletion does not take into account if the field we are updating is already also referencing the item that we are relinking to.

That is, prior to the cleanup, the event would have had these options selected in the checklist field:

• Reference Item 1
• Similar Reference Item 1
• Reference Item 2
• Similar Reference Item 2

And after performing the relinks, we wound up with this:

• Reference Item 1
• Reference Item 1
• Reference Item 2
• Reference Item 2

Note that I don't have the option of removing the breaking links (instead of updating) during deletion because it's not always guaranteed that event items will be referencing both items in a set. Whether an event was previously linking to one or both of the options in the set, it always needs to result in there being a single link to the remaining item, e.g. when Reference Item 1 or Similar Reference Item 1 or both are selected, the end result should be that Reference Item 1 is the only selected option.

Does Sitecore not take this scenario into account when relinking? I can understand why it wouldn't, because Sitecore can't make assumptions about what the order of the selected options should be. If merging two IDs into one, which one should be removed? That's not Sitecore's call. Therefore, it keeps both in their respective places and simply updates the ID(s). Then again, in the case of a checklist field, the selected options aren't able to be re-ordered like a true multilist field, so I wouldn't expect to see this problem for checklist fields.

Further, if this observation is correct, isn't the implication that we should be performing a uniqueness check whenever we enumerate multilist-type fields?

What are my options? It seems that the instances of the issue would need to be resolved case by case or via a script. Either way, it would have been helpful if a dialog box warned me that this was going to happen.

Answer 1

Unfortunately the answer to your question is "No, Sitecore did not take this scenario into account".

If you look at the Sitecore.Data.Fields.DelimitedField field class, Relink method simply replaces original item ID with new item ID:

public override void Relink(ItemLink itemLink, Sitecore.Data.Items.Item newLink)
{
  string str = itemLink.TargetItemID.ToString();
  if (!this.Contains(str))
    return;
  this.Replace(str, newLink.ID.ToString());
}

It doesn't check for duplicates.

I think the warning message in the popup before relinking could be helpful but could be also confusing for content authors.

In theory nothing stops you from creating your own class inheriting from Sitecore.Data.Fields.MultilistField and overriding method

public override void Relink(ItemLink itemLink, Sitecore.Data.Items.Item newLink)

checking for uniqueness and applying the logic you want there. And then registering instead of

<fieldType name="Checklist" type="Sitecore.Data.Fields.MultilistField,Sitecore.Kernel" resizable="true"/>

your own field type implementation

<fieldType name="Checklist" type="MyAssembly.MyNamespace.MyCustomChecklistField,MyAssembly" resizable="true"/>

But I haven't heard about anyone who had done it so you would have to be really careful and thorough while testing if nothing was broken with that change.