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