Can we disable notifications for user permission level changes?

Summary

We'd like to disable notifications for when a user's permission level is changed at the group and or project level.

feature proposal

Related Code

• Here's the NotificationSetting model
  • Perhaps at a custom permission level, we could enable/disable notifications for the permission change event
• Here's the code that sends an email when a group member's permission level changes
• Here's the code that sends an email when a project member's permission level changes
• This is the NotificationService that handles email sending for various events
  • Maybe more events in here should be added to the EMAIL_EVENTS constant in the NotificationSetting model

UI/UX

• The "Show" view of a user's notifications settings
• The partial allowing a user to configure their custom notifications

Extent of Work

• It looks like the UI code doesn't need to change as the list of events are fetched from the NotificationSetting model
• The change_project_access_level and change_group_access_level events need to be added to the NotificationSetting model
• Once that's in place we just need to update the conditions here to account for the custom permissions setting at the group-level and project-level.

  • For example (for group-level):

        def post_update_hook
          if access_level_changed? and self.user.notification_settings_for(self.group).events[:change_group_access_level]
            notification_service.update_group_member(self)
          end
    
          super
        end

Related Issues

• Make proper API for notification settings

Changed title: Can we disable notifications for permission changes? → Can we disable notifications for user permission level changes?

Added feature proposal notifications labels

mentioned in merge request !5570 (closed)

mentioned in issue #20151 (moved)

@winniehell is there anything more I can do to draw attention to this and !5570 (closed)?

@dandunckelman I'll try

cc @jschatz1?

@winniehell thank you!

I think this more of a thing for @DouweM or @rspeicher. But my initial visceral reaction is to say

Do or do not. There is no configuration.

--- @DouweM 2016

@jschatz1 @rspeicher The entire point of the "Custom" notification level is to allow people more fine grained control over what notifications they will and won't receive, so in this configuration is a feature :) That doesn't mean that we should add configuration options for every notification type though, you can't disable the "new SSH key was added to your profile" notification either for example, because that's a security feature.

I'm also not sure if this notification type, if we were to add it, makes sense per-user on a per-group and per-project level. It seems like a global preference per user, or for all of GitLab (which we likely won't add a configuration option for).

@dandunckelman Can you help me understand why you want this feature?

/cc @rymai because you're reviewing https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5570

@DouweM we provide an "IaaS" platform and use Gitlab to store info about each of our users' "applications". We allow our users to browse Gitlab via SSO with "guest" level access so we can interact together via Issues. We prefer the "guest" access level instead of something more elevated to help prevent them from making changes directly in Gitlab when we have our own UI for controlling their Gitlab project's code (our users are generally non-developers with little to no git experience).

When a user makes changes to their "app", we use the Gitlab gem to change their "project". In order to do this, we change their access level from "guest" to "master" so the requested changes are attributed back to their user. Once all changes have been made, their access level is then changed back from "master" to "guest".

We've been wanting to enable email notifications for own benefit & our customers, but because of the above workflow, they will receive a lot of emails saying "You've been granted 'guest' access on Project X" or "You've been granted 'master' access on Project X".

Adding this feature would disable those emails (at least, once we can control notification settings via API...which is being worked on in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5632).

In order to do this, we change their access level from "guest" to "master" so the requested changes are attributed back to their user.

This sounds to me like a good use case for the impersonate feature. Have you already considered that? Sorry, I can't find any documentation about it to link from here.

@winniehell I can't find any docs on it as well, but that does seem like it is a fit for our use-case.

The Admin::UsersController provides the ability to impersonate, but I can't find any way to "make commits as another user" via API. Maybe that's the feature we really need.

@winniehell @dandunckelman the API has the ability to sudo to another user (from admin) which is how commits are being done as the end user. But as they are by default guests in our example, we need to

• set them to Master
• sudo to the user
• commit as the user
• exit sudo
• set them back to Guest

@mahcsig If it is only about the information stored in the Git commit, it would be even simpler:

$ GIT_COMMITTER_NAME='Mr. Committer' GIT_COMMITTER_EMAIL='committer@example.com' git commit --author 'Mrs. Author <author@example.com>' --message='dummy commit'
$ git log --max-count=1 --format=full
commit 48417d880cb9a804cf25de717fcad577d54be414
Author: Mrs. Author <author@example.com>
Commit: Mr. Committer <committer@example.com>

    dummy commit

@dandunckelman Thanks for the explanation about your use-case! I don't like adding more options to support "hacky" use-cases like the one you described. As @DouweM pointed out, I see the "access granted" email as a "security" email that should always be sent.

Also, I think the custom notifications feature allows you to be notified for more events than the default events, it doesn't allow you to opt-out of default events, so it wouldn't solve your use-case (since we want to send the "access granted" emails by default)!

@DouweM @rymai please help me and @mahcsig come up with a solution that isn’t hackish and accomplishes our goal.

To add some clarity to our use case, we have a Rails app that handles the user authentication and provides a UI editor to build configuration files that we version control that forces a certain workflow so end users don’t have to learn git. Our users are mostly non-developers and our early attempts to educate them on a git workflow proved to be disastrous. We have close to 1000 projects and over 2400 non-developer users (guests) that are using GitLab through this application.

We want to use the Issues built into GitLab but don’t want to provide access to the repository contents. To accomplish this we assign Guest permissions so they can create/comment on issues, but have no file access. We do however want any changes they make to the configuration files to be attributed to them, which is why we currently go through the permission change dance.

@winniehell We are using the GitLab API to communicate as the API was one of the reasons we use GitLab in the first place. We were using Rugged in the past to access repositories directly and it got to be unwieldy.

With the current notification settings each time we commit on their behalf it triggers the sending of two emails, one when we change the permissions to allow commit and one when we change it back. Due to this we have disabled the GitLab email integration but have lost the critical functionality of notifying users of Issues when there are comments or other relevant events. This has caused us significant pain and impacted our users’ satisfaction.

After reviewing the options, there appears to be (3) directions we can head:

1. Accept this MR & !5632 (merged)
2. Implement an impersonate or “commit as” feature for the API where the user would be the committer, but their permissions would not be used.
3. Help us determine a different workflow that doesn’t involve our current workaround, while still accomplishing our goal.

We are using the GitLab API to communicate as the API was one of the reasons we use GitLab in the first place. We were using Rugged in the past to access repositories directly and it got to be unwieldy.

@dandunckelman If I understand you correctly, adding the functionality I described above (manipulating author and committer) to the GitLab API would also solve your problem. Is that right?

@winniehell right. That's inline w/ our suggestion:

Implement an impersonate or “commit as” feature for the API where the user would be the committer, but their permissions would not be used.

@mahcsig @dandunckelman I found the impersonate feature in API documentation (it's actually called sudo there): https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/api/README.md#sudo

Does this help?

@winniehell I think that's what @dandunckelman & @mahcsig already do (see https://gitlab.com/gitlab-org/gitlab-ce/issues/20147#note_13590395), but you still have to change the user's permission level since SUDO only sets the current user as the given user (thus the permissions used are those of the given user, guest in this case).

Sorry, I misunderstood the sudo-thing in that case. I'll try to avoid cluttering the discussion with more not-knowledge.

I think we can add params to the commit API to override the commit's user name and email. After all, people can already set those to whatever they like on their local machine.

@dandunckelman Can you open an issue for that specific request?

mentioned in issue #20789 (closed)

@DouweM added here: https://gitlab.com/gitlab-org/gitlab-ce/issues/20789

Status changed to closed

Closing in favor of #20789 (closed)

mentioned in merge request !5822 (merged)