SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 187 visiteurs en ce moment

Accueil > Interactivité, échanges > Email, Newsletters, listes de diffusion > Notifications > SystemeDeNotification (Archive)

SystemeDeNotification (Archive)

27 octobre 2004

Ceci est une archive périmée mais qui reste intéressante, parfois autant pour l’article que les commentaires associés.

Ceci est une ARCHIVE, peut-être périmée. Vérifiez bien les compatibilités !

Dernière minute : un système de notifications générique a été réalisé dans le cadre de spip-lab.


(Fil) Pour avancer je propose qu’on fasse un système de feeds RSS spécialisés, avec un fichier spip_rss.php3 unique qui fait le travail (authentification, sélection du RSS à donner, et calcul de ce RSS, éventuellement via des squelettes dans un répertoire rss/)
-  Pour l’authentification il faut utiliser la clé de petite sécurité qu’on trouve dans spip_cal.php3 :
if (verifier_low_sec($id_auteur, $cle, 'ical'))
-  Pour la sélection du feed choisi, un simple &feed=xxx dans l’URL
-  Ensuite faire les feeds un par un, par exemple &feed=messagerie donne les derniers messages
Dire « un par un », ci-dessus, signifie modularité, contribs, développement à plusieurs, etc. Je veux bien me charger de démarrer le processus en gérant spip_rss.php3 et en y mettant un ou deux feeds de base (suivi des pétitions, par exemple).

La suite éventuelle de ce travail sera(it) de faire un outil qui agglutine des RSS et les envoie par mail, par jabber, par iCal etc... ; à ce compte-là, peu importe que cet outil soit ou non lié à SPIP, il peut être totalement générique. Et il existe probablement déjà...


(James) le suivi ... effectivement, on avait déjà commencé ;-)

Reprise de la TODO


  • Système de notification d’événements (via mail, jabber ou rss)
    http://thread.gmane.org/gmane.comp....
    >> voire iCal, wap, popups sur le site (via javascript), balises #LU ? ...
    -* possibilité de s’inscrire pour suivre les forums par notification
    -* recevoir les avis de "nouveau message dans la messagerie", "dans
    le forum (privé) sous votre article", "nouveau site proposé", etc.

Il faudrait établir la liste complète des choses à signaler

  • Création de newsletter "nouveautés" : avec le nouveau compilo on
    récupère la page, on peut donc faire des squelettes de newsletter
    tout à fait normaux au lieu des horreurs phpiques actuelles
    (+ prévisulisation).
  • idée de Tom Dissing ;
    page de prévisualisation de la lettre automatique (admins seulement) ;
    ne pas trop cherche la complication : c’est probablement très très simple
    à faire, INCLURE nouveautes et afficher la variable résultat....
<?php
$fond = "nouveautes";
$delais = 24 * 3600;
include ("inc-public.php3");
/* ici vérifier le statut */
echo propre("<code>$mail_nouveautes< /code>");
?>

La liste complète des choses à signaler

* Partie publique

-  parutions des articles,
-  parutions des brèves,
-  parutions des sites,
-  parutions des documents dans les rubriques,
-  parutions de messages de forums,
-  parutions d’articles syndiqués.

* Partie privée

-  propositions d’articles,
-  propositions de brèves,
-  propositions de sites,
-  articles syndiqués bloqués à priori,
-  les messages de forums publics modérés à priori,
-  messages de forums des administrateurs,
-  messages de forums interne,
-  messages de forums associés aux articles,
-  messages de forums associés aux brèves, aux sites,
-  messages et rendez-vous privés et leurs messages associés,
-  annonces et rendez-vous et leurs messages associés ,
-  erreurs de syndication automatique,

* Et pourquoi pas ?

-  nouvel inscrit,
-  parutions de signatures de pétition,
-  parutions de nouvelles rubriques,
-  parutions de groupe/mots-clés,
-  connexion au site d’un inscrit,
-  alertes de rappel de rendez-vous x temps avant,
-  problème technique d’une pétition (confirmation de signatures, envoi de
mails...),
-  évènement éditoriaux tels que refus d’articles, de brèves et de sites.

* Restrictions

* liées au statut du visiteur
- Il faut être au moins rédacteur pour être notifié des éléments de la
partie privée.
- Il faut être au moins administrateur restreint pour être notifié des
messages de forums des administrateurs.

* liées au mode de récupération des notifications
- En dehors des fichiers RSS ’standard’ qui permettent de récupérer
anonymement les éléments de la partie publique, toute notification
nécessite une identification :
- Le visiteur anonyme doit enregistrer son mail/compte jabber quelquepart
pour être averti des parutions publiques avec ces moyens.
>> Utiliser le statut ’6forum’. Eventuellement proposer un script de changement
>> de statut ’6forum’->’1comite’. Regler le problème des inscriptions
>> #LOGIN_PUBLIC avant ?
>> Alternativement, le système d’abonnement prendra en charge l’email et/ou un
>> compte jabber du visiteur

* liées à la confidentialité des informations
- On ne peut être notifié QUE des messages privés qui nous sont adressés.

>> Prévoir fonction d’identification et de détection du statut

* Notification par défaut

- Les messages associés aux annonces pour les administrateurs.
- Les propositions d’articles, de brèves, de sites, les articles syndiqués
bloqués, les messages de forums publics modérés à priori pour les
administrateurs et les administrateurs restreints (pour leurs rubriques).
>> identifier les rubriques des admins restreints et vice-versa.
- Les messages de forums associés aux articles, les messages associés aux
messages, les messages privés, les messages associés aux messages privés,
les rendez-vous et les messages associés aux rendez-vous pour les rédacteurs
concernés.
>> Prévoir une règle pour éviter les doublons.

