Normalize layers/groups management in TOC #10247

[rowheat02]

Description

fixes: #10247. Some old maps and exports have groups in legacy format which shows some bugs like those mentioned in #10247. Old formats can be converted to new standard formats with UI-wise invisible default group as a parent of all groups.

legacyGroups = [
  { id: '1', name: 'Group 1' },
 { id: DEFAULT_GROUP_ID }
 ];

newStandardFormat=[
      {
          id: <DEFAULT_GROUP_ID>,
         name: <DEFAULT_GROUP_ID>,
        nodes: [
             { id: '1', name: 'Group 1' },
             { id: 'DEFAULT_GROUP_ID.DEFAULT_GROUP_ID' } // Unique UUID generated
         ],
        expanded: true
    }
 ]
 

Please check if the PR fulfills these requirements

• [x] The commit message follows our guidelines: https://github.com/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x", remove the others)

• [x] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Other... Please describe:

Issue

What is the current behavior?

#10247 There are some interactivity bugs on TOC in old maps and exports.

What is the new behavior?

There are no interactivity bugs on TOC in old maps and exports.

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• [ ] Yes, and I documented them in migration notes
• [x] No

Other useful information

[rowheat02]

@tdipisa

• This PR solves the bugs mentioned here #10247
• Now the conversion is done considering groups from this map.https://dev-mapstore.geosolutionsgroup.com/mapstore/#/viewer/39079. Are there any other maps with TOC bugs to verify?

[tdipisa]

@allyoucanmap it seems @rowheat02 is waiting for your feedback to unblock and finalize this PR. Can you please have a look?

[rowheat02]

This task will be placed on hold for the following reasons.

Currently, there is a single group wrapper named "Default," which is not visible in the UI. This wrapper supports all utility functions related to adding/moving nodes, exporting, and importing configurations from the existing codebase. The legacy system's default group (node) can coexist with other sibling groups. Additionally, there is the concept of a "root group" for nodes that are not assigned to any group. Two potential solutions to make it compatible for both new and legacy format of nodes have been identified, both of which involve breaking changes and require careful updates to old utility functions, followed by thorough testing.

Solution 1: Include both layers and groups in the group state, as the group state serves as the starting point for the Table of Contents (TOC) UI. However, this approach would disrupt all legacy utility functions that assume the group state should only contain groups as level-one nodes.

the format that every util function supports ( all group nodes as level one child in group state)

[
  {
    "id": "group node 1",
    "nodes": [
      {
        "id": "layer node 1"
      }
    ]
  },
  {
    "id": "group node 2"
  }
]

format proposed which breaks every util functions( layer node in group as level one child)

[
  {
    "id": "group node 1",
    "nodes": [
      {
        "id": "layer node 1"
      }
    ]
  },
  {
    "id": "layer node 1"
  },
  {
    "id": "group node 2"
  }
]

Implementing this would require a deep understanding of all utility functions and meticulous updates to ensure compatibility.

Solution 2: Introduce a root group that can wrap the Default group and other sibling groups while hiding it in the UI.

{
  "id": "root",
  "node": [
    {
      "id": "Default",
      "nodes": [
        {
          "id": "layer node 1"
        }
      ]
    },
    {
      "id": "layer node 1"
    },
    {
      "id": "group node 2"
    }
  ]
}

However, this adds an additional layer of hierarchy, which could complicate maintenance. It also risks breaking the format and functionality during the export and import of configurations. Both solutions involve significant changes and need careful updates to legacy utility functions, along with extensive testing.

[allyoucanmap]

@rowheat02 @tdipisa, leaving this for the future, both solutions 1 and 2 should not taken as the only ways to solve this problem because they are just a results of internal discussion. Some important points and finding for this task:

• the groups sorting in the TOC root container could be solved by removing some constraint in the UI and functions while the sorting for layers at root level needs refactor in legacy utility function
• a refactor of involved utilities function is needed both for readability and to better understand the sorting workflow
• the exported and imported map configuration should always be consistent. So it's important to evaluate carefully the new properties/structures we want to introduce (if we need to). For this reason I would avoid the solution 1 if possible
• at the moment the groups structure is always derived by the layers configuration. This is computed inside the getLayersByGroup function
• the current duality of root and default group concept should be reduce to a single type of "default" group. In general if we are going to add a layer with group property undefined we should expect this layer in the first level of the TOC without parent groups node