FIX: Blocked tags were too aggressive (PR #11734)

In the context of tag synonyms, any tag that is a substring of the main tag is not listed as an available synonym. Removing the section of code in this PR fixes the issue, while not hindering the ability to block a tag.

Before

After

The blockedTags attribute is used in one other template (tag notification user preferences). Interestingly, in this context, the behavior appears correct both before and after the change.

It’s possible I’ve overlooked something, or there’s a better solution. Please let me know if so!

GitHub

This is odd. Is blockedTags not an array of strings? If it’s a CSV field or something I can see how this would fail. In that case a better fix would probably be to split the string, and then check the inclusion. @jjaffeux ?

It looks like the synonym tag chooser only blocks the primary tag. This is to make sure you don’t have a situations where a tag is a synonym of itself. This blocked value would be represented by a string according to:

So given that it’s a string, it looks like the includes here in the component file is interpreted as String.includes() instead of the Array.includes() it seems to expect:

Doing a split on the value before passing it as blockedTags seems like a good approach. Let me know if I should move to that direction. Curious to hear if Joffrey has any thoughts too!

I think the best here to make it clear for everyone would be to write tests with different cases of what you have as input and what you expect to get after

@tshenry can you make a TODO on dev for this, it looks like we need to write unit tests for this change. Just describe the problem with a repro and recommended fix, we can assign it out.

1 Like