* Abonnements de branche

-  Tout abonnement devrait être hérité de l’abonnement à la rubrique parente.
-  Idem pour les fil de discussions des forums (threads).

>> Limiter aux secteurs et aux racines des fils de discussions
>> ou bien fournir un jeu de fonctions de détection de filiation

des contribs à mutualiser ?

faire chatter les gens : http://www.spip-contrib.net/ecrire/...
notification par mail : http://www.spip-contrib.net/ecrire/...
, http://www.spip-contrib.net/ecrire/...

format de notification ATOM : http://www.spip-contrib.net/ecrire/...

newsletter : http://www.spip-contrib.net/ecrire/... et la bloogletter, bien entendu.

Système de notification d’événements

* Les types de notification
Soit on limite au niveau global les moyens de notification, soit on laisse le
choix au visiteur.
Feed RSS/ATOM : éviter la redondance avec le système actuel de backend ou le
remplacer. étendre le système actuel aux évènements de l’espace privé.
iCal : idem que ci-dessus.
Mail : Soit on envoie les évènements individuellement dans un mail, soit on
envoie des ’digest’ régulièrement, soit on laisse le choix au visiteur.
>>Jabber : Comment ça marche ?
Squelettes : Pour les inscrits connectés dans la partie publique et/ou dans
l’espace privé, on affiche les nouveautés par le biais d’une boucle
spécifique ou d’une balise #LU/#NONLU . On peut ainsi fabriquer un popup qui
indique si on a reçu un message privé sur le site public...

* Proposition de fonctionnement

-  On adopte une notation pour les choses à signaler (types d’évènement)
On recense la methode d’acquisition de l’évènement (la requête SQL)
On recense les types de notification possible pour ce type d’évènement
On recense les restrictions d’accès aux évènements de ce type
On recense les possibilités de notification par défaut de ce type
-  Une table spip_evenements gère les évènements courants
champs : id_evenement, type_evenement, id_objet
effacement des évènements révolus, génération des évenements courants
-  Une table spip_auteurs_evenements gère les notifications à effectuer
champs : id_auteur, id_evenement, type_notification
-  Une table spip_abonnements gère les abonnements des visiteurs
champs : id_auteur, e_mail, jabber, id_branche, type_branche, type_evenement

Le formulaire (ou la série de lien) à fournir compile selon le contexte les
différents abonnements auxquels sourcrire et/ou les types de notification
possibles. Exemples :

-  Sur la page d’un article publié, je peux me faire notifier des nouveaux
messages.
-  Sur la page de l’espace privé d’une rubrique, je peux me faire notifier des
prochaines propositions d’articles et/ou de sites.
-  Sur la page d’accueil du site, je peux m’abonner à la newsletter (parutions de
tous les articles et de toutes les brèves du site).
-  Sur la page de saisie d’un message de forum, je peux me faire notifier les
réponses à mon message.

L’abonnement est donc enregistré dans une table de la BDD.

Toute action de l’espace privé peut engendrer un évènement notifiable. Soit on
patche les pages en conséquence pour créer les évènements (et les supprimer
aussi). Soit on laisse au cron de SPIP le soin de regarder régulièrement.

Le cron regarde si des évènements sont révolus et les efface. Il insère ensuite
les nouveaux évènements. Enfin, il génère les notifications et envoie un lot de
notification qu’il efface de la table.

Quand un évènement est-il révolus ?

Quand l’objet n’est plus dans la base dans l’état annoncé OU que toutes les
notifications de cet évènement ont été envoyés.

Dernière modification de cette page le 26 août 2009

Retour en haut de la page

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Import ICS 2 (agenda distant)

    2 août – 35 commentaires

    La version 2 du plugin « import ICS » en reprend la principale fonctionnalité, à savoir l’ajout automatique d’évènements distants dans la liste des évènements d’un site. À la différence de la première version, elle ne dépend pas du plugin « Séminaire » et est (...)

  • Newsletters

    16 janvier 2013 – 374 commentaires

    Ce plugin permet de composer des Info-lettres. Par info-lettre, on désigne ici le contenu éditorial qui va être composé et envoyé par courriel à une liste d’inscrits. Le plugin permet de composer une info-lettre à partir d’un modèle pré-composé, (...)

  • CKeditor 3.0

    4 octobre 2009 – 1217 commentaires

    CKeditor est l’évolution de l’éditeur WYSIWYG : FCKeditor, avec ce plugin vous pourrez utiliser cet éditeur à la place de l’éditeur de spip tout en laissant le choix à vos auteurs de l’éditeur qu’ils préfèrent utiliser. Attention : cet éditeur WYSIWYG (...)

  • GIS 4

    11 août 2012 – 1284 commentaires

    Présentation et nouveautés La version 4 de GIS abandonne la libraire Mapstraction au profit de Leaflet. Cette librairie permet de s’affranchir des librairies propriétaires tout en gardant les mêmes fonctionnalités, elle propose même de nouvelles (...)

  • SPIPr

    23 mars 2015 – 75 commentaires

    SPIPr est à la fois une famille de squelettes et un framework pour le développement front avec SPIP. Prêt à l’emploi, thémable, responsive, et conçu dans une approche d’industrialisation et de développement rapide. Documentation source : (...)

Ça spipe par là