Is there some way to specially filter access tokens from the invite member search?

Hi everyone,

I’m using GitLab for many different source code projects and some projects focused on deploying compiled binary software to customers. Reason is that we have some software which doesn’t need to be installed and is only a collection of files and directories, config and language files etc. maintained in GIT repos. Configs, language files etc. are heavily customized for customers and tracking those as part of a whole deployment makes updates etc. a lot easier.

Though, customers don’t have real user accounts like mine to access their repos, but instead access tokens are used. As those are maintained per repo in their dialog, their name is pretty generic currently: customer_reader, customer_writer, maintainer_reader and stuff like that. One reason to not encode repo names, customers name etc. in it was that groups names, repo names, repo paths etc. might change anytime, while the tokens can’t be renamed. So, with pretty generic token names, when renaming or moving repos, one only needs to change the config for those on checkouts.

When adding other employees of my company to some repos or groups, the dialog to search those contains all access tokens as well and because those are named that generically, it’s a pretty long list and possibly cluttered within all other different types of accounts I’m interested in.

Is there some setting or whatever to exclude access tokens from that list by default?

As those are created per repo anyway most likely, it doesn’t make too much sense to me to handle those like other system wide created accounts by default. The only different approach I see currently is either prefixing all tokens with something sorting at the beginning of the list or name them using abbreviations of their parent organisation and repo or alike. Something like the following:

  • _at_customer_reader
  • _access_token_customer_reader
  • _token_customer_reader
  • $ORG_$SUBGROUP1_$SUBGROUP2_$SUBGROUP3_$REPO_customer_reader

The latter example is to show that I heavily use subgroups to organize different customers into different groups, different kinds of repos by their purpose into groups etc. Names can become really long that way and additionally groups and repos can easily be renamed and moved according to their path, so token names would simply not be correct anymore.

Any ideas? Thanks!

It seems that access tokens with a prefix like “token” are sorted at the end of the list of members to invite into groups. Which is at least something, but would be better to have some sort of filter.