Amélioration de la documentation embarquée

Cf cette ébauche de Readme : https://md.yeswiki.net/e9kPN6HHQUyrxKXC46OLHg?both#

• Url dédiée ?doc
• Début de restructuration des fichiers
• Téléchargement des images depuis la doc en ligne
• Amélioration de la visibilité du menu
• Suppression des langues autre que français
• Affichage de la doc avec la langue du wiki. Suppression du sélecteur de langue
• Affichage de code yeswiki executé via une iframe

Comment tester

[[En allant sur ?doc](En allant sur ?doc)](http://localhost:81/?doc)

Yo !

voilà je pense que la PR est prête pour review. Niveau code, il y a beaucoup de commits et changements, donc le ieux est peut être plutot de regarder l'état final : AceditAction.php aceditor.js etc..

Il y aura aussi besoin d'un bonne série de tests ! Candidate potentielle pour la release 4.4

Voilà le contenu

Amélioration de la création de page

Modal de création/édition de lien simplifiée

Nouveau bouton pour créer une page

Petit crayon pour éditer les liens

Ancienne syntaxe de lien de nouveau par default

Lorsque je crée un lien depuis si le lien s'ouvre dans l'onglet courant alors il utilise la syntaxe classique [[Lien texte]] puisqu'il y a maintenant le lien pour l'éditer

Autocompletion pour les lien et les actions

Plusieurs aceditor par page

Les composants marchent maintenant dans chaque editeur

Refactor Aceditor

J'ai regroupé et converti pas mal de bout de code qui étaient éparpillées et qui fonctionnait indépendamment, rendant assez dur à suivre le fonctionnement de aceditor

Maintenant il y une action AceditorAction (qui s'invoque depuis un twig avec le nouveau helper renderAction)

{{ renderAction('aceditor', { saveButton: true, name: 'body', value: body })|raw }}

Cependant, du au fait que l'on ne peut pas mettre un élément HTML form dans un autre, il faut aussi ne pas oublier d'inclure les différentes modals via un {{ include('@aceditor/aceditor-modals.twig') }}

Ensuite la classe javascript Aceditor va s'initialiser pour chaque éditeur de la page, gérer la toolbar, gérer les aide à la saisie de l'éditeur (autocompletion, petit crayon pour éditer les actions et les liens), et initialiser les différentes modals (actions-builder, files, link...)

Refactor handler edit

Pareil y'avait plusieurs bout de code éparpillé, du à l'utilisation des callback edit__.php. J'en ai regroupé certains, mais pas tous. Il y aura encore les actions relatives aux tags et au selecteur de thème à refactorer pour les inclure directement dans handlers/edit.twig

Voilà là proposition qu'on fait avec florian :

On garde le système actuel de build de version (https://github.com/YesWiki/yeswiki-build-repo + https://github.com/YesWiki/yeswiki-config-repo/blob/master/repo.config.json)

On utiliserait maintenant 2 versions (en plus de cercopitheque)

• une version "stable" qui se base sur des tags publiés de manière ponctuelle, genre "4.1.12". c'est la version utilisée par default i.e. {{ update }}
• une version "dev/test" qui se base sur le dernier commit de la branche doryphore. Réservée aux utilisateurs avancés qui configureront leur wiki avec {{ update version="nom_de_cette_version_test" }}

Pour le nom de ces deux versions, soit on continue un naming aligné sur les version majeure (perso je pense que c'est le plus simple) version stable: "doryphore" version test: "doryphore-test" puis on aura pareil avec ectoplasme

Soit on prend un nom generique et on assure le passage d'une version majeure à une autre version stable : "stable" version test: "test"

Pour les commits :

• Création d'une nouvelle branche doryphore-dev (ou peut être tout simplement dev): tous les commits arriveront désormais sur cette branche, via PR ou en direct
• Quand on juge que y'a assez de nouvelles features pour une release, on fast forward doryphore vers doryphore-dev (ou on merge si on peut pas fast forward). La future release sera en phase de test, accessible via {{ update version="doryphore-test" }}
• Si des bugs sont trouvés, un commit de fix est poussé sur doryphore-dev, puis copié sur doryphore (git cherry pick)
• Si de nouveaux devs sont fait entre temps, ils sont poussés sur doryphore-dev, mais ne seront pas mergés dans doryphore (on est en feature freeze)
• Quand on a assez joué avec la version "test" et que y'a plus de bugs (ici on peut prendre vraiment le temps de tester, genre 1 mois, d'ou l’intérêt d'avoir la branche doryphore-dev pour continuer à faire d'autres devs), on créé un nouveau tag sur doryphore en incrémentant la version. Tous les utilisateurs auront donc accès à la nouvelle version via ce tag

Intégration continue

Si on se chauffe, y'a l'idée de déclencher le build des versions dès que y'a un push sur doryphore ou un nouveau tag créé. On pourrait même mettre à jour automatiquement testing.yeswiki.net avec la version test dès que y'en a une publiée

Voilà pour les grandes, lignes, ça vous botte?

11 mars 2021:mise à jour de cet en-tête Intention principale : pouvoir éviter que les anciens champs restent présents dans une fiche.

• modification de EntryManager pour la méthode de fusion des données lors de l'update (ne pas ajouter les anciennes données mais que celles qui correspondent à un champ).
• mise à jour de quelques Fields pour rester compatibles avec canEdit
• refacto pour la gestion des anciens champs sous forme de fonction (parce que ça devenait trop compliqué de maintenir la rétrocompatibilité comme le code était, maintenant c'est plus simple).
• refacto du Guard pour prendre en compte directement les BazarField
• corrections de quelques erreurs dans le EntryManager

Tests du 11 mars 2021 Tests #670.zip

Cette PR semble intégrer des modifications qui ne sont pas prioritaires. Toutefois, elle permet de résoudre le problème de données en trop (BUG) et aussi facilite la correction des autres futurs bugs. C'est pour ceci que je me permets de le proposer sur Doryphore et non Ectoplasme

Texte d'avant

Lors de la mise à jour d'une fiche, il y a pour le moment fusion entre les anciennes données et les nouvelles données. Conséquence:

• ça permet de reconstruire les données manquantes qui auraient pu disparaître lors du passage sur le navigateur du client.
• ça complique la remise à zéro des données en tableau comme les checkbox
• ça ne permet pas de supprimer les anciennes données qui ne sont plus utilisées.

Le correctif que je propose permet de continuer de récupérer les anciennes données sans garder les données qui sont maintenant inutiles.

Je te sollicite @acheype dans un premier temps pour avoir ton avis. Qu'en penses-tu ? J'ai ouvert une PR pour permettre un espace d'échange facilité. Elle est en brouillon car elle n'est pas prête à être fusionnée. N'importe qui peut se joindre à cette discussion voire faire une revue. :wink:

J'ai des questions sur la possibilité de déplacer la sauvegarde des données des champs non accessibles en écriture dans les champs dédiés.

ET je n'ai pas encore fait tous les tests

Cette PR permet d'introduire une fonctionnalité d'archivage asynchrone du wiki. Spécifications pour cette PR : https://pad.lescommuns.org/YmnJJPjJRMGj7EhAlD1eZg#

Pour tester:

• faire /update une fois sur la branche feat/archive
• penser à faire un composer install juste au cas où
• se rendre sur la page GererMisesAJour :
  • il y a alors un bouton "Gérer les sauvegardes"
  • une sauvegarde est lancée avant chaque mise à jour

Matrice de couverture de la spécification: |Numéro|Nom|Implémenté|Testé|Commentaire| |:-|:-|:-|:-|:-| |[R01]|console + command spécifique|[x]|[x]|| |[R02]|command avec params|[x]|[x]|| |[R02.1]|params pour choix sql, fichiers ou tout|[x]|[x]|| |[R02.2]|par défaut tout|[x]|[x]|test par lecture du code| |[R02.3]|nom des fichiers|[x]|N.A.|voir constantes dans ArchiveService| |[R02.4]|params extrafiles|[x]|[x]|test manuel| |[R02.4.1]|params extrafiles chemins relatifs|[x]|[x]|test phpunit| |[R02.4.2]|params extrafiles OK pour dossiers|[x]|[x]|test manuel| |[R02.4.3]|params extrafiles OK pour sous-dossiers|[x]|[x]|test manuel| |[R02.4.4]|params extrafiles compatible glob|[x]|[x]|test manuel| |[R02.4.5]|params extrafiles save dans wakka.config.php du zip|[x]|[x]|test phpunit| |[R02.4.6]|params extrafiles configurable via frontend|[x]|[x]|tests manuels| |[R02.4.8]|params extrafiles save dans wakka.config.php du zip sous forme de tableau|[x]|[x]|test phpunit| |[R02.4.9]|params extrafiles ne doit tenir compte que des chemins inclus dans le dossier de tête|[x]|[x]|test phpunit| |[R02.5]|params excludedfiles|[x]|[x]|test hors phpunit| |[R02.5.1]|params excludedfiles chemins relatifs|[x]|[x]|test phpunit| |[R02.5.2]|params excludedfiles OK pour dossiers|[x]|[x]|test phpunit| |[R02.5.3]|params excludedfiles compatible glob|[x]|[x]|test hors phpunit| |[R02.5.4]|params excludedfiles save dans wakka.config.php du zip|[x]|[x]|test phpunit| |[R02.5.5]|params excludedfiles configurable via frontend|[x]|[x]|tests manuels| |[R02.5.6]|params excludedfiles save dans wakka.config.php du zip sous forme de tableau|[x]|[x]|test phpunit| |[R03]|permettre l'anonymisation de wakka.config.php|[x]|[x]|test phpunit| |[R03.1]|anonymisation de wakka.config.php réglable par un paramètre|[x]|[x]|test phpunit| |[R03.2]|anonymisation de wakka.config.php valeurs par défaut|[x]|[x]|test phpunit| |[R03.3]|anonymisation de wakka.config.php save dans wakka.config.php|[x]|[x]|| |[R03.4]|anonymisation wakka.config.php avec tableaux aussi|[x]|[x]|test phpunit| |[R03.5]|anonymisation wakka.config.php avec tableaux : format|[x]|[x]|test phpunit| |[R04]|un controlleur pour appeler la CLI|[x]|[x]|test phpunit| |[R04.1]|un controlleur dans includes|[x]|[x]|test par lecture du code; c'est un service| |[R04.2]|le controlleur fournit les paramètres d'anonymisation|[x]|[x]|test phpunit| |[R04.3]|les paramètres d'anonymisation ne peuvent être réglés par le frontend|[x]|N.A.|vérifiaction en lisant le code| |[R05]|la CLI vérifie le dossier n'est pas sur le web|[x]|[x]|tests manuel en suppriment .htaccess| |[R05.1]|chemin de sauvegarde dans wakka.config.php|[x]|[x]|test manuel| |[R05.2]|chemin de sauvegarde configurable via {{editconfig}}|[x]|[x]|test manuel| |[R06]|mode hibernate pendant la sauvegarde|[x]|[x]|proposition de créer un mode archiving| |[R07]|archivage sur PID différent|[x]|[x]|test phpunit + test manuels| |[R07.1]|utilisation possible de symfony/process|[x]|[x]|| |[R07.2]|pouvoir arrêter la CLI|[x]|[x]|test manuel| |[R07.3]|fournit un état instantané de la CLI|[x]|[x]|test manuel| |[R07.4]|communication avec la CLI via un fichier|[x]|[x]|test manuel| |[R08]|zip avec arborescence similaire au yeswiki|[x]|[x]|test phpunit| |[R08.1]|sauvegarde sql dans zip|[x]|[x]|test phpunit| |[R08.4]|sauvegarde sql dans zip private/backups|[x]|[x]|test phpunit| |[R08.5]|private/backups avec .htaccess et README|[x]|[x]|test phpunit| |[R08.6]|pas d'assurance de la sécurité des données|[x]|N.A.|| |[R09]|téléchargement du fichier sans lien direct|[x]|[x]|test manuel| |[R10]|pas de sauvegarde pendant une autre sauvegarde|[x]|[x]|test phpunit| |[R11]|vérification de l'espace disque avant de lancer une sauvegarde|[x]|[x]|test manuel| |[R11.1]|règle pour la marge d'espace disque|[x]|[x]|choix taille files + custom + 300 Mo| |[R12]|limiter le nombre de sauvegardes à 10|[x]|[x]|test manuel| |[R12.1]|toujours supprimer la plus ancienne|[x]|[x]|test manuel ! conserve toujours au moins une archive qui a deux jours| |[R12.2]|demander une confirmation du frontend avant suppression|[x]|[x]|test manuel| |[R21]|frontend via {{adminbackups}}|[x]|[x]|test manuel| |[R21.1]|pas d'impact dans {{update}}|[x]|N.A.|| |[R22]|{{adminbackups}} gestion des sauvegardes précédentes|[x]|[x]|test manuel| |[R22.1]|{{adminbackups}} actions : liste/télécharger/supprimer|[x]|[x]|test manuel| |[R22.2]|{{adminbackups}} actions : laisser la possibilité pour "restaurer"|[x]|N.A.|le code frontend contient déja des bouts de codes en commentaires| |[R23]|{{update}} lancer une sauvegarde automatique avant update|[x]|[x]|tests manuels| |[R23.1]|{{update}} sauvegarde auto contournable|[x]|[x]|tests manuels| |[R23.2]|{{update}} sauvegarde auto contourné = confirmation requise|[x]|[x]|tests manuels| |[R23.3]|{{adminbackups}} permet une sauvegarde manuelle|[x]|[x]|tests manuels| |[R23.4]|{{adminbackups}} permet la configuration de la sauvegarde|[x]|[x]|tests manuels| |[R23.5]|{{update}} sauvegarde auto contournable uniquement si param dans wakka.config|[x]|[x]|tests manuels| |[R24]|{{adminbackups}} VueJS possible|[x]|[x]|usage de VueJs avec syntaxe compatible vuejs 2 et 3| |[R25]|{{adminbackups}} appel routes API|[x]|[x]|| |[R25.1]|{{adminbackups}} appel routes API en ajax|[x]|[x]|| |[R25.2]|{{adminbackups}} suivi CLI en dynamique|[x]|[x]|test manuel| |[R25.3]|{{adminbackups}} permettre arrêter la CLI|[x]|[x]|test manuel| |[R25.4]|{{adminbackups}} rafraichissement mini 5 sec|[x]|[x]|test manuel| |[R26]|route API pour lancer la sauvegarde|[x]|[x]|test manuel| |[R26.1]|route API pour lancer la sauvegarde sauf si pas assez d'espace|[x]|[x]|test manuel| |[R26.2]|route API pour lancer la sauvegarde suppression auto de la plus ancienne si > 10|[x]|[x]|test manuel| |[R26.3]|route API pour lancer la sauvegarde limite 2 par jours maxi|N.A.|N.A.|non réalisable car c'est la même route api|

N.A. : non applicable

Je travaille en ce moment à réutiliser les facettes pour qu'elles puissent effectuer des filtrages au niveau de la vue ProgressDashboard du LMS. Je propose ces deux commit pour rendre plus clair le code.

Cette pull-request a pour objectif d'améliorer le fonctionnement de l'action {{newtextsearch}} en s'inspirant de ce qui a été fait sur un wiki existant de Villeurbanne

Ceci est d'abord une pull-request draft, qui propose les améliorations en se basant sur des développements custom. Ne pas prendre le code proposé comme valide pour fusion tant que les spécifications ne sont pas validées. le code est d'abord proposé comme base de travail des spécifications qui peuvent invalider tout ou partie des modifications courantes.

Proposition de spécifications:

Spécification pour amélioration de l'action {{newtextsearch}}

• [R01] : l'action {{newtextsearch}} DOIT être réécrite dans le nouveau format dans le fichier NewTextSearchAction.php
• [R02] : le fichier docs/actions/advanced-actions.yaml DOIT être à jour par rapport aux modifications apportées concernant {{newtextsearch}}
• [R03] : l'action {{newtextsearch}} DOIT maintenant proposé un template twig par défaut newtextsearch.twig qui affiche les résultats comme avant
• [R04] : un nouveau template newtextsearch-by-form.twig devrait aussi être créé
• [R04.1] : le nouveau template de [R04] DOIT permettre l'affichage des résultats classés par formulaires ou types de données
• [R04.2] : le nouveau template de [R04] DEVRAIT afficher les données en colonnes.
• [R04.2] : le nouveau template de [R04] DEVRAIT utiliser le nouveau paramètre nbcols pour déterminer le nombre de colonnes
• [R04.3] : le nombre de colonnes du nouveau template de [R04] DOIT être entre 1 et 3
• [R04.4] : si le parmaètre nbcols vaut 0 pour le nouveau template de [R04], alors la mise en colonne DEVRAIT se faire automatiquement en fonction de la largeur du contenu
• [R04.5] : le nouveau template de [R04] DEVRAIT affiché les résultats classés par catégories
• [R04.6] : le nouveau template de [R04] NE DOIT PAS être le template par défaut
• [R04.7] : le nouveau template de [R04] DEVRAIT créer autant de lignes que nécessaire pour respecter le nombre de colonnes demandées
• [R04.8] : le nouveau template de [R04] PEUT être un affichage dynamique
• [R05] : le paramètre displaytype DEVRAIT être utilisé par les deux templates pour déterminer le type d'affichage selon:
  • modal : fenêtre modale
  • link : fenêtre courante
  • newtab : nouvel onglet
• [R05.1] : la valeur par défaut de displaytype DEVRAIT être modal
• [R06] : le paramètre displaytext DEVRAIT être utilisé uniquement par le deux templates pour déterminer s'il faut afficher le texte des résultats
• [R06.1] : les valeurs de displaytext PEUVENT être:
  • true pour forcer l'affichage du texte
  • false pour ne pas afficher le texte
  • "" pour n'afficher le texte que pour le template par défaut (c'est la valeur par défaut)
• [R06.2] : displaytext NE DEVRAIT être configurable qu'avec les paramètres avancés de composants
• [R07] : le paramètre displaytypes DEVRAIT être utilisé par le nouveau template de [R04] pour déterminer ce qu'il faut afficher et dans quel ordre
• [R07.1] : si le paramètre displaytypes est vide, le nouveau template de [R04] DEVRAIT afficher les résultats classés par formulaire pour les fiches, par ordre croissant de nom de formulaire suivi d'un bloc avec les pages sans les pages de logs
• [R07.2] : le paramètre displaytypes PEUT accepter les syntaxes suivantes, séparées par des virgules
  • un nombre : pour un formulaire spécifiques
  • page ou pages : pour les pages sans les pages de logs
  • logpage, logpages, logspage, logspages : pour les pages de logs
  • tag:<nom-du-tag> (ex: tag:catégorie: 1 pour le tag catégorie: 1)
• [R07.3] : si un résultat appartient à la fois à un tag et à la fois à un bloc page, logpage ou formId (un formulaire), ce résultat PEUT être afficher en doublon dans les deux catégories
• [R07.4] : le paramètre displaytypes DEVRAIT pouvoir être saisi facilement depuis les composants (en développant un Input dédié si nécessaire)
• [R08] : le paramètre titles DEVRAIT être utilisé par le nouveau template de [R04] pour déterminer le titre de chaque bloc
• [R08.1] : la syntaxe du paramètre titles DEVRAIT être une concaténation de texte, chaque titre étant séparés par des virgules, classés dans le même ordre que le paramètre displaytypes
• [R08.2] : si un titre est vide (ex: 1.Titre non vide 1,,3.Titre non vide 2), celui-ci DEVRAIT être remplacé par :
  • le label du formulaire pour les formulaires
  • Pages pour les pages (+ traductions)
  • Log pages pour les pages de logs (+ traductions)
  • Nom du tag pour les tags
• [R09] : le paramètre limit DEVRAIT être utilisé par le template d'origine pour limiter le nombre total de résultats fournis
• [R09.3] : le paramètre limit DEVRAIT avoir pour valeur par défaut 10
• [R09.4] : le paramètre limit DEVRAIT automatiquement être remplacer par sa valeur par défaut si sa valeur initiale est inférieure ou égal à 0
• [R09.6] : le paramètre limit DEVRAIT automatiquement être remplacer par sa valeur par défaut si sa valeur initiale est inférieure strictement à 0
• [R09.7] : le paramètre limit DEVRAIT uniquement être utilisé par le nouveau template de [R04] pour déterminer le nombre maximum de résultats par catérgorie
• [R10] : le nouveau template de [R04] DEVRAIT proposer un bouton voir plus quand la limite est atteinte par limit
• [R10.2] : le bouton voir plus NE DEVRAIT PAS recharger la page pour n'afficher que les résultats de la catégorie concernée sans limite
• [R10.3] : le bouton voir plus DEVRAIT mettre à jour la liste des résultats concernant la catégorie de façon dynamique
• [R11] : le clic sur un résultat PEUT ouvrir la page avec une ancre au bon endroit
• [R11.3] : les actions show__ et iframe__ DEVRAIT prendre en compte $_GET['searchAnchor'] afin d'ajouter à la volée une ancre pour faciliter la navigation

Changements

• 2022-08-31 [JD]:
  • [R04.6] ~~DEVRAIT~~ => NE DOIT PAS
  • [R04.7][R04.8] ajout
  • [R09] ~~tous les templates~~ => le template d'origine
  • [R09.1] suppression : ~~le paramètre nbbytypes DEVRAIT uniquement être utilisé par le nouveau template de [R04] pour déterminer le nombre maximum de résultats par catérgorie~~
• [R09.2] suppression : ~~le paramètre limit DEVRAIT être prioritaire sur le paramètre nbbytypes~~
• [R09.3] ajout de par défaut 100 pour le template d'origine est 10 pour le nouveau template
• [R09.5] suprresionn ~~: le paramètre nbbytypes DEVRAIT avoir pour valeur par défaut 0, ce qui correspond pas de limite~~
• [R09.7] : ajout
• [R10] : nbbytypes => limit
• [R10.1] suppression : ~~le bouton voir plus DEVRAIT recharger la page pour n'afficher que les résultats de la catégorie concernée mais sans limite de nbbytypes (en gardant la limite de limit)~~
• [R10.2][R10.3]: ajout
• [R11.1] suppression : ~~un handler avec le nom /anchor PEUT être créé afin d'ajouter à la volée une ancre pour faciliter la navigation~~
• [R11.2] suppression : ~~un handler /anchoriframe PEUT être aussi créé pour le contexte iframe~~
• 2022-09-07 [JD]:
  • [R07.2] : suppression de
    • ~~tagonpage:<nom-du-tag> (ex: tagonpage:catégorie: 1 pour le tag catégorie: 1 concernant que les pages)~~
    • ~~tagonforms:<nom-du-tag> (ex: tagonforms:catégorie: 3 pour le tag catégorie: 3 concernant que les fiches)~~
    • ~~tagonformXX,XX:<nom-du-tag> (ex: tagonform1,33:catégorie: 3 pour le tag catégorie: 3 concernant que les fiches des formulaires 1 et 33)~~
    • [R09.3] : valeur par défaut 10 (au lieu de différencier pour chaque template)
    • [R11.3] : ~~$_GET['search_anchor']~~ => $_GET['searchAnchor']

Ce que fait la branche en l'état

• refactor de {{newtextsearch}}
• création d'un nouveau template avec affichage par colonne des résultats groupés par formulaire
• ajout des paramètres existant dans advanced-actions.yaml
• ajout des nouveaux paramètres liés au nouveau template
• l'affichage est maintenant dynamic

Pour tester la branche en l'état

• dans une page, utilisez le bouton composants > Actions avancées > Recherche de texte pour ajouter l'action {{newtextsearch}}
• régler à votre convenance les nouveaux paramètres
• faire une recherche et apprécier

toutes les url commençant par ?api renvoient une 401. https://gogowiki.teritorio.xyz/?api/fiche/1

Et depuis le dashboard bazar, le lien vers l'api JSON est incorrect, il renvoie vers ?api/fiche/FORM_ID au lieu de ?api/form/FORM_ID

Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) New feature / Nouvelle fonctionnalité Bug / Bogue

Description Suite à une mise à jour de wikis vers la version doryphore 2021-01-11-3, écran blanc (un des wikis est tout neuf, sans contenu original, justement pour tester)

Additionnal informations / Informations complémentaires

• doryphore 2021-01-11-3
• http://carto.hinaura.fr/?PagePrincipale
• logs Fatal error: Uncaught Error: Call to undefined function YesWiki\loadTemplates() in /srv/data/web/vhosts/carto.hinaura.fr/htdocs/includes/YesWiki.php:1776 Stack trace: #0 /srv/data/web/vhosts/carto.hinaura.fr/htdocs/includes/YesWiki.php(97): YesWiki\Wiki->loadExtensions() #1 /srv/data/web/vhosts/carto.hinaura.fr/htdocs/index.php(69): YesWiki\Wiki->__construct() #2 {main} thrown in /srv/data/web/vhosts/carto.hinaura.fr/htdocs/includes/YesWiki.php on line 1776

Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) New feature / Nouvelle fonctionnalité

Description Si ça n'existe pas déjà ce serait super d'avoir une action qui permette d'afficher du contenu (bouton, HTML, ou autre...peu importe) uniquement pour tel ou tel utilisateur (suivant une ACL quoi). Dans mon cas par exemple je souhaite afficher un bouton "ajouter un évènement" à un calendrier qui mène vers la bonne page d'admin mais que ce bouton ne s'affiche que pour les @admins évidemment.

Additionnal informations / Informations complémentaires

• version of YesWiki / version de YesWiki Doryphore

YesWiki est de plus en plus installé comme une plateforme de service SAAS, et afin de pouvoir bénéficier des modifications de code sur les plateforme, il nous faudrait utiliser la licence AGPL. cf. https://www.gnu.org/licenses/why-affero-gpl.html

Pour éviter de devoir faire un fork sous cette licence, il faudrait que tous les contributeurs de YesWiki consentent au passage à cette licence.

Pour cela il nous faudrait le consentement explicite des contributeurs suivants: @mrflos @daviddelon @Cyrille37 @gatienbataille @daiko @furax37 @LouiseQuincaillere @sylvainboyer @flabastie @acheype @jpmilcent @srosset81 @benrubson @sudwebdesign @geigerni

Merci de laisser un commentaire avec votre consentement... ... ou pas ;)

Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) Bug / Bogue

