Skip to content
Extraits de code Groupes Projets
Sélectionner une révision Git
  • check_reponse
  • dev/issues_131_133_boites_liaisons
  • formidable_request_ou_base
  • imposer_un_traitement
  • issue45_date_effacement
  • issue_251_erreur_formulaires_lies
  • master par défaut protégée
  • no_bouton
  • v0
  • v1
  • v2
  • v3
  • v4
  • v7.0.5
  • v7.0.4
  • v7.0.3
  • v7.0.2
  • v7.0.1
  • v7.0.0
  • v6.6.2
  • v6.6.1
  • v6.6.0
  • v6.5.0
  • v6.4.0
  • v6.3.2
  • v6.3.1
  • v6.3.0
  • v6.2.0
  • v6.1.2
  • v6.1.1
  • v6.1.0
  • v6.0.0
  • v5.7.1
33 résultats
Vous pouvez vous déplacer dans le graphe en utilisant les touches fléchées.
Created with Raphaël 2.2.03Dec27Nov829Oct282724155411Sep24Aug17Jul825Jun24876329May24211714133227Apr24231918Mar65129Feb2725222120765330Jan2513117631Dec2322191328Nov12102123Oct222115141015Sep73131Aug2117624Jul22211611130Jun2924151424May21201713964319Apr16119320Mar19171413627Feb1124Jan23119523Dec2221201918171615915Nov131283130Oct29282523222112115429Sep282647Aug10Jul429Jun25241463228May27242313111093Apr22Mar1817161224Feb2014825Jan2418Dec828Nov272213121119Oct22Sep18Aug172Jul123May8421Apr181286214Mar1194321Feb29Jan28272623212017139852131Dec30292827242322Bien que la problématique ait été soulevée par un troll sexiste, elleMieux : on collecte tous les messages de retour (le personnalisé + ceux des traitements), ce qui permet ensuite de les distinguer plus facilement avec des sauts de lignes.Ticket #44 : afficher les messages de retour des traitements même s'il y a un message personnalisé, car ils peuvent contenir de informations importantes, ou être indispensables au fonctionnement même du formulaire s'ils contiennent du JS qui déclenche des actions. On fait au plus simple : Le message perso est placé au début, séparé par un saut de ligne.Encapsuler l'affichage dans des div qu'on peut ciblerZ+1v4.7.1v4.7.1Ajouter une classe sur les boutons en multi étapes, pour pouvoir les cibler en css[Salvatore] [source:lang/ formulaire] Export depuis https://trad.spip.net de la langue frup de yv4.7.0v4.7.0Merge pull request 'dev/issue_42' (#43) from dev/issue_42 into masterAu passage on déclare bien les jointures pour tout le monde comme pour les docs aussi, et le champ vu en exception pareilVérifier au moins les liens déjà existant pour mettre vu=oui si ya toujours le modèle trouvé dans le contenuOups oubli de retirer le code commentéIssue 42 : améliorer la liaison des formulaires avec un champ vu comme pour les documents : il FAUT savoir quels liens ont été mis à la main et lesquels sont automatiques suivant les modèles dans les textes. Surtout qu'il y avait un bug : ça virait les liens même ceux mis à la main si on les trouvait pas dans les textes. Maintenant ça fait tout comme les documents : si le form n'est plus en modèles dans les textes, ça passe juste en vu=non, mais le lien reste.un peu de logune note de commentairecoquille logc'était juste que les dernières versions du lecteur de log insérait <code>check_reponsecheck_reponseRevert "Je ne sais pas pourquoi, sur mon serveur le decodage json plante. Tant"Je ne sais pas pourquoi, sur mon serveur le decodage json plante. Tantune page pour voir les e nregistrement en formidable_post qui n'ont pas d'équivalent en base. C'est moche et mal codé, mais ca dépanne déjà. Attention, si un e personne modifie une réponse, c'est logique qu'un enregistrement se retrouve pas en base, donc c'est pas sur à 100%Ne pas oublier d'inclure le fichierv4.6.3v4.6.3précisions dans les logsdifférents logs[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue archaine de langue correct pour les titre de statuts de formulairesv4.6.2v4.6.2up de zv4.6.1v4.6.1pour les filtres de statuts, se baser sur les titres (= etat) plutôt que sur les textes d'institution (=verbe)chaine de langue pour le titre de la réponse à la poubellecohérence de l'ordre entre statut_textes_instituer et statut_titresup de yv4.6.0v4.6.0Les formulaires sont désormais listées en onglet, pour l'instant par statutConstruire dynamiquement les onglets de statut, ce qui permet à n'importe qui d'ajouter ses propres statuts de réponse.Quand on va chercher les réponses du visiteur en cours, on ne doit pas forcer à ce qu'il ne puisse que re modifier si déjà publié. Si c'était en modération à priori, sa réponse n'est pas validé par un admin mais c'est sa réponse quand même, elle n'est pas à la poubelle, donc il peut continuer de la modifier si on est en option modifiable.v4.5.6v4.5.6Version Z pour correction des autorisations, qui fait que quand modération à priori, alors quand un visiteur quelconque répond, c'est bien en proposé, pas publié, comme demandé par la config.Refonte de l'autorisation editer formulaire moins bazar, là si yavait l'option de liaison auteur ça testait même pas les admins restreints car return direct…Vraie autorisation correct pour instituer une réponse : avoir le droit d'éditer le form parent ET si pas admin qu'il y ait l'option qui autorise les auteurs simples à modérer les réponses. Et pour modifier les réponses : pas besoin de refaire les mêmes tests : c'est comme instituer donc on l'appelle directement. Du coup il n'y a plus d'utilisation de la mauvaise fonction formidable_auteur_admin_reponse() qui ne faisait pas les bons tests. On la laisse quand même pour rien casser.Meilleur rangement de formidable_auteur_admin_reponse + prise en compte dedans des admins restreints aussi (mais cette fonction reste encore merdique puisque ne teste pas que CET auteur a le droit pour TEL formulaire, alors que c'est le principal à savoir…)Clarifier formidable_autoriser_par_auteurdebug sur l'aide mémoire lorsqu'on a une explication juste après un champ avec datav4.5.4v4.5.4En session, les saisies sont identifiées, mais ce n'est pasv4.5.3v4.5.3

Forge communautaire SPIP | Charte d'utilisation | Signaler un problème sur ce site