Merge branch 'master' of gitlab.com:gitlab-org/gitlab-ee

app/services/git_push_service.rb

@@ -84,11 +84,7 @@ class GitPushService
         author ||= commit_user(commit)
 
         issues_to_close.each do |issue|
-          if project.jira_tracker? && project.jira_service.active
-            project.jira_service.execute(commit, issue)
-          else
-            Issues::CloseService.new(project, author, {}).execute(issue, commit)
-          end
+          Issues::CloseService.new(project, author, {}).execute(issue, commit)
         end
       end
 

app/services/issues/close_service.rb

 module Issues
   class CloseService < Issues::BaseService
     def execute(issue, commit = nil)
+      if project.jira_tracker? && project.jira_service.active
+        project.jira_service.execute(commit, issue)
+        return issue
+      end
+
       if project.default_issues_tracker? && issue.close
         event_service.close_issue(issue, current_user)
         create_note(issue, commit)

doc/integration/ldap.md

@@ -359,3 +359,24 @@ Here, `sync_time` is set to `1800` seconds, meaning the LDAP cache will expire e
 For manual GitLab installations, simply uncomment the `sync_time` entry in your `gitlab.yml` and set it to the value you desire.
 
 Please note that changing the LDAP sync time can influence the performance of your GitLab instance.
+
+## What sort of queries can my LDAP server expect from GitLab EE?
+
+Active GitLab users trigger 'permission updates' by signing in or
+interacting with GitLab, and in addtion all GitLab users (active or not) get a
+permission update during the daily sweep. The number of permission updates per
+day depends on how many of your GitLab users are active and on how many
+LDAP-enabled GitLab users exist in your GitLab SQL database.
+
+During a 'permission update' for a user, GitLab does 1-2 queries for the
+specific user, and 1 queries for each LDAP group known to GitLab. GitLab
+fetches all available attributes of LDAP user and group objects on most
+queries. If you use Active Directory, GitLab performs additional
+'extensibleMatch' queries to check for nested group membership and whether the
+user is blocked, one of each per user and group.
+
+Note that usually not all user and group objects in an organization's LDAP tree
+will be known to GitLab. GitLab only queries LDAP user objects corresponding to
+users who use or have used GitLab. Similarly, GitLab only queries LDAP group
+objects that have been (manually) linked to a GitLab group by a GitLab user or
+administrator.

lib/gitlab/ldap/access.rb

@@ -108,7 +108,7 @@ module Gitlab
         ldap_email = ldap_user.email.last.to_s.downcase
 
         return false if user.email == ldap_email
-        
+
         user.skip_reconfirmation!
         user.update(email: ldap_email)
       end
@@ -131,6 +131,10 @@ module Gitlab
       end
 
       # Loop throug all ldap conneted groups, and update the users link with it
+      #
+      # We documented what sort of queries an LDAP server can expect from
+      # GitLab EE in doc/integration/ldap.md. Please remember to update that
+      # documentation if you change the algorithm below.
       def update_ldap_group_links
         gitlab_groups_with_ldap_link.each do |group|
           active_group_links = group.ldap_group_links.where(cn: cns_with_access)