Étendre le contrôleur existant ?

[petermarkley]

Salut à tous, j’espère que je poste au bon endroit. J’essaie de développer un plugin pour mon nouveau site web Discourse.

J’ai “forké” le dépôt d’exemple ici, j’ai réussi à faire fonctionner un “Plugin Outlet”, puis j’ai atteint un mur et j’ai commencé à me sentir assez perdu et confus. Je commence à peine à maîtriser les frameworks PHP MVC comme Laravel, mais je suis TRÈS nouveau aux frameworks JS. Je n’ai jamais touché à Ruby, Rails ou Ember auparavant.

Le Problème

Mon site web est pour une communauté de syndicats de copropriétaires (HOA). Ce que j’essaie de faire, c’est collecter et enregistrer quelques champs de données supplémentaires par utilisateur :

• legal_name (string)
• is_owner (bool)
• is_resident (bool)
• building (string) - représentant le numéro de leur bâtiment
• unit (string) - représentant le numéro de leur appartement
• … et quelques autres variables internes, comme si un modérateur les avait confirmés.

Je veux rendre ces champs obligatoires pour l’inscription des utilisateurs. Cela signifie modifier le formulaire d’inscription des utilisateurs. J’ai utilisé l’“outlet” create-account-after-password et j’ai réussi à afficher des champs supplémentaires, mais évidemment, cela ne les rend pas fonctionnels.

Je pense que je dois étendre le contrôleur dans app/assets/javascripts/discourse/app/controllers/create-account.js, non seulement pour récupérer les nouvelles valeurs du formulaire lors de la soumission, mais même pour quelque chose d’aussi (apparemment) basique que l’utilisation du nom du site this.siteSettings.title dans un champ de traduction client.en.yml ! (Pour l’instant, les champs supplémentaires de mon formulaire d’inscription sont intitulés : “Quelle est votre relation avec [valeur %{title} manquante] ?” Ce qui n’est évidemment pas bon.)

Plus j’essayais de chercher des réponses, plus j’avais de questions et plus elles devenaient importantes. Les différents guides que j’ai essayés de suivre étaient apparemment écrits pour différentes versions de Discourse. Le dépôt d’exemple de plugin contient des choses que je ne comprends pas. Quelle est la différence entre une route côté client et une route côté serveur ? Quelle est la différence entre un plugin et un module ? Je suis tellement perdu.

Si quelqu’un pouvait m’offrir de l’aide, je lui en serai très reconnaissant. Merci d’avance.

[Moin]

@petermarkley

Ce que j’essaie de faire, c’est de collecter et de sauvegarder quelques champs de données supplémentaires par utilisateur :

Je pense que vous pourriez faire cela avec Creating and configuring custom user fields

[petermarkley]

Merci ! Cela ne fournit pas toutes les fonctionnalités que je pense vouloir, mais cela me fait certainement réfléchir à la manière dont cette fonctionnalité peut m’aider à atteindre mes objectifs.

Quoi qu’il en soit, je pense que je dois toujours répondre à la question initiale de savoir comment étendre les contrôleurs existants à l’aide d’un plugin. Est-ce possible ?

[Lilly (Lillian Louis)]

@petermarkley

Ce que j’essaie de faire, c’est de collecter et de sauvegarder quelques champs de données supplémentaires par utilisateur

@petermarkley

Cela ne fournit pas toutes les fonctionnalités que je pense vouloir, mais cela me fait certainement réfléchir à la question de savoir si cette fonctionnalité peut m’aider à atteindre mes objectifs.

le sauvegarder pour l’afficher quelque part ? que voulez-vous faire de ces données ? je crois comprendre que vous voulez les stocker pour une autre fonctionnalité plutôt que de simplement les afficher quelque part sur le forum.

[RGJ (Richard - Communiteq)]

@petermarkley

Ce que j’essaie de faire, c’est de collecter et de sauvegarder quelques champs de données supplémentaires par utilisateur :
…
Je veux que ces champs soient obligatoires lors de l’inscription de l’utilisateur. Cela signifie modifier le formulaire d’inscription de l’utilisateur.

