- On v6.5.3, Tag A is present at path /content/cq:tags/project/folder1/tagA, this tag is moved to a new location, which is /content/cq:tags/project/folder2/tagA.
- Behind the scenes, Authors see the new tag path in page properties (say basic > cq:tags), but in crx/de the tag on the page still points to old location, which is /content/cq:tags/project/folder1/tagA.
- Mapping, /content/cq:tags/project/folder1/tagA tag has a property 'cq:movedTo' whose value is /content/cq:tags/project/folder2/tagA. And /content/cq:tags/project/folder2/tagA tag has a property 'cq:backLinks' whose value is /content/cq:tags/project/folder1/tagA tag. So, there's a 1:1 mapping.
- Other observation is, this /content/cq:tags/project/folder1/tagA tag is still present in crx/de - but not visible to Author, it is 'hidden' somehow and authors only see the new tag path, which is /content/cq:tags/project/folder2/tagA.
This looks to be a new way of how tags are managed in v6.5.x, but i'm trying to understand the reasoning behind it. My use case is all the taxonomy is getting updated in the project, which means tags are moved to different folders, new folders are added etc, which all depend on the OOTB Move operation, and if I use OOTB move operation, I will end up having the legacy tag structure in AEM (seen only in crx/de) and a mapping which will point to old paths. This creates a lot of dependency with the old tags, the path and the 'hidden' tags, and i'm concerned if this will have any impact in the future, if taxonomy is again updated or possible future upgrades.
So, i'm planning of developing a utility to custom move the tags and also update the references in crx/de and not end up having any legacy tag paths and hidden tags. Is there any reason why I should not do this? And is the v6.5.3 tagging move behavior a product bug or is that how it's intended to work, which is little weird isn't it?