Description Voici un cas d'utilisation pour reproduire le bug sur un environnement de dev local :

• je me connecte en n'oubliant pas et note l'heure (par exemple 14:00)
• une fois connecté, je rafraîchis la page ce qui confirme que les informations de sessions sont retrouvées
• je change l'heure du serveur (je mets 1h30 de plus pour être sûr que la session soit expirée)
• en réactualisant la page, quand je clique sur la roue crantée, je vois que je ne suis plus connecté

Sur mon ordinateur, c'est au bout d'un peu plus de 30 minutes que la session expire. Mais théoriquement, ce semblerait que ce soit la valeur qui soit inscrite dans le php.ini de l'apache du serveur à la variable session.gc_maxlifetime. Celle-ci est définie par défaut à 14400 (24 minutes) et c'est la valeur que j'ai chez moi.

Tant que la session n'est pas expirée, la variable $_SESSION contient bien une clé user mais ensuite c'est le cookie qui devrait prendre le relais mais la variable $_SESSION est ensuite vide. Pourtant, je peux vérifier dans la console de dév de mon navigateur que j'ai bien le cookie YesWiki-main. Au niveau du code, le chargement des données de la session se fait au session_start() ici. C'est donc suite à cette instruction que je constate que je n'ai plus la clé user quand la session est expirée. Normalement la donnée devrait être ensuite copié (c'est censé être le comportement par défaut de PHP) au niveau d'un fichier (pour info, le cookie contient uniquement une clé qui permet d'identifier à qui appartient les données).

