feat(CommentsField): create #1044
Conversation
|
hello, pour ma part je ne suis pas super chaud à créer encore un field pour cela.
C'est pour cela que j'ai mis bazar dans les priorités de la version yeswiki 4.5, en particulier le fait de convertir la table nature en page avec du json, car cela permettrait de plus facilement mettre des options avancées pour les formulaires et donc par exemple de sortir les acls,les themes des fiches, la création d'un user, les titres automatiques, comme des options apparaissant dans l'espace de saisie/modif du formulaire, et pas comme des champs à ajouter au formulaire, ce qui serait à mon avis bien plus compréhensible, l'éditeur de formulaire servant à gérer que les champs apparaissant vraiment. Après vous avez peut être un plan pour utiliser cela rapidement, donc au point où on en est, je ne suis pas contre le fait de rajouter ce champs, mais en validant avec vous que ce comportement changera en version 4.5. |
J9rem
force-pushed
the
feat/comments-field
branch
from
98e232a
to
9dec25d
Compare
|
@mrflos je comprends ta position et effectivement l'état actuel de la partie des champs bazar ne permet pas de rendre lisible les ajouts. L'intérêt de la PR est de proposer un champ Je préfère laisser le soin à @acheype de décider entre
Je continue à ne pas vouloir me prononcer pour ce qui est prévu dans |
|
Ok @acheype dis nous ce qui a ta faveur! |
J9rem
force-pushed
the
feat/comments-field
branch
from
9dec25d
to
e577c4d
Compare
|
On a en effet pas mal parlé de ce champ avec @J9rem lors des spécs. Ce champ Pour le coeur de YesWiki, J'imagine que c'est intéressant aussi de pouvoir laisser un utilisateur renseigner dans la fiche qu'il a saisie, s'il accepte d'avoir des commentaires sur sa fiche. Pour moi, c'est une fonctionnalité qui a sa place dans le coeur. Après je suis pleinement d'accord avec toi @mrflos, le jour où la table nature est transformée en fiche json, et qu'on pourra facilement ajouter des options aux formulaires, plutôt que des champs, c'est clair qu'on pourra transformer ce champ (ainsi que son homologue pour les réactions) en options. Le code étant déjà là, ça ne devrait pas être trop compliqué. Bref, je suis pour qu'on intègre |
|
En regardant de plus près la PR, j'ai remarqué qu'il y avait la valeur par défaut défini pour @J9rem, est-ce que c'est parce que qu'on ne peut pas accéder aux autres champs depuis un champ ? Si oui, j'imagine que quand on passera à des options de formulaire, on pourra alors se baser sur la valeur d' |
|
@mrflos @acheype , merci pour le partage de vos réflexions. A vous lire, je me demande si ça ne serait pas mieux de modifier le champ Avantage:
Inconvénient:
La rétrocompatibilité pour le champ Qu'en dites-vous ? J'attends votre validation à tous les deux avant de coder dans ce sens. Je passe la PR en draft |
|
Yes, ca parait un bon compromis si c'est pas trop compliqué à mettre cela dans le champ acls |
|
Pareil, je valide. Très bonne idée ! |
|
euh oui @acheype , j'étais resté flou mais c'était l'intention. Je vais faire sous 15 jours un commit sur la présente branche, et vous me direz si le format du champ |
J9rem
force-pushed
the
feat/comments-field
branch
2 times, most recently
from
5e5fbff
to
2ae293b
Compare
|
ça y est le champ |
tools/bazar/lang/bazar_fr.inc.php
Outdated
| @@ -278,6 +278,15 @@ | |||
| 'BAZ_CLOSE_THIS_WINDOW' => 'Fermer cette fenêtre', | |||
| 'BAZ_BOOKMARKLET_LABEL' => 'Créer une fiche %{form}', | |||
|
|
|||
| // fields/CommentsField.php | |||
| 'BAZ_ACTIVATE_COMMENTS' => 'Activer les commentaires ?', | |||
There was a problem hiding this comment.
Peut être préciser 'Activer les commentaires sur cette fiche'
There was a problem hiding this comment.
bonne idée, j'ai poussé la modification sur la ranche avant fusion
There was a problem hiding this comment.
Slt,
Désolé de ne pas avoir réagi plus tôt. Pour celui-ci précisément, je ne vois pas l'intérêt d'écrire « sur cette fiche ». Ca me paraît logique vu qu'on est en train d'éditer la fiche en question.
Et vu qu'on essaie de privilégier quand on peut des labels de champ courts, et que dans le LMS on a déjà l'autre champ « Activer les réactions ? », je suis plus pour remettre « Activer les commentaires ? » qu'uniformiser en proposant « Activer les réactions pour cette fiche ? ».
J'attends votre réponse et si vous êtes d'accord, je peux m'occuper du fix pour éviter que tu ais à remodifer Jerem.
Pour l'autre message par contre, c'était une bonne idée !
There was a problem hiding this comment.
Oui, je peux vivre avec, même si je trouve que rajouter "sur la fiche" est plus explicite c'est en effet plus long donc ya des avantage/inconvénients.
Ca me va donc de faire marche arrière si vous préférez, juste un petit point de vigilance à ne pas voir les PR du coeur à travers le prisme du lms seulement, il faut que le label soit clair aussi dans un autre contexte que les activités LMS (ce qui ici me semble le cas)
There was a problem hiding this comment.
Qu'en résulte-t-il de votre décision ?
- remplacer
Activer les commentaires pour cette fiche ?parActiver les commentaires ? - ou remplacer
Activer les réactions ?parActiver les réactions pour cette fiche ?
Dès que vous avez décidé, j'applique la modification.
There was a problem hiding this comment.
J'ai déjà fait le commit et le merge tout à l'heure @J9rem ;)
L'important pour moi était surtout d'uniformiser avec les réactions qui sont maintenant également dans le cœur.
Je n'avais plus en tête que les intitulés des champs étaient au dessus (et non sur le côté), donc il n'y finalement pas de soucis à rajouter « sur cette fiche » et vu que ce semble être ta préférence @mrflos, je suis aller dans ce sens en modifiant le message d'édition des réactions (proposition 2 du commentaire ci-dessus).
There was a problem hiding this comment.
toi aussi tu es aussi rapide que l'éclair @acheype , j'avais pas encore vu ton commit
tools/bazar/lang/bazarjs_fr.inc.php
Outdated
| @@ -215,6 +215,14 @@ | |||
| 'BAZ_FORM_EDIT_BOOKMARKLET_TEXT_LABEL' => "Texte affiché", | |||
| 'BAZ_FORM_EDIT_BOOKMARKLET_TEXT_VALUE' => "Glisser-déposer le bouton dans votre barre de favoris", | |||
|
|
|||
| 'BAZ_ACTIVATE_COMMENTS' => 'Activer les commentaires ?', | |||
| 'BAZ_ACTIVATE_COMMENTS_HINT' => 'Droits mis à jour lors de l\'enregistrement de la fiche', | |||
| 'BAZ_FORM_EDIT_COMMENTS_FIELD_DEFAULT_ACTIVATION_LABEL' => 'Activation des commentaires par défaut', | |||
There was a problem hiding this comment.
Peut être plutôt 'Choix par défaut pour l'activation des commentaires'
There was a problem hiding this comment.
bonne idée, j'ai poussé la modification sur la ranche avant fusion
J9rem
force-pushed
the
feat/comments-field
branch
from
0c2ebc1
to
aef60ef
Compare
|
@J9rem J'ai trouvé un léger bug :
Pourtant j'ai bien l'acl "comments-closed" sur la fiche... |
|
C'est pas un bug, c'est le comportement qui a été spécifié. |
|
merci pour tous ces micro changements / améliorations / échanges, c'est vraiment top! |
|
Merci c'est nickel maintenant ! |
cette PR ajoute le champ
commentsce que ça fait:
commentsSpécifications pour l'amélioration de la gestion des commentaires pour l'extension LMS
Auteur: Jérémy Dufraisse JD
Intentions
Ce document a pour objectif de proposer des spécifications pour améliorer les comportements des commentaires au sein de l'extension
LMSFonctionnement
@j3rem)Spécifications
[R01]: le paramètre
lms_config['use_yeswiki_comments']du fichierwakka.config.phpne DEVRAIT plus officiellement être pris en compte[R02] : le nouveau paramètre DEVRAIT être
lms_config['lms_comments_handler']dans le fichierwakka.config.php[R02.1]: le paramètre
lms_config['lms_comments_handler']DOIT être une chaîne de caractères parmi les valeurs possibles:[R02.2] : un post handler
UpdateHandler__.phpNE DEVRAIT PAS extraire automatiquement la valeur du paramètrelms_config['use_yeswiki_comments']du fichierwakka.config.php[R02.3] : le paramètre
lms_config['lms_comments_handler']DEVRAIT être accessible dans l'action{{editconfig}}[R03] : le handler
YesWiki\Lms\IframeHandler__.phpDEVRAIT prendre en compte le nouveau paramètrelms_config['lms_comments_handler']en remplacement delms_config['use_yeswiki_comments']selon['lms_comments_handler']bf_commentairespour l'activitéexternal_humhubtruedata-external-comments="0"à<head>et ajouter le javascript (*)external_humhubfalseembedded_humhubtruefiche-x...dédié)embedded_humhubfalseyeswikidiscourse""(*): javascript https://gitlab.com/cuzy/humhub-modules-external-websites ou
for-external-website-embedded-in-humhub.jsversion modifiée du dépôt[R03.1] : il DEVRAIT y avoir un fichier
docs/user/en/README.mdcompatible de la doc embarquée à partir deYesWiki 4.3et y indiquant pourembedded_humhuble lien vers la doc https://gitlab.com/cuzy/humhub-modules-external-websites/-/tree/master/docs et un exemple de code js à rajouter dans le templatefiche-x.tpl.html[R04] : l'ensemble des modifications DEVRAIT considérer que la version de
YesWikiest a minimadoyphore v4.2.4[R05] : un nouveau champ bazar DEVRAIT être créé pour le choix d'activer ou non les commentaires
[R05.1] : ce champ DOIT hériter de
SelectField.php[R05.2] : ce champ DOIT avoir un
propertyNamede typebf_commentaires, configurable par le contructeur de formulaire[R05.3] : ce champ DEVRAIT afficher un message d'information si
lms_config['lms_comments_handler']est parmiexternal_humhub,embedded_humhuboudiscoursepour indiquer que les commentaires ne sont pas affichés par YesWiki[R05.4] : le message d'aide du champ pour le choix d'afficher les commentaires DEVRAIT proposer de l'aide ou un lien vers l'aide pour savoir régler les paramètres
[R05.5] : le message d'information PEUT être:
external_humhub:Les commentaires sont gérés par la plateforme sociale HumHub (Humhub intégré par YesWiki)external_humhub:Les commentaires sont gérés par la plateforme sociale HumHub (YesWiki intégré par Humhub)discourse:Les commentaires sont gérés par la plateforme discourse : mais ça n'est pas encore fonctionnel ![R05.6] : le champ DOIT être visible dans le constructeur graphique de formulaire
[R05.7] : lors de l'enregistrement et de l'affichage de la fiche, le champ DOIT mettre à jour les paramètres d'affichage de commentaires de la fiche dans YesWiki en fonction de
['lms_comments_handler']bf_commentairespour l'activitéexternal_humhubcomments-closedembedded_humhubcomments-closeddiscoursecomments-closedyeswikitrueyeswikifalsecomments-closed""trueyeswiki+true""falseyeswiki+falseCommentsFieldCommentsFieldsi ouvertcomments-closed++comments-closed+%comments-closed%@GroupeNamecomments-closed@GroupeNameUserNamecomments-closedUserNamecomments-closedcomments-closed+cette valeur DOIT prendre le dessus sur le comportement du champ
aclset des droits par défautdocs/user/en/README.mdsignalé en [R03.1] ou dans la doc du coeur si le champ est dans le coeurcomments-closed, vide ou+UpdateHander__.phpDOIT remplacer le contenu du formulaire activité pour pointer vers ce nouveau champ:CommentsFielden remplacement delisteListeOuinonLmsbf_commentaires(exemple :comments***bf_comentaires*** *** ***)listeListeOuinonLmsbf_commentairessi elle est existante en préservant le label (texte affiché) et la valeur par défautCommentsField(nom de fichierCommentsField.php)lms_config['lms_comments_handler'] == "yeswiki"etcomments_activated == falseUpdateHander__.phpDOIT remplacer le contenu de toutes les fiches pour renommer la clélisteListeOuinonLmsbf_commentairesenbf_commentairesCommentsFieldPEUT être intégré dans le coeur de YesWiki en faisant attention à adapter le template de rendu de fiche de LMSCommentsFieldDOIT être supprimé dès qu'il est disponible dans une version officielle de YesWikiHistorique des changements
activity_comments=>lms_comments_handler'activity_comments' => ['enabled' => true,'external_comments' => true]"","embedded_humhub","external_humhub","yeswiki","discourse"DEVRAIT extraire le paramètre=> NE DEVRAIT PAS extraire automatiquement la valeur du paramètrelms_config['use_yeswiki_comments']du fichierwakka.config.phpet le remplacer parlms_config['use_yeswiki_comments']du fichierwakka.config.phpactivity_comments=>lms_comments_handleractivity_comments=>lms_comments_handleret adaptation du tableau etlisteListeOuinonLmsbf_commentaires=>bf_commentairesce champ DOIT avoir un=> ce champ DOIT avoir unpropertyNameidentique à celui deSelectField.phppour ne pas avoir à remodifier toutes les ficherspropertyNamede typebf_commentaires, configurable par le contructeur de formulaireactivity_comments=>lms_comments_handleravertissement=>informationactivity_comments=>lms_comments_handler+ adaptation du tableau etlisteListeOuinonLmsbf_commentaires=>bf_commentaireslmsactivitycommentsselect=>CommentsFieldUpdateHander__.php:listeListeOuinonLmsbf_commentaires=>bf_commentairesCommentsFielddans le coeurembedded_humhubajouter le javascript (*)=> ne rien fairedocs/user/en/README.mdfaisant attention au comportement du champaclss'il est présentupdateHandlerCommentsFieldDOIT être suppriméCommentaires en vrac
attention cette PR pointe vers la branchecoms-improvementvu que c'est très lié