doc-locale/fr-fr/administration/moderate_users.md
{{< details >}}
{{< /details >}}
Si vous êtes un administrateur d'instance, vous disposez de plusieurs options pour modérer et contrôler l'accès des utilisateurs.
[!note] Cette rubrique concerne spécifiquement la modération des utilisateurs dans GitLab Self-Managed. Pour les informations relatives aux groupes, consultez la documentation des groupes.
Pour afficher tous les utilisateurs de votre instance :
Sélectionnez un utilisateur pour afficher les informations de son compte.
{{< history >}}
{{< /history >}}
Les instances GitLab établies peuvent souvent avoir un grand nombre d'utilisateurs humains et de bots. Vous pouvez filtrer la liste des utilisateurs pour n'afficher que les utilisateurs humains ou les utilisateurs bots.
Pour afficher les utilisateurs par type :
Vous pouvez afficher et mettre à jour les utilisateurs facturables de votre instance via la console Rails.
Pour obtenir une liste des utilisateurs facturables quotidiens et historiques dans votre instance GitLab :
Comptez le nombre d'utilisateurs dans l'instance :
User.billable.count
Obtenez le nombre maximum historique d'utilisateurs sur l'instance au cours de l'année écoulée :
::HistoricalData.max_historical_user_count(from: 1.year.ago.beginning_of_day, to: Time.current.end_of_day)
Pour déclencher une mise à jour manuelle des utilisateurs facturables quotidiens et historiques dans votre instance GitLab :
Forcez une mise à jour des utilisateurs facturables quotidiens :
identifier = Analytics::UsageTrends::Measurement.identifiers[:billable_users]
::Analytics::UsageTrends::CounterJobWorker.new.perform(identifier, User.minimum(:id), User.maximum(:id), Time.zone.now)
Forcez une mise à jour du nombre maximum historique d'utilisateurs facturables :
::HistoricalDataWorker.new.perform
Un utilisateur en état d'attente d'approbation nécessite une action de la part d'un administrateur. L'inscription d'un utilisateur peut être en état d'attente d'approbation parce qu'un administrateur a activé l'une des options suivantes :
Lorsqu'un utilisateur s'inscrit à un compte alors que ce paramètre est activé :
Un utilisateur en attente d'approbation :
Un administrateur doit approuver leur inscription pour leur permettre de se connecter.
{{< history >}}
{{< /history >}}
Pour afficher les inscriptions d'utilisateurs en attente d'approbation :
{{< history >}}
{{< /history >}}
Une inscription d'utilisateur en attente d'approbation peut être approuvée ou rejetée depuis la zone Admin.
Pour approuver ou rejeter une inscription d'utilisateur :
Approuver un utilisateur :
Rejeter un utilisateur :
Si l'approbation de l'administrateur pour les promotions de rôle est activée, les demandes d'adhésion qui font passer des utilisateurs existants à un rôle facturable nécessitent l'approbation de l'administrateur.
Pour afficher les utilisateurs en attente de promotion de rôle :
Une liste des utilisateurs avec le rôle le plus élevé demandé s'affiche. Vous pouvez Approuver ou Rejeter les demandes.
Les administrateurs GitLab peuvent bloquer et débloquer des utilisateurs. Vous devez bloquer un utilisateur lorsque vous ne souhaitez pas qu'il accède à l'instance, mais que vous souhaitez conserver ses données.
Un utilisateur bloqué :
Prérequis :
Vous pouvez bloquer l'accès d'un utilisateur à l'instance.
Pour bloquer un utilisateur :
Pour signaler un abus de la part d'autres utilisateurs, consultez signaler un abus. Pour plus d'informations sur les signalements d'abus dans la zone Admin, consultez résoudre les signalements d'abus.
{{< history >}}
{{< /history >}}
Vous pouvez débloquer un utilisateur pour lui redonner accès à l'instance.
Pour débloquer un utilisateur :
L'état de l'utilisateur est défini sur actif et il consomme un siège.
[!note] Les utilisateurs peuvent également être débloqués à l'aide de l'API GitLab.
L'option de déblocage peut être indisponible pour les utilisateurs LDAP. Pour activer l'option de déblocage, l'identité LDAP doit d'abord être supprimée :
Les administrateurs GitLab peuvent désactiver et réactiver des utilisateurs. Vous devez désactiver un utilisateur s'il n'a aucune activité récente et que vous ne souhaitez pas qu'il occupe un siège sur l'instance.
GitLab détermine l'activité récente d'un utilisateur sur la base de l'horodatage last_active_at, qui est le plus récent entre :
last_activity_on : L'horodatage de la dernière activité enregistrée de l'utilisateur dans GitLab (comme la création de tickets, de merge requests ou de commentaires).current_sign_in_at : L'horodatage de la connexion la plus récente de l'utilisateur.Si l'horodatage de connexion actuel d'un utilisateur est plus récent que sa dernière activité enregistrée, l'utilisateur est considéré comme récemment actif, même s'il n'a utilisé aucune fonctionnalité GitLab depuis sa connexion.
Un utilisateur désactivé :
Lorsque vous désactivez un utilisateur, ses projets, groupes et historique sont conservés.
Prérequis :
Pour désactiver un utilisateur :
L'utilisateur reçoit une notification par e-mail indiquant que son compte a été désactivé. Après cet e-mail, il ne reçoit plus de notifications. Pour plus d'informations, consultez les e-mails de désactivation d'utilisateur.
Pour désactiver des utilisateurs avec l'API GitLab, consultez désactiver un utilisateur. Pour des informations sur les restrictions permanentes d'utilisateurs, consultez bloquer et débloquer des utilisateurs.
Pour supprimer un utilisateur d'un abonnement GitLab.com, consultez Supprimer des utilisateurs de votre abonnement.
{{< history >}}
{{< /history >}}
Les administrateurs peuvent activer la désactivation automatique des utilisateurs qui :
Pour désactiver automatiquement les membres inactifs :
Lorsque cette fonctionnalité est activée, GitLab exécute un job quotidien pour désactiver les utilisateurs inactifs.
Un maximum de 100 000 utilisateurs peut être désactivé par jour.
Par défaut, les utilisateurs reçoivent une notification par e-mail lorsque leur compte est désactivé. Vous pouvez désactiver les e-mails de désactivation d'utilisateur.
[!note] Les bots générés par GitLab sont exclus de la désactivation automatique des utilisateurs inactifs.
{{< details >}}
{{< /details >}}
{{< history >}}
delete_unconfirmed_users_setting. Désactivé par défaut.{{< /history >}}
Prérequis :
Vous pouvez activer la suppression automatique des utilisateurs qui :
Vous pouvez configurer ces paramètres à l'aide de l'API Settings ou dans une console Rails :
Gitlab::CurrentSettings.update(delete_unconfirmed_users: true)
Gitlab::CurrentSettings.update(unconfirmed_users_delete_after_days: 365)
Lorsque le paramètre delete_unconfirmed_users est activé, GitLab exécute un job toutes les heures pour supprimer les utilisateurs non confirmés. Le job ne supprime que les utilisateurs qui se sont inscrits il y a plus de unconfirmed_users_delete_after_days jours.
Ce job ne s'exécute que lorsque email_confirmation_setting est défini sur soft ou hard.
Un maximum de 240 000 utilisateurs peut être supprimé par jour.
{{< history >}}
{{< /history >}}
Pour réactiver un utilisateur :
L'état de l'utilisateur est défini sur actif et il consomme un siège.
[!note] Un utilisateur désactivé peut également réactiver son compte lui-même en se reconnectant via l'interface utilisateur. Les utilisateurs peuvent également être réactivés à l'aide de l'API GitLab.
Lorsque l'accès restreint est actif et qu'aucun siège sous licence n'est disponible, les utilisateurs inactifs qui tentent de se reconnecter sont mis en attente d'approbation au lieu d'être réactivés.
{{< history >}}
hide_merge_requests_from_banned_users. Désactivé par défaut.hidden_notes. Désactivé par défaut.hide_projects_of_banned_users. Désactivé par défaut.hide_merge_requests_from_banned_users supprimé.{{< /history >}}
Les administrateurs GitLab peuvent bannir et débannir des utilisateurs. Vous devez bannir un utilisateur lorsque vous souhaitez le bloquer et masquer son activité sur l'instance.
Un utilisateur banni :
Vous pouvez bannir un utilisateur pour le bloquer et masquer ses contributions.
Pour bannir un utilisateur :
{{< history >}}
{{< /history >}}
Pour débannir un utilisateur :
L'état de l'utilisateur est défini sur actif et il consomme un siège.
Pour supprimer un utilisateur :
[!note] Vous ne pouvez supprimer un utilisateur que s'il est un propriétaire hérité ou direct d'un groupe. Vous ne pouvez pas supprimer un utilisateur s'il est le seul propriétaire du groupe.
{{< history >}}
{{< /history >}}
Par défaut, les utilisateurs ne sont pas approuvés et sont bloqués lorsqu'ils tentent de créer des tickets, des notes et des extraits de code considérés comme du spam. Lorsque vous faites confiance à un utilisateur, il peut créer des tickets, des notes et des extraits de code sans être bloqué.
Pour faire confiance à un utilisateur :
Pour ne plus faire confiance à un utilisateur :
{{< details >}}
{{< /details >}}
Lors de la modération des utilisateurs, vous pouvez avoir besoin d'effectuer des actions en masse sur ceux-ci en fonction de certaines conditions. Les scripts de console Rails suivants montrent quelques exemples de cela. Vous pouvez démarrer une session de console Rails et utiliser des scripts similaires aux suivants :
Les administrateurs peuvent désactiver les utilisateurs n'ayant aucune activité récente.
[!warning] Les commandes qui modifient des données peuvent causer des dommages si elles ne sont pas exécutées correctement ou dans les bonnes conditions. Exécutez toujours les commandes dans un environnement de test d'abord et ayez une instance de sauvegarde prête à restaurer.
days_inactive = 90
inactive_users = User.active.where("last_activity_on <= ?", days_inactive.days.ago)
inactive_users.each do |user|
puts "user '#{user.username}': #{user.last_activity_on}"
user.deactivate!
end
Les administrateurs peuvent bloquer les utilisateurs n'ayant aucune activité récente.
[!warning] Les commandes qui modifient des données peuvent causer des dommages si elles ne sont pas exécutées correctement ou dans les bonnes conditions. Exécutez toujours les commandes dans un environnement de test d'abord et ayez une instance de sauvegarde prête à restaurer.
days_inactive = 90
inactive_users = User.active.where("last_activity_on <= ?", days_inactive.days.ago)
inactive_users.each do |user|
puts "user '#{user.username}': #{user.last_activity_on}"
user.block!
end
Les administrateurs peuvent bloquer ou supprimer les utilisateurs n'ayant aucun projet ni groupe.
[!warning] Les commandes qui modifient des données peuvent causer des dommages si elles ne sont pas exécutées correctement ou dans les bonnes conditions. Exécutez toujours les commandes dans un environnement de test d'abord et ayez une instance de sauvegarde prête à restaurer.
users = User.where('id NOT IN (select distinct(user_id) from project_authorizations)')
# How many users are removed?
users.count
# If that count looks sane:
# You can either block the users:
users.each { |user| user.blocked? ? nil : user.block! }
# Or you can delete them:
# need 'current user' (your user) for auditing purposes
current_user = User.find_by(username: '<your username>')
users.each do |user|
DeleteUserWorker.perform_async(current_user.id, user.id)
end