Suite à la lecture de cet article qui stipule qu'il ne faut pas laisser un session_start() ouvert sans avoir fait un session_write_close() (car cela peut provoquer des blocages d'accès aux données de la session), j'ai suivi cette piste en me disant que session_write_close() allait peut-être permettre d'écrire les données dans ce fameux fichier (et ne pas rester seulement en mémoire), mais après de nombreux tests, en essayent également de changer la façon dont on fait les paramétrages de la session, j'obtiens toujours le même soucis.

Sur ce sujet de forum, la personne a lui même détecté quand la session est expirée mais qu'il y a toujours le cookie et charge le cookie manuellement... J'ai l'impression que php devrait justement s'occuper de cela mais lui a résolut le soucis de cette manière.

Additionnal informations / Informations complémentaires

• 4.3.1, doryphore-dev, et toutes les versions depuis septembre (en gros)

cette PR ajoute le champ comments

ce que ça fait:

• ajouter le champ comments
• en suivant les spécifications de https://pad.lescommuns.org/C7vddagURFGIbraoE_Z02Q# (lien temporaire)

~~attention cette PR pointe vers la branche coms-improvement vu que c'est très lié~~

Avant de continuer à refactorer toutes les actions vers la nouvelle syntaxe en classe, je pense qu'il y quelque chose à faire sur la déclaration des paramètres (i.e. arguments) de l'action

