1 person found this helpful
Interesting - at first glance this sounds like a DayCare ticket I opened up a year ago. Ticket #31878 for anyone from DayCare reading this. We were given a (custom?) fix pack named tag-merge-backlinks-bug36257-2.0.zip (I assume the #36257 is for internal JIRA/Bugzilla tracking, since it is unrelated to the DayCare ticket number). There were also two assurances in the DayCare ticket that this would be fixed in CQ v5.5, so I'm kind of shocked that you're seeing the issue in AEM v5.6 (we're still on v5.4, as well). I suppose it is possible that we're actually talking about different issues, but it sounds VERY similar. Perhaps it was accidentally reintroduced in v5.6?
Be warned, if you get this fix pack, there was another issue introduced which was that tag admins can still see the merged/hidden tag in the left-hand tree view and if they attempt to delete the hidden tag, it will delete the tag it was merged into. We opened another DayCare ticket for this (DayCare #33302, which apparently corresponded to JIRA/Bugzilla tracking #35194), and got another custom fix pack named Move_MergeTag-1.0.zip - and the DayCare ticket contained an assurance that this was fixed in CQ v5.5, as well.
Good luck getting this sorted out, but I think you're going to need to submit a DayCare ticket to get the patches.
I'd appreciate hearing back from Adobe to validate that both of these issues are indeed resolved in CQ v5.5 and AEM v5.6.
It does sound like the same issue. I should clear up something about AEM 5.6. I tested that backlinks are still incorrectly added. I did not test that it still causes a NPE from JcrTagImpl. It's possible that they just added a null-check in that class, which would probably "fix" though wouldn't "solve" the problem. That could be the case.
Also, the issue you mention about the left-hand tree view exists without your patch (which I obviously don't have). I did notice it was fixed in AEM 5.6.
1 person found this helpful
As noted, the NPE was fixed for 5.5 with hotfix 36257. Additional backlinks are not an issue: if they point to a non-existing node, they will be ignored (here is where the NPE happened). This makes the merge logic simpler in that specific case.
Out of curiosity, is there a reason all of those extra backlinks get created? I understand a null-check solution to avoid the NPE, but doesn't it still seem incorrect that backlinks would be created to non-existing nodes? I didn't really dig into the code that creates the backlinks - just the code that processes them. Is there a technical limitation or something that I'm not seeing?
I'm just kind of curious now. I'm glad to read that an author action cannot create a NPE now, per that hotfix.
I think it is required as a safety measurement in case someone adds a new tag "old-solo/new-child".