Roles and Permissions page settings giving a 404 error

Summary

As an Administrator of an instance, and as Owner of an existing Group (when the Owner is populated via LDAP), when accessing https://<instance>/<group> > Settings > Roles and Permissions, a 404 page is displayed (full URL: https://<instance>/groups/<group>/-/settings/roles_and_permissions)

This is not the case when accessing as Owner of the Group when the Group is recently created (and therefore no LDAP synchronization is in place).

Steps to reproduce

  • As administrator (or as Group Owner, assuming ownership has been granted via LDAP), go to a Group page.
  • Expand Settings.
  • Click on Roles and Permissions.
  • 404 error page.

What is the current bug behavior?

It gives a 404 error page for existing Groups.

What is the expected correct behavior?

Should give 200 success page and to show the appropriate page.

This behavior does not show up when owner is granted explicitly in the project members (not via LDAP).

Relevant logs and/or screenshots

Tested in GitLab 16.5.3 -> 16.9.4

{ "data": { "msg": "access", "kubernetes": { "container_name": "gitlab-workhorse", "namespace_name": "gitlab", "pod_name": "gitlab-webservice-default-85c49566cc-2kp74", "container_image": "registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ee:v16.5.3", "container_image_id": "registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ee@sha256:454aa5a4cc0168de0bbdf93a7af969f0c442f84be4c4b309e6f5da812183ca27", "pod_id": "e35bcdd2-76ae-470d-ac52-d1a00c95fba9", "labels": { "app": "webservice", "chart": "webservice-7.5.3", "heritage": "Helm", "pod-template-hash": "85c49566cc", "release": "gitlab", "gitlab_com/webservice-name": "default" }, "host": "xxx", "master_url": "https://10.254.0.1:443/api", "namespace_id": "a319dbad-dc19-4bb9-beee-1e8ff9b70fe9", "namespace_labels": { "kubernetes_io/metadata_name": "gitlab" } }, "remote_addr": "xxx", "method": "GET", "level": "info", "raw": "{\"content_type\":\"text/html; charset=utf-8\",\"correlation_id\":\"01HGZP0P7KG3Z6JWTQ9MFM9H8R\",\"duration_ms\":47,\"host\":\"<instance>\",\"level\":\"info\",\"method\":\"GET\",\"msg\":\"access\",\"proto\":\"HTTP/1.1\",\"referrer\":\"https://<instance>/<group>/\",\"remote_addr\":\"xxx\",\"remote_ip\":\"xxx\",\"route\":\"\",\"status\":404,\"system\":\"http\",\"time\":\"2023-12-06T13:45:28Z\",\"ttfb_ms\":47,\"uri\":\"/groups/<group>/-/settings/roles_and_permissions\",\"user_agent\":\"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0\",\"written_bytes\":57268}", "uri": "/groups/<group>/-/settings/roles_and_permissions", "docker": { "container_id": "8ee18f5b2ebdc768dc1874729073de993eef9d1524ecaaebc7533a1f9bf88f9f" }, "duration_ms": 47, "route": "", "system": "http", "content_type": "text/html; charset=utf-8", "stream": "stdout", "proto": "HTTP/1.1", "correlation_id": "01HGZP0P7KG3Z6JWTQ9MFM9H8R", "ttfb_ms": 47, "written_bytes": 57268, "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0", "status": 404 }}

Possible fixes

We believe this should be both fixed for Owners of a Group, and accessible anyway by Administrators of the instances.

Edited by Ismael Posada Trobo