Jérémie et Adrien avait déjà cerné le problème et ont mis en place une fonction formatArguments

Je pense qu'on peut aller plus loin et faire quelque chose de plus générique et DRY

Proposition

S'inspirer de la syntaxe symfony pour déclarer les argument des commandes symfony

Exemple pour l'action Button

class ButtonAction extends YesWikiAction
{
  public function configure()
  {
      $this
          ->addArgument("link", UrlArgument, ["required" => true])
          ->addArgument("text", TextArgument, ["required" => true])
          ->addArgument("hideifnoaccess", BooleanArgument, ["default" => true]);
  }
  
  // ...
}

Et on peut déclarer les types d'argument avec quelque chose comme

class Argument
{
    public function format($arg)
    {
        return $arg;
    }
}

class TextArgument extends Argument {}
class UrlArgument extends TextArgument {}

class BooleanArgument
{
    public function format($arg)
    {
        return in_array($arg, ["true", "1"]);
    }
}

Traitement automatisés

Avec cela on pourra automatiquement détecter et mettre une alerte sur les argument obligatoire non rempli, assigner les valeurs par default, et faire le formattage/parsing des arguments un peu spéciaux genre groups ou displayfields en créant un nouveau type d'argument

Inherit from another action

L'avantage avec la function configure c'est qu'on peut faire des trucs genre

