[Fix]: Migrate existing tag nav to new navigation tree structure

[dancastellon]

Resolves #4881
Impact: minor
Type: bugfix

Issue

With the merge of #4683, a new API for defining and loading navigation trees was introduced. As part of migration 50, a default navigation tree was created with a single "Home" item. The migration should have also converted the existing tag nav items to the new tree.

Solution

This PR updates migration 50 to migrate the existing tag nav to the new tree structure.

Breaking changes

None

Testing

1. Login to Reaction and update the tag nav to look like the demo storefront: https://storefront.demo.reactioncommerce.com/
2. In the database, set Migrations.version back to 49 and restart the app
3. Run this query in Graphiql and confirm the tree structure matches what you see in the Reaction app (Compare the content -> value field)

{
  primaryShop {
    defaultNavigationTree(language: "en"){
      _id
      shopId
      name
      items {
        navigationItem {
          data {
            ...NavigationItemFields
          }
        }
        items {
          navigationItem {
            data {
              ...NavigationItemFields
            }
          }
          items {
            navigationItem {
              data {
                ...NavigationItemFields
              }
            }
          }
        }
      }
    }
  }
}

fragment NavigationItemFields on NavigationItemData {
  content {
    language
    value
  }
  classNames
  url
  isUrlRelative
  shouldOpenInNewWindow
}

[dancastellon]

@mikemurray and @aldeed Can you take a look at this when you have a chance?

[aldeed]

@dancastellon Can you move the two util functions to /imports/plugins/core/versions/server/util? We don't want migrations to reference any code outside of the versions plugin because otherwise someone may use those utils for something else, change them to match future development, and in the process break the way the original migration is supposed to work.

[mikemurray]

@dancastellon I noticed that to 2nd level tags aren't sorted in the correct order. Do we need to preserve that order or was it an acceptable loss to sort them by createdAt instead?

[aldeed]

I vote for preserving the current order, which is the order in the subtag arrays. You could potentially follow the pattern used in the starterkit, which gets all tags first and then passes to the recursive function.

[mikemurray]

@aldeed should this be going into develop or the release-2.0.0-rc.8 branch?

[dancastellon]

@mikemurray and @aldeed - I've made 2 changes:

• Moved the 2 util functions to the versions plugin
• Updated the order of sub tags to match order defined on parent (parentTag.relatedTagIds)

To retest you should just be able to:

• Delete NavigationTrees and NavigationItems records
• Set Migrations.version back to 49
• Restart app

[mikemurray]

@dancastellon @aldeed Looks good to me.

Just wanted to confirm which branch this PR is supposed to go into. release-2.0.0-rc.8 or into develop since it seems like this is one of the last PRs to target release-2.0.0-rc.8

[spencern]

@mikemurray Good question on the base branch for this PR. Based on the fact that #4683 was merged into RC8, I believe this should target RC8 as well.

[mikemurray]

@spencern then into RC8 it goes

[mikemurray]

👍

Files related to the migration have been moved to the versions plugin