Cela peut être accompli sans aucune programmation avec Creating and configuring custom user fields

[petermarkley]

qu’est-ce que vous voulez faire de ces données ? j’ai l’impression que vous voulez les stocker pour une autre fonctionnalité plutôt que de simplement les afficher quelque part sur le forum.

Eh bien, mon espoir/vision ultime était :

1. Modération par niveaux

Accorder aux propriétaires de chaque unité de la communauté des pouvoirs de modération UNIQUEMENT sur les résidents de leur unité.

En gardant à l’esprit qu’il y a près de 200 unités dans notre communauté, il ne semblait pas réalisable d’utiliser la fonctionnalité de groupes pour y parvenir. Voir également le point n° 3 ci-dessous, avec lequel les groupes entreraient également en conflit.

2. Expérience utilisateur d’inscription

L’expérience utilisateur parfaite dans mon esprit ferait également réagir dynamiquement le menu déroulant pour « unité » sur le formulaire d’inscription au choix de l’utilisateur dans le champ « bâtiment », afin de proposer uniquement les unités qui se trouvent dans ce bâtiment. (J’allais trouver un moyen d’analyser un fichier de configuration JSON pour cela lors de l’initialisation de Discourse.)

3. Paramètres de confidentialité des champs

Je voulais offrir à chaque utilisateur le choix de masquer son numéro de bâtiment et/ou d’unité aux autres utilisateurs n’appartenant pas à son unité.

J’ai l’impression que la fonctionnalité de base des champs personnalisés offre cette option uniquement par champ (pas par utilisateur) et également uniquement aux administrateurs, pas aux utilisateurs eux-mêmes.

4. Style fantaisiste

Ce serait plus une cerise sur le gâteau, mais au lieu de l’afficher comme « Propriétaire : oui », je voulais donner au système une connaissance spéciale de ces champs pour les styliser différemment sur les résumés d’utilisateurs. Comme mettre une icône de titre SVG, et une coche si un modérateur a confirmé leur statut (ou une icône de maison pour les résidents). Ce genre de chose.

Alors, oui…

Peut-être que je suis trop exigeant ici, mais j’ai l’impression qu’une fois que j’aurai surmonté la courbe d’apprentissage pour accomplir la fonctionnalité principale, les éléments de la liste de souhaits plus petits deviendront presque triviaux.

Beaucoup de résidents de ma communauté sont des personnes âgées avec peu ou pas de connaissances informatiques. J’ai de sérieuses inquiétudes quant au fait que certains résidents ne voudront pas adopter et utiliser mon site Web Discourse simplement parce qu’il est nouveau et pas Facebook, sans parler des problèmes d’utilisation réels comme la confidentialité des adresses ou la saisie non validée des numéros de bâtiment/unité.

[RGJ (Richard - Communiteq)]

@petermarkley

Compte tenu qu’il y a près de 200 unités dans notre communauté, il ne semblait pas réalisable d’utiliser la fonctionnalité de groupes pour y parvenir. Voir aussi le point n°3 ci-dessous, avec lequel les groupes entreraient également en conflit.

Les groupes fonctionneront très bien à cette fin, et vous pouvez facilement avoir 200 groupes.
Il vous suffirait de mapper manuellement ou par programmation le champ sur un groupe. Mais vous pourriez aussi vouloir que les gens envoient une sorte de « preuve » après l’enregistrement.
Vous pourriez le faire manuellement, coder cela vous-même, utiliser le plugin de sorcier personnalisé de Pavilion pour cela.

@petermarkley

Mon impression est que la fonctionnalité principale des champs personnalisés n’offre cette option que par champ (pas par utilisateur)

C’est vrai, mais vous pourriez avoir des utilisateurs qui souhaitent rendre ce champ public ailleurs, c’est-à-dire avoir un champ de bâtiment « privé » et un champ de bâtiment « public ».

[pfaffman (Jay Pfaffman)]

