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=xxxdans l’URL
- Ensuite faire les feeds un par un, par exemple&feed=messageriedonne 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
- Jabber toujours : faire chatter les gens
http://thread.gmane.org/gmane.comp....
- 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.
Aucune discussion
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