class CustomButtonAction extends ButtonAction
{
  function configure()
  {
     parent::configure();
     $this
       ->removeArgument('text');
       ->updateArgument("link", UrlArgument, ["required" => false]);
       ->addArgument("newarg", TextArgument);
  }
}

Documentation automatisée

L'autre avantage c'est qu'on peut récupérer les infos déclarées dans configure pour les utiliser dans l'action builder. C'est notament important pour les valeur par default, car si dans la doc yaml on met que la valeur par défault d'un argument est "true" et que dans l'action php l'argument est par défault initialisé à "false", ça fait un peu tout foirer

Mais je pense qu'on va quand meme garder les fichier yaml car il y aura toujours des config qui trouveront difficilement leur place dans le configure notamment la description des groupe d'actions Mais on pourrait fusionner les deux config, par pour le button;yaml on pourrait garder cette config

# buttons.yaml
label: _t(AB_buttons_label)
position: 2
previewHeight: 100px
actions:
  button:
    label: _t(AB_buttons_action_button_label)
    description: _t(AB_buttons_action_button_description)
    properties:
      text:
        label: _t(AB_buttons_action_button_text_label)
        value: _t(AB_buttons_action_button_text_default)
      link:
        label: _t(AB_buttons_action_button_link_label)
        value: https://yeswiki.net
        hint: _t(AB_buttons_action_button_link_hint)
        type: page-list
     hideifnoaccess:
        advanced: true
        label: _t(AB_buttons_action_button_hideifnoaccess_label)

