Nested Groups - top-level group missing services

[br05s]

Description

I'm running version 1.4.5 on Docker and use automatic discovery for most of my services. I'm trying to use the layout below in my settings.yaml and finding that the services in my Streaming group are not being returned by the API. If I move Library Management to no longer be nested, the services are returned.

However this problem is not impacting the Downloads group and it is returning the services as expected.

homepage version

v1.4.5

Installation method

Docker

Configuration

layout:
  Streaming:
    style: column
    Library Management:
      style: column
  Upcoming:
    style: column
  Downloads:
    style: column
    Download Management:
      style: column

Container Logs

No response

Browser Logs

No response

Troubleshooting

I looked through the API code and noticed something that may be the problem. In ensureParentGroupExists, it overwrites the index of sortedGroups with the group from configuredGroups.

When building the response, if a group is child group, it falls to a section that merges the group to configuredServices and then calls ensureParentGroupExists (using configuredServices as the argument for configuredGroups). But top-level groups defined in the layout are simply added to the sortedGroups array and never merged into configuredServices.

But why does this only impact one of my groups and not the other? It appears that this bug will only occur if a nested group comes after the top-level group when iterating mergedGroupsNames. Otherwise it will work correctly as the nested group will be found in configuredServices when building the new mergedGroup of the top-level group, which then replaces the previous entry.

So this issue will only potentially occur depending on the order services returned from Docker (and also Kubernetes for that matter). Configured services through the yaml shouldn't run into this issue since they would exist in configuredServices. But based on how mergedServiceNames is created, any service definition in the yaml using a nested group would likely always cause this issue if other services came from those other sources.

I think I see a couple ways that this could be fixed - in ensureParentGroupExists, if an entry already exists for that index in sortedGroup, don't replace it. Another way would be to call mergeSubgroups when a group is defined at the top-level of the layout.

[br05s]

I was able to work around the issue for now by creating a single top-level group and nesting everything under it:

layout:
  Main:
    style: row
    columns: 3
    header: false
    Streaming:
      style: column
      Library Management:
        style: column
    Upcoming:
      style: column
    Downloads:
      style: column
      Download Management:
        style: column

I did notice something interesting though as my Upcoming group is defined in services.yaml. Despite having it in the layout in the second column, it was being placed in the first column. That appears to be because groups defined under layout in settings.yaml are simply added to what was loaded from services.yaml. So anything defined in services will already exist before adding from layout.

- Main:
  - Upcoming:
    - "":
        widget:
          type: calendar
          firstDayInWeek: sunday
          view: monthly
          showTime: true
          maxEvents: 50
          integrations:
            - type: sonarr
              service_group: Library Management
              service_name: Sonarr
              color: blue
              params:
                unmonitored: false
            - type: radarr
              service_group: Library Management
              service_name: Radarr
              color: yellow
              params:
                unmonitored: false
    - " ":
        widget:
          type: calendar
          firstDayInWeek: sunday
          view: agenda
          showTime: true
          maxEvents: 10
          integrations:
            - type: sonarr
              service_group: Library Management
              service_name: Sonarr
              color: blue
              params:
                unmonitored: false
            - type: radarr
              service_group: Library Management
              service_name: Radarr
              color: yellow
              params:
                unmonitored: false

I was able to work around that by adding the groups to services.yaml. I originally just tried putting "Streaming", but it didn't work until I also put "Library Management":

- Main:
  - Streaming:
    - Library Management:
  - Upcoming:
    - "":
        widget:
          type: calendar
          firstDayInWeek: sunday
          view: monthly
          showTime: true
          maxEvents: 50
          integrations:
            - type: sonarr
              service_group: Library Management
              service_name: Sonarr
              color: blue
              params:
                unmonitored: false
            - type: radarr
              service_group: Library Management
              service_name: Radarr
              color: yellow
              params:
                unmonitored: false
    - " ":
        widget:
          type: calendar
          firstDayInWeek: sunday
          view: agenda
          showTime: true
          maxEvents: 10
          integrations:
            - type: sonarr
              service_group: Library Management
              service_name: Sonarr
              color: blue
              params:
                unmonitored: false
            - type: radarr
              service_group: Library Management
              service_name: Radarr
              color: yellow
              params:
                unmonitored: false

[xolom]

I have the same issue. As soon as there are 3 services in top level group, the services gonna disappear

[github-actions[bot]]

This discussion has been automatically closed due to inactivity. See our contributing guidelines for more details.

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details.