Sur le forum que nous gérons, bien que nous accordions beaucoup de latitude sur le nom d’utilisateur, nous avons exigé (dans les conditions d’utilisation) que les utilisateurs fournissent leur nom complet et ne le modifient pas, sauf pour refléter des changements légaux de nom. Nous n’avons pas encore beaucoup d’utilisateurs (moins de 250), mais déjà, certaines personnes commencent à ne pas respecter cette règle. Nous avons donc besoin d’un moyen de l’appliquer.
En bref, nous avons besoin qu’un nom complet ne puisse être modifié que par un modérateur ou un administrateur après que le compte ait été approuvé. Y a-t-il un moyen d’y parvenir dans Discourse ? J’ai parcouru la documentation sans succès.
Si ce n’est pas le cas, cette fonctionnalité pourrait-elle être ajoutée au code ?
Une solution simple mais évitable consiste à masquer le bouton de modification avec CSS. Les personnes astucieuses pourraient le modifier de toute façon. Pour forcer son maintien, vous auriez besoin d’un plugin ou peut-être du SSO.
Merci pour votre réponse. Savez-vous si un tel plugin existe déjà ? Sinon, j’essaierai de comprendre comment faire cela, mais cela fait une éternité que je n’ai pas codé quoi que ce soit
Il semble que le plugin n’existe pas, mais la solution de contournement CSS consiste simplement à inspecter dans Firefox ou Chrome, à cliquer sur la boîte que vous souhaitez masquer et à modifier le CSS du thème :
Je pense que l’option la plus solide ici est d’utiliser un fournisseur d’authentification externe (OAuth, peu importe) avec l’option « auth overrides username » :
Remplace le nom complet local par le nom complet du site externe à chaque connexion et empêche les modifications locales. S’applique à tous les fournisseurs d’authentification.
Cela fera l’affaire, mais l’inclusion de services tiers n’est pas une bonne affaire pour beaucoup d’entre nous qui sont d’accord pour laisser les utilisateurs choisir leur fournisseur de messagerie.
Par « externe », je n’entends pas « tiers » mais plutôt « externe à Discourse ». Vous pourriez utiliser une solution tierce, ou vous pourriez l’exécuter vous-même.
La confiance en nous-mêmes est différente de la confiance dans l’équipe principale de Discourse, ce sont des professionnels de haut niveau qui ont construit le tout.
Mon point est que votre solution la plus solide n’est pas la plus élégante, qui devrait être de désactiver l’option à partir d’un interrupteur.
Bonjour,
Merci pour la suggestion, mais malheureusement, ce n’est pas une option actuellement. Nous n’avons pas d’authentification unique (SSO) centralisée et sa gestion est bien plus que ce que je souhaite entreprendre !
Actuellement, la falsification CSS est probablement la seule chose que je pourrai faire. Je gère un forum de club, avec tous les membres identifiés, et forcer ce changement malgré le fait qu’il soit simplement désactivé (et interdit par les règles) entraînerait la conversion du compte de l’utilisateur en lecture seule ou sa désactivation complète.
Merci @satonotdead pour les liens que vous avez fournis, je vais parcourir ce contenu et voir si je peux gérer le changement facilement. À long terme, quand j’aurai le temps (je devrai peut-être attendre 15 ans ou plus jusqu’à la retraite ), je pourrais choisir d’y investir en écrivant un plug-in…
Cela pourrait en effet fonctionner, mais je souhaite toujours qu’il apparaisse à côté du nom d’utilisateur, comme c’est actuellement le cas pour le nom complet.
Pour l’instant, masquer la section du nom complet dans la section de mise à jour du profil de l’utilisateur sera une solution temporaire acceptable. Je peux toujours gérer les exceptions venant d’utilisateurs trop curieux pour leur propre bien.
Je ne comprends toujours pas pourquoi cela semble être un tel problème d’avoir cette option de verrouillage dans le produit de base, comme nous l’avons pour le nom d’utilisateur… cela semble très dogmatique.
[MODE TAQUIN ACTIVÉ]
Un peu comme refuser d’autoriser les signatures d’utilisateurs parce que c’est pour notre propre bien.
[MODE TAQUIN DÉSACTIVÉ]
J’ai jeté un coup d’œil ; cacher le champ avec l’API est possible, mais je ne trouve aucune donnée sur laquelle je puisse m’appuyer pour savoir si cet utilisateur est approuvé ou non (dans le contexte de la page des préférences)
Voici ce que j’ai pour l’instant.
Je ne sais pas si je devrais me sentir mal ; c’est peut-être un peu astucieux ici.
js
<script type="text/discourse-plugin" version="0.8">
const { setting } = require("discourse/lib/computed");
api.modifyClass("controller:preferences/account", {
pluginId: "hide-name-in-preferences",
get canEditName() {
const enables_name = setting("enable_names");
if (enables_name && this.isCurrentUser && !this.model.staff) {
if (this.model.name) {
// Hide only the input field (name is displayed)
this.model.can_edit_name = false;
} else {
// Hide the whole section
return false;
}
}
return enables_name;
},
});
</script>
Ce n’est pas un problème ou un dogme, la plupart de nos fonctionnalités sont priorisées en fonction de la demande, et il n’y a pas eu beaucoup de demande pour cela.
Merci @Arkshine, cela ressemble beaucoup à ce dont j’ai besoin. Je devrai juste chercher comment l’intégrer dans mon environnement , mais je l’aurai probablement intégré d’ici ce week-end.
Merci, je peux comprendre la priorisation, bien que le mécanisme global soit déjà présent et, d’après ce que j’ai pu voir, ait été demandé plusieurs fois par les utilisateurs. Si le correctif est vraiment aussi simple que ce qu’Arshkine vient de fournir, il me semble que ce fut un choix conscient de NE PAS accorder la même « courtoisie » à ce champ qu’aux autres.
Ne vous méprenez pas, c’est une merveilleuse pièce logicielle qui a été développée ici. D’après ce que je peux dire du forum que j’administre, cela semble fonctionner sans faille, et je sais à quel point c’est difficile. Je ne suis simplement pas d’accord avec toutes les décisions qui ont été prises, et je considère que certaines des justifications qui ont été données sont parfois dogmatiques ou autoritaires. Cela n’empêche pas que ce soit le meilleur disponible aujourd’hui.
Un composant de thème peut être contourné en utilisant le mode sans échec ou en modifiant d’autres éléments dans le navigateur.
La plupart du temps, le développement est piloté par des personnes hébergées chez CDCK/Discourse.org, car c’est de là que vient l’argent. Parfois, des fonctionnalités sont ajoutées si beaucoup de personnes veulent/ont besoin d’une fonctionnalité, mais si ces personnes ne paient pas d’argent à CDCK, il faut qu’elles soient très nombreuses, ou qu’il s’agisse d’une fonctionnalité qui semble plaire à de nombreux clients payants. Notez que je ne travaille pas pour eux, il ne s’agit donc que de mon observation au cours des (presque 8) dernières années.
Spéculation : Je ne serais pas surpris si la plupart des personnes qui le souhaitent et qui sont des clients payants ont déjà une forme d’authentification unique (SSO). Cela en fait donc une fonctionnalité encore plus de niche pour tous les autres.
Il ne semble pas que vous fassiez quoi que ce soit pour authentifier le nom complet que vos utilisateurs fournissent lors de leur inscription. Donc, s’ils le changent de Bob Jones à Sam Smith, comment savez-vous que l’un ou l’autre nom leur appartient ?
), je pourrais choisir d’y investir en écrivant un plug-in…
, mais je l’aurai probablement intégré d’ici ce week-end.