Si vous avez besoin d’ajouter des fonctionnalités, vous voulez créer un composant de thème ou un plugin, pas un fork de Discourse.

@petermarkley

Expérience utilisateur d’inscription

Vous pouvez le faire dans un composant de thème, vous n’avez donc pas besoin d’un plugin pour cela, mais si vous créez un plugin, vous pouvez également inclure les modifications du côté client dans le plugin. Développement de plugins Discourse - Partie 1 - Créer un plugin de base. Rechercher des plugins qui ajoutent des fonctionnalités similaires est également une bonne approche. Il existe un dépôt Discourse appelé all-the-plugins que vous pouvez utiliser pour rechercher des exemples.

@petermarkley

Paramètres de confidentialité des champs

Avoir des versions publiques ou privées de ces champs, comme suggéré, semble être une bonne solution, mais vous pouvez également ajouter des champs utilisateur dans un plugin et contrôler comment et si ces champs sont ajoutés au sérialiseur pour les afficher.

@petermarkley

Style fantaisiste

C’est ce que font les composants de thème. Guide de référence rapide pour les développeurs de thèmes pourrait être un début.

[RGJ (Richard - Communiteq)]

@pfaffman

vous voulez créer un plugin ou un composant de thème, pas un fork de discourse.

Je ne pense pas que TS ait eu l’intention de forker discourse??

@petermarkley

J’essaie de développer un plugin pour mon nouveau Discourse

[pfaffman (Jay Pfaffman)]

@RGJ

Je ne pense pas que TS ait eu l’intention de créer un fork de discourse ??

Il semble que le dépôt qu’il a lié soit un fork et non un plugin.

[RGJ (Richard - Communiteq)]

Forker discourse-plugin-skeleton semble être un bon point de départ pour écrire un plugin pour moi…

[pfaffman (Jay Pfaffman)]

D’accord ! Je ne sais pas ce que je crois avoir vu ! Je ne sais pas comment j’ai pu manquer que c’était une fourche.

Je pensais avoir cherché plugin.rb…

[Lilly (Lillian Louis)]

C’est bon, j’ai appris des choses grâce à cette conversation

[petermarkley]

Merci @RGJ de m’avoir clarifié cela ! Oui, je n’aurais certainement jamais forké Discourse juste pour ça.

[petermarkley]

vous pouvez également ajouter des champs utilisateur dans un plugin et contrôler comment et si ces champs sont ajoutés au sérialiseur pour les afficher.

Cela inclut-il de les ajouter au formulaire modal « créer un compte » et de les rendre obligatoires ? Pouvez-vous m’indiquer des exemples ou des guides sur la façon de procéder ?

J’ai déjà lu l’intégralité du guide que vous avez lié « Développement de plugins Discourse ». C’est par là que j’ai commencé. Au final, la seule fonctionnalité réelle qu’il montre comment étendre est la création d’une nouvelle page d’administration avec un tentacule violet. J’ai déjà une page d’administration qui fonctionne pour mon plugin, mais je ne suis même pas sûr d’en avoir besoin. Elle n’est pas liée aux problèmes actuels qui se posent à moi, donc leur exemple n’est pas très utile dans mon cas.

[petermarkley]

Les groupes fonctionneront bien à cette fin, et vous pouvez facilement avoir 200 groupes

Il faudrait en fait entre 400 et 600 pour couvrir toutes les permutations (propriétaire, résident ou affilié de chaque unité). Mais comment cela fonctionnerait-il ? 200 groupes peuvent-ils tous s’afficher de manière identique pour les utilisateurs, de sorte qu’il dise simplement « Propriétaire » au lieu de « Propriétaire 187 » ou quelque chose comme ça ?

C’est une question plus pointue, mais un identifiant de groupe interne est-il exposé aux utilisateurs finaux quelque part, par exemple dans une URL ? Si un utilisateur a défini le numéro de son unité comme privé, quelqu’un pourrait-il le découvrir en comparant l’identifiant du groupe à d’autres utilisateurs ?