Et on la compléterai avec les infos définies dans le configure

Donc la y'aurait un arbitrage à faire avec ce qu'on met dans le configure et ce qu'on met dans le yaml. Car on pourrait très bien dans configure faire

public function configure()
{
    $this->addLabel(_t("AB_buttons_action_button_label"));
    $this->addArgument("text", UrlArgument, [
        "required" => true,
        "label" => _t("AB_buttons_action_button_text_label"),
        "value" => _t("AB_buttons_action_button_text_default"),
        "advanced" => false
    ]);
}

Perso je laisserai le max dans le yaml, et mettrai juste ce qui permet le traitement automatique des arguments, donc le type, si c'est required, et si y'a une valeur par default.

En prévision d'un futur sprint

L'idée est de pouvoir facilement personnaliser le rendu d'une fiche bazar depuis l'interface sans avoir à créer un fichier sur le serveur dans custom/templates

Proposition

Lorsqu'on édite un formulaire, on pourrait rajouter un nouvel onglet "Rendu des fiches" avec un éditeur wiki dedans Dans cet éditeur, en plus des fonctionnalités classique lorsqu'on édite une page, il faut pouvoir :

1. Accéder aux valeurs brutes des champs de la fiche
2. Afficher un champ tel qu'il aurait été affiché de manière automatique en html
3. Accéder à la config du formulaire
4. Ecrire directement du twig

