Groups on profile page

On https://[our gitlab]/users/[username]/groups
(Our GitLab is behind a VPN so you couldn’t access it even if I hadn’t hidden the address above)

a number of groups is shown (see

), but if I check on
https://[our gitlab]/admin/users/[username]/projects
that user is a member of fewer groups (see
(In both screenshots, I’ve removed the person’s name, as I don’t want to expose them in any way, trust me that it is the same person. I’ve also removed the name of one group as that said something about which company this is for, now you can just see something which technologies we use, and where we have a department - not that interesting if you ask me)

Where does that first list come from?

And how can non-admins find out what groups users are a member of?

I’m wondering if it’s an issue with the group settings. For example, if you go to Group_Name → Settings → General under visibility level there are options for private, public, internal. As shown below:

assuming that the group is private, then if you are not a member of the group then you will be unable to see the group/projects unless you are an admin.

This could potentially explain why. In such a scenario, it would be best if all groups were internal if you wish for normal users to see who is a member of what group/project.

My problem is the other way round, when I have admin rights I see fewer groups (but it matches what the user can actually do) than users without admin rights (or me with admin rights) checking user’s profiles.

We have (at least) two people that are shown (on their profile pages) to be members of a group I’m personally a member of, but I’m not personally a member of most of the involved groups.

But I was an admin when I checked and made those screenshot (the second is from the admin area, which you can’t even access if you’re not).

The default visibility level for new groups, and the visibility level for all the involved groups is “Internal”.

But my issues comes from the fact that a colleague who is not an instance administrator on our GitLab though some people were members of some groups (because they were shown on those people’s profiles), but they couldn’t access projects owned by those groups - when I (as admin) checked, the “answer” was that those people were not members of those groups.

You could try clearing the cache. I did this once when the main screen wasn’t showing groups/projects properly. Usually something they suggest in the gitlab docs after a name change etc. might help?

(Being a little stupider than I have to, hoping to make this thread more usable for others who find it later) Which cache and how to clear it? When I search for ‘gitlab clear cache’ online, most results are about the caches runners use (I saw somewhere that there can be up to four caches), I hope it’s not any of those.

The server could probably do with a reboot anyway (but not during normal working hours), would that clear that cache or is it backed by anything?

I’m trying to find the command now that I used, my google skills seem to be failing me to locate it today. I did find it in the Gitlab docs.

A restart would reset the redis cache though.

Could the command you’re looking for be /opt/gitlab/bin/gitlab-rake cache:clear?

Yeah, that’ll be the one, I know it had something to do with the dashboard: Maintenance Rake tasks | GitLab

After you posted that I managed to find it. I did remember it being related to maintenance or troubleshooting, but was failing me to find it.

Last night I remembered to reboot the server.

My main browser has cached the pages with the wrong lists, but of I try in a browser I don’t normally use for GitLab, the “Groups” tab on a users profile page shows a lot fewer groups than before, but it still doesn’t match what I can see as instance administrator (I did that from my main browser.

As an example I have one user, where the profile page show them to be a member of exactly one group called “mirror”, but the admin page shows them to be a member of exactly one group called “webdev-india”. As far as I can see none of those groups are a subgroup of the other.