Il me semble que j’obtiendrais peut-être de meilleurs résultats en créant seulement 3 groupes (propriétaire, résident et affilié - ou seulement 2 : propriétaire et résident). Peut-être que je pourrais attribuer ces groupes de manière appropriée comme vous l’avez dit, puis bloquer certaines actions si l’utilisateur essaie de modérer un résident de la mauvaise unité ?

Je suppose que si le blocage d’une action comme celle-ci est totalement impossible, alors oui, je suis coincé avec la création de 600 groupes… et j’espère simplement que nous n’aurons aucun utilisateur ayant des idées astucieuses pour « pirater » le système et dénoncer qui que ce soit.

[pfaffman (Jay Pfaffman)]

@petermarkley

Accorder aux propriétaires de chaque unité de la communauté des pouvoirs de modération UNIQUEMENT sur les résidents de leur unité.

Attendez. Quoi ? Donc, si je suis locataire et que je dis quelque chose sur le forum, mon propriétaire peut changer mes mots ? Les sujets n’appartiennent qu’à une seule catégorie, vous auriez donc des conversations qui ne se déroulent qu’entre le propriétaire et le locataire.

Cela n’a pas de sens. Et il n’y a vraiment aucun moyen facile d’avoir des permissions au niveau du sujet.

Je penserais que vous voudriez des groupes et des catégories par bâtiment, mais le contrôle par unité n’a tout simplement pas de sens.

[petermarkley]

Je n’ai rien dit au sujet des permissions au niveau des sujets.

Peut-être que le mot « modérateur » est inapproprié ? Je ne sais pas. (Je n’ai jamais utilisé Discourse avant maintenant.)

Je parle d’approuver ou de supprimer l’accès au forum par utilisateur. Donc non, votre propriétaire ne peut pas changer vos mots, mais c’est lui qui a l’autorité pour confirmer votre inscription en tant que résident, et si vous devenez un troll, il peut vous mettre en sourdine ou vous bannir. Les publications et les sujets sont modérés de manière égale par rapport à une politique de contenu, par le personnel du site web, et non par les propriétaires.

Mon objectif est de lier l’accès au forum autant que possible à la chaîne d’autorité légale sur chaque propriété elle-même. Aucun propriétaire confirmé qui possède légalement une propriété ici ne devrait jamais être banni, mais s’il publie quelque chose qui enfreint la politique, cette publication peut être supprimée par le personnel. Cependant, s’il vend la propriété, son statut de « propriétaire » est immédiatement révoqué, résultant éventuellement à sa suppression du site web (sauf s’il opte pour un statut « affilié » et est approuvé par le nouveau propriétaire de la propriété).

Dans notre communauté, il n’y a aucune relation entre une unité et une autre dans le même bâtiment, sauf qu’elles sont physiquement attachées. C’est tout. Regrouper les gens par bâtiment est pratiquement une décision cosmétique d’expérience utilisateur ; désigner des autorités sur des bâtiments entiers n’aurait aucun sens ici.

[petermarkley]

J’ai trouvé ceci : Add a custom per-user setting in a plugin

Dans les commentaires, un utilisateur a dit qu’il avait « patché un contrôleur ». Il a un fichier .js.es6 dans assets/javascripts/discourse/initializers/ qui fait référence à une méthode appelée api.modifyClass()…

Hmmm Peut-être que je suis sur la bonne piste.

[pfaffman (Jay Pfaffman)]

Ouais ! C’est ça !

Je vous conseille de vous familiariser davantage avec le forum avant de décider de ce que vous voulez faire.

Je pense qu’il serait plus facile si un petit groupe de personnes approuvait les nouveaux membres plutôt que chaque propriétaire d’une unité ne contrôle également l’accès au site. Si les propriétaires sont ceux qui décident, que se passe-t-il lorsque quelqu’un vend son unité ? Qui déciderait alors ? Qu’en est-il d’un propriétaire qui ne se soucie pas que son locataire puisse être membre du forum ? Je pense que laisser cela au gérant de la résidence aurait beaucoup plus de sens et ne nécessiterait probablement pas de plugin.