Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab
GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 34,932
    • Issues 34,932
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 1,253
    • Merge Requests 1,253
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #260347

Closed
Open
Opened Oct 02, 2020 by Melissa Ushakov@mushakovDeveloper4 of 12 tasks completed4/12 tasks

Group Webhooks for Members MVC

Release notes

GitLab has made it easier for you to build user management automation with a webhook that is triggered when a new member is added to a group.

Problem to solve

Customers want to see when members are added to their groups.

Some examples of why this is useful:

  • When a user is added, automatically grant access to specific subgroups or projects.
  • Ensure that users have the appropriate role. For example, no one other than a set of designated people should be group owners.
  • Capture the event in their own data store for auditing purposes.

Today customers need to schedule calls to the API and therefore they don't get notified not immediately and so many API calls puts an unnecessary load on the system.

Customer Use Case:

  • Customer follows an inner sourcing model for the majority of their projects.
  • An internal SLA states that users should have access to all groups needed to perform their job within 5 minutes of gaining access to a system.
  • Today this need is met because all users that SSO in automatically have Guest access and have enough access to get started. The customer has created custom processes that calls the GitLab API and looks for any new user. If a user is found, their role is changed to Developer on the top-level group and they have access to the full group hierarchy.
  • This customer needs to be able to hide certain groups (dark groups) from most users due to security/regulations. These groups are NOT in GitLab today but wish to migrate to it from another platform.
  • Using #220203 (closed) , the customer can change their setup so that users have limited access when created and the dark groups can remain hidden. The customers automation would need to change so that users are added to each individual groups under the top level group except dark ones.
  • This setup will prevent them from meeting their internal SLAs since any post user creation automation will take longer than 5 minutes.
  • If a webhook was available for user creation, they could trigger their automation on that event instead of continuously polling the API. They could meet their SLAs and also greatly reduce the number of API calls they make to GitLab.

Intended users

  • Cameron (Compliance Manager)
  • Sidney (Systems Administrator)
  • Sam (Security Analyst)
  • Alex (Security Operations Engineer)

User experience goal

Group administrators should receive events when member actions are performed so that they can trigger their own automation!

Proposal

Develop a group webhook for Members. The webhook should trigger when members are added.

Implementation steps:

  • Add member_events column to web_hooks database table
  • Add member events to webhook edit form UI
  • Fire member events webhook when user added to group backend and specs
  • Docs with example output
  • Enable feature flag for member events webhook so we can ensure it's not breaking anything
  • When we're confident it's working as expected, remove member events feature flag

Further details

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited Dec 14, 2020 by Serena Fang
Assignee
Assign to
13.7
Milestone
13.7 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: gitlab-org/gitlab#260347