internal/tools/accessrequests/markdown.go:76 renders accessLevelLabel(ar.AccessLevel) unconditionally in the list table, while the card at line 28 guards on the same value and leaves the row out. So one pending access request is published two ways by two formatters of the same package, and the list endpoints are precisely the ones that answer with pending requests, which makes the disagreeing case the common one.
It is not an unambiguous bug, which is why it is a question rather than a patch. For an actual member NoPermissions is a real state, and internal/tools/groupmembers/group_members_test.go:1146 deliberately pins **Access Level**: No access (0) on a card for that reason. What has to be decided is whether a table cell should be empty when GitLab named no level, or whether the two formatters are right to differ because a pending request and a member are not the same object.
Found by the mutation sweep of #823 and deliberately left alone there: it is a published-surface change.
internal/tools/accessrequests/markdown.go:76rendersaccessLevelLabel(ar.AccessLevel)unconditionally in the list table, while the card at line 28 guards on the same value and leaves the row out. So one pending access request is published two ways by two formatters of the same package, and the list endpoints are precisely the ones that answer with pending requests, which makes the disagreeing case the common one.It is not an unambiguous bug, which is why it is a question rather than a patch. For an actual member
NoPermissionsis a real state, andinternal/tools/groupmembers/group_members_test.go:1146deliberately pins**Access Level**: No access (0)on a card for that reason. What has to be decided is whether a table cell should be empty when GitLab named no level, or whether the two formatters are right to differ because a pending request and a member are not the same object.Found by the mutation sweep of #823 and deliberately left alone there: it is a published-surface change.