Syntaxe/Implémentation

Prenons un exemple : pour un formulaire avec un bf_titre, bf_equipe, bf_url et bf_categories (de type checkboxes), je veux -> afficher un titre avec bf_titre et bf_equipe dedans -> afficher un bouton qui renvoie vers bf_url -> afficher les catégories de manière automatique

Moustaches

Note: Il faudra ajouter une option lors du Formatter wakka pour dire "si l'action n'est pas trouvée, laisse le texte comme ça" plutot que de mettre le message "Action bf_titre n'existe pas" Avantages: Ca ressemble à une syntaxe classique yeswiki, et on peut écrire du twig Inconvenient: L'autocompletion quand on tape {{ mélangera le nom des actions et le nom des champs. Ou alors dans ce contexte on désactive l'autocompletion du nom des actions.

==={{bf_titre}} - {{bf_equipe}}===
{{button link="{{bf_url}}" text="Site web"}}
{{field id="bf_categories" label="Les catégories"}}

{# Autre exemple avec twig #}
""
<h1>{{ bf_titre|uppercase }} - {{bf_equipe}}</h1>

{% for option in bf_categories %}
	<li>Category value = {{ option }} label = {{ form.bf_categories.options[option] }}
{% endfor %}
""

Crochets

Avantages: Pas de conflits de syntaxe. On peut facilement faire de l'autocompletion Inconvenient: Pour twig, faudrait changer le delimiteur

===[[bf_titre]] - [[bf_equipe]]===
{{button link="[[bf_url]]" text="Site web"}}
{{field id="bf_categories" label="Les catégories"}}

{# Autre exemple avec twig #}
""
<h1>[[ bf_titre|uppercase ]] - [[bf_equipe]]</h1>

[% for option in bf_categories %]
	<li>Category value = [[ option ]] label = [[ form.bf_categories.options[option] ]]
[% endfor %]
""

Variantes pour l'affichage du rendu automatisé d'un champ

{{render field="bf_categories" label="Les catégories"}}
{{bazarfield id="bf_categories" label="Les catégories"}}
{{bazarentry field="bf_categories" label="Les catégories"}}

Spécifier de quelle manière on veut faire le rendu

Par default ça utilise le type de champ déclaré dans le formulaire

{{field id="bf_url" as="text" label="l'url en mode plain text"}}

Petit extra

Un bouton special dans la toolbar pour selectionner quel champ on veut afficher et que ça insère {{bf_equipe}} dans l'éditeur quand on selectionne bf_equipe dans la popup

Personnaliser aussi le bazarliste

On pourrait utiliser la même syntaxe mise en place afin de personaliser le rendu des bazarliste. Pour le template card par example, plutôt que de dire "dans la zone de titre affiche le champ bf_titre" on pourrait dire "dans la zone de titre affiche le rendu de Equipe {{bf_titre}} ({{bf_equipe}})

Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) Bug / Bogue

Description Lors de l'affichage des données d'un formulaire, la liste des fiches liées aux fiches du formulaire ne s'affiche pas lorsque le paramètre dynamic="true" est présent dans bazarliste (en revanche elles s'affichent bien lorsqu'on les ouvre depuis Base de données).

{{bazarliste id="46" template="liste_accordeon" filtersresultnb="false" dynamic="true" groups="listeListeBlocDeCompetences" }}

Lorsque l'on supprime dynamic="true", les fiches liées apparaissent.

{{bazarliste id="46" template="liste_accordeon" filtersresultnb="false" groups="listeListeBlocDeCompetences" }}

Additionnal informations / Informations complémentaires

• version of YesWiki / version de YesWiki doryphore : 4.2.4

• url to see the problem or an example / url pour voir le probleme ou un exemple : https://www.cerealocales.org/?ExpertisesListe

• screenshot / capture d’écran Avec dynamic="true" : Sans dynamic="true" :

• logs

Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) New feature / Nouvelle fonctionnalité

Description Il serait utile de pouvoir avoir une vue des caractères tapés lors de la saisie du mot de passe (au clic sur un icone à droite par exemple) comme cela se fait habituellement dans ce type d'interface.

Demande remontée par utilisatrice rencontrée dans le cadre d'animacoop