Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Issues
  • #6328

Closed
Open
Created Feb 14, 2014 by Administrator@rootOwner

Return username parameter in UserSafe entity

Created by: jefferai

The internal API contains a "/discover" method to allow gitlab-shell to find out the name associated with a key_id. This is filtered via UserSafe to contain only the "name" parameter.

Right now, the only use of both /discover and UserSafe is to allow this functionality in case audit_usernames = true. However, fetching the username from a key_id is a very useful thing to have as keying behavior off of usernames is often far easier than keying behavior off of numeric IDs.

My proposal is to modify UserSafe to expose ":name, :username" instead of just ":name". I don't think this is unsafe (you're not returning the email, after all) and doesn't incur meaningful additional overhead, but vastly helps those of us that need to add logic in the hook before/after the gitlab-shell update call.

I've tried this small change locally and it works well.

Assignee
Assign to
Time tracking