Recherche avancée

Sur d’autres sites (5462)

• lpc_intrin* : Remove unused code.

  21 septembre 2014, par Erik de Castro Lopo

  lpc_intrin* : Remove unused code.
  Which in turn simplifies FLAC__lpc_restore_signal_16_intrin_sse2()
  
  function.
  Patch-from : lvqcl <lvqcl.mail@gmail.com>
  

  • [DH] src/libFLAC/include/private/lpc.h
  • [DH] src/libFLAC/lpc_intrin_sse2.c
  • [DH] src/libFLAC/stream_decoder.c
  • [DH] src/libFLAC/stream_encoder.c

• Créer des auteurs par lot

  9 mai 2013

  Il peut être intéressant de pouvoir insérer dans SPIP une liste d’auteurs soit via une liste d’emails rentrée dans un champ textarea ou via un import CSV (était possible avec Inscription2 et donc à réadapter).

  Doit être un plugin indépendant. Ce serait trop lourd de gérer cela en plus dans Inscription3 alors que ce plugin est déjà bien compliqué.

  Note du 26/05/13 :

  • Il existe déjà un plugin "importateur de contacts" qui pourrait réaliser cela : http://contrib.spip.net/Importateur-de-contacts
  • Ce plugin peut également être couplé à la librairies [Openinviter(cf : http://contrib.spip.net/OpenInviter)
  • Enfin, pour être complet, il doit être couplé au plugin Parrainage pour gérer les invitations ;

  Tâches à réaliser

  	Titre	#
  	Intégrer le plugin importateur contacts dans la configuration qui permet de récupérer les contacts à partir d’une liste ou d’un site externe (Gmail etc...) ;	#1
  	Intégrer le plugin parrainages qui permet de sélectionner les contacts et de les inviter à créer un compte (configuration + formulaire de parrainage) ;	#2
  	Intégrer OpenInviter pour ajouter des méthodes à importateur de contacts	#3
  	Pouvoir configurer le lien dans le mail de parrainage	#4
  	Le mail de parrainage devrait être en html (notifications)	#5
  	Lors du click sur le lien dans le mail => préremplir les champs du formulaire d’inscription (nom + email) ;	#6
  	Faire en sorte que les personnes avec un code d’invitation puisse s’inscrire dans un intranet : cf zone.spip.org/trac/spip-zone/changeset/73071	#7
  	Permettre aux utilisateurs d’inviter leurs propres amis depuis leur page cf : http://zone.spip.org/trac/spip-zone/changeset/73066 ;	#8
  	Ne pas pouvoir parrainer si la conf du site ne permet pas l’inscription, l’indiquer dans la configuration du plugin parrainage ;	#9
  	Passer par une action editer_filleul dans le plugin parrainage ;	#10
  	Si le code d’invitation est obligatoire, le signaler dans le formulaire d’inscription et dans le formulaire de configuration de l’ouverture d’inscription du site ;	#11
  	Pouvoir ajouter comme contact un email simple, une liste d’email ;	#12
  	Pouvoir ajouter les auteurs via un csv ;	#13
  	intégrer les plugins dans le script de la version 0.3	#14
  	documenter l’usage dans MediaSPIP + screencasts	#15

• Evolution #4256 : Faire un signalement des mise à jour de sécu

  11 janvier 2019, par Franck D

  Salut marcimat, Oui, c’est pour cela que je disais que cela allait un peu avec 3509, mais en même temps, simplement le signalement d’une mise à jour de secu ne demande pas forcément d’avoir le changelog, cela ne serait qu’un plus !
  Celui voulant savoir, pourrait toujours faire comme actuellement, une lecture des logs de commit (ce n’est pas génial, mais bon...)
  Il ne faut pas que les gens se rendent compte qu’une mise à jour de secu est dispo uniquement car ils vont voir la page de gestion des plugins, car les administrateurs ou webmestres n’y vont pas systématiquement à chaque fois qu’ils vont sur un site.
  C’est pour cela qu’il faut qu’ils reçoivent l’info dès qu’ils arrivent sur le site (une fenêtre qui s’ouvre, une couleur de fond qui change, l’envoi d’un mail, un message par pigeon voyageur, ????), quelque chose qui fasse que les gens se disent "mon site est vulnérable, il faut que je regarde les plugins qui ne sont pas à jour"

  C’est pour ça que je pensais à, un génie de plus dans spip qui regarderait un simple fichier archivelist_secu.txt (après reste à bien réfléchir comment doit être indiquer qu’un plug est vulnérable (je ne sais pas si ce que je proposais était suffisant (car j’ai peur que l’on indique que des versions ont des problèmes alors qu’il ne sont pas concernés), possible qu’il faudrait plutôt un truc du genre :
  Nom_du_prefix_du_plugin/Version_du_X_Y_Z_qui_contient_le_problème/Version_du_plugin_sans_problème

  Sachant que si la personne écrit par exemple : saisie / version 1.x.x / 1.42.11 (alors cela voudrait dire que toutes les versions 1.x.x ont un problème)