Description :
Description :
Connaissez-vous MemoServ ? Il s'agit d'un service disponible sur certains serveurs IRC et permettant d'envoyer un message à un utilisateur, qu'il soit connecté ou non. Bonne idée en soi si certains défauts majeurs ne le rendaient pas quasiment inutile :
MDS permet d'envoyer un message à une personne (qui n'a pas besoin d'être connectée) et de s'assurer que le message sera bien délivré dans les meilleurs délais.
Dès que le destinataire rejoindra un des chans sur lesquels le bot se trouve ou qu'il y parlera, donc dès qu'on pourra être certain qu'il y porte attention, un message lui sera affiché afin de lui indiquer qu'il a des messages non-lus.
Il pourra alors taper !lire (par défaut) pour les recevoir.
Si l'utilisateur ne lit pas ses messages, un rappel lui indiquant qu'il a des messages en attente s'affichera toutes les 30mn (réglable) s'il manifeste sa présence en parlant. Ce compteur de 30mn est réinitialisé si de nouveaux messages lui sont envoyés entre temps.
![[Image: mdsscreenshot.jpg]](http://img42.imageshack.us/img42/614/mdsscreenshot.jpg)
Lorsqu'un message est reçu, un accusé de réception est automatiquement envoyé Ã l'expéditeur pour l'en informer (optionnel).
Il est également possible pour le destinataire de confirmer avoir lu le message au moyen de la commande !lu <n° d'identifiant du message> (optionnel). Si une confirmation de lecture est envoyée, elle remplace l'accusé de réception.
Concernant la confidentialité, MDS s'assure du mieux qu'il peut qu'il ne délivrera pas un message à la mauvaise personne.
De plus, si l'identité de l'expéditeur d'un message présente une incohérence, le fait sera signalé au destinataire ainsi qu'une estimation du niveau de confiance qu'il peut lui accorder en fonction du nombre et de la gravité des anomalies détectées. Il sera alors libre de lui accorder ou non du crédit.
Ce système fonctionne conjointement avec les handles enregistrés sur l'eggdrop (et leurs listes de hosts associés), la vérification d'identité auprès de NickServ ou tout serveur de nick similaire (si disponible) et le recoupement de diverses informations disponibles afin de détecter les anomalies.
Avoir un nick enregistré ou un handle sur l'eggdrop augmente donc considérablement le niveau de sécurité et permet de s'assurer que personne ne pourra lire vos messages à votre place. Pour ceux qui n'ont ni handle, ni nick enregistré, le bot ne pourra faire mieux que de délivrer le message à la première personne portant le même nick.
Veuillez noter que le bon fonctionnement de ce système repose en partie sur une liste d'accès bien tenue, avec des masques de hosts pertinents et aussi précis que possibles (je parle évidemment de la liste d'accès de l'eggdrop).
Si vous utilisez des handles génériques, il est possible de les déclarer afin que le système de sécurité de MDS n'accorde pas trop de crédit à la reconnaissance par handle en ce qui les concerne.
L'idée de base d'un handle générique est de regrouper plusieurs utilisateurs ayant un host identique (utilisateurs d'un même bnc, d'un cybercafé, etc..) sous un même handle dit "générique".
Si l'on tente d'envoyer un message trop long pour être affiché intégralement chez le destinataire, le bot nous en informe et affiche la limite à ne pas dépasser. Cette limite est dynamique et est calculée en fonction du nom du chan, du nick de l'expéditeur, de la fioriture que vous avez choisie pour rendre bien visibles les messages recus, etc...
L'activation/désactivation du script sur chaque chan se fait au moyen de la commande de partyline .chanset #nomduchan [+/-]MDS
Notez que ceci concerne uniquement l'utilisation des commandes de la messagerie, ce qui veut dire qu'une personne ayant un message et manifestant sa présence sur un chan inactif sera quand même avertie qu'elle a un message non-lu.
Il est possible d'utiliser MDS pour envoyer des messages à des utilisateurs depuis d'autres scripts, une procédure existe dans ce but précis.
Voici comment utiliser cette fonction :
send_msg_to <destinataire>[,destinataire,...] <nom_du_script_appelant> <message>
- Le nom du ou des destinataires peut être un nick ou un handle.
- nom_du_script_appelant doit être le nom du script qui envoie le message.
Le destinataire recevra le message sous la forme :
"Message de nom_du_script_appelant envoyé le xx/xx/xxxx à xxhxx : blablabla".
MDS déclare le package "MDS" afin que vous puissiez vérifier sa présence depuis d'autres scripts au moyen de "package require MDS".
Les messages envoyés par ce biais ne sont pas soumis au contrôle de longueur minimale et maximale du message ou du nombre maximum de destinataires, et l'anti-flood ne s'en occupe pas. Soyez donc responsable dans la façon dont vous l'utilisez.
Commandes par défaut :
Envoyer un message depuis un chan :
!msg <destinataire>[,destinataire,...] <message>
Envoyer un message depuis un message privé :
/msg nom_du_bot msg <destinataire>[,destinataire,...] <message>
Recevoir ses messages non-lus depuis un chan :
!lire
Recevoir ses messages non-lus depuis une commande privée :
/msg nom_du_bot lire
Confirmer la lecture d'un message depuis un chan :
!lu <n° d'identifiant du message>
Confirmer la lecture d'un message depuis un message privé :
/msg nom_du_bot lu <n° d'identifiant du message>
Afficher la liste des destinataires ayant des messages en attente :
!messages
Changelog :
1.0
- 1ère version publique
1.01
- Correction : demander l'affichage de la liste des destinataires ayant d'un message ne provoque plus d'erreur si ladite liste est vide.
- Correction : créer manuellement le fichier base de données plutôt que le laisser être créé automatiquement n'empêche plus le script de fonctionner.
1.02
- Correction : lorsque le bot détectait une anomalie dans l'identité du destinataire, une erreur se produisait parfois.
- Correction : terminer la liste de destinataires par une virgule (lors d'un envoi multi-destinataires) ne pose plus de problème.
- Correction : dans certains cas, relever ses messages au moyen de la commande "/msg nomdubot lire" provoquait une erreur.
- Correction : la version d'eggdrop est désormais correctement détectée.
- Correction : la confirmation d'envoi à plusieurs destinataires s'affiche maintenant correctement.
- Ajout : une nouvelle option permet de régler un délai avant de signaler à un utilisateur qu'il a de nouveaux messages lorsqu'il rejoint un chan.
2.0
- Restructuration importante du script : sécurité renforcée contre les fraudes, refonte du fonctionnement interne, modification du format de la base de données (si vous possédez une base de données d'un ancien format, elle sera automatiquement convertie).
- Correction : le cas où un destinataire a des messages à la fois sur son nick et sur son handle (et que ces 2 derniers sont différents) est maintenant géré.
- Modification : l'activation/désactivation du script sur un chan se fait maintenant au moyen d'un flag udef (.chanset #nomduchan [+/-]MDS)
Veuillez noter que le script est activé par défaut sur tous les chans lors de son 1er lancement.
- Ajout : si un utilisateur a déjà pris connaissance d'un accusé de réception, il n'est plus possible d'envoyer une confirmation de lecture en plus. Ceci évite de recevoir des doubles confirmations.
- Ajout : une nouvelle option permet d'imposer une longueur minimale aux messages envoyés.
- Ajout : protocole permettant à d'autres scripts d'utiliser MDS pour envoyer des messages aux utilisateurs.
- Correction : bugs divers
2.1
- Correction : meilleur gestion des caractères spéciaux dans les nicks
- Correction : bug lors de la vérification d'identité au cas où Nickserv n'est pas disponible (merci à qr3nt)
- Modification : en raison des problèmes rencontrés par les utilisateurs n'ayant défini aucun chan statique dans leur fichier eggdrop.conf, la messagerie n'est désormais plus activée automatiquement sur tous les chans lors du 1er lancement du script. Vous devrez donc l'activer manuellement sur chaque chan au moyen de la commande : .channel set #nomduchan +MDS (Ã taper en partyline)
- Ajout : nouvelle option permettant de fixer une limite au nombre de messages qu'un même utilisateur peut avoir en attente (option max_messages_per_recipient). Les accusés de réception et les confirmations de lecture ne comptent pas.
- Modification : il n'est maintenant plus possible d'envoyer un message à l'eggdrop.
- Modification : si l'option permettant d'envoyer une confirmation de lecture est désactivée (option AR_enabled), l'id du message n'est plus affiché au destinataire car cette information est inutile.
- Ajout : nouvelle option (admin_flags) permettant selon leurs flags, d'exempter certains utilisateurs des restrictions suivantes lors de l'envoi d'un message : contrôle du nombre maximum de destinataires (option max_recipients), contrôle de flood lors de l'envoi de messages (option cmdflood_msg) et contrôle du nombre maximum de messages en attente pour un destinataire donné (option max_messages_per_recipient)
- Ajout : nouvelle option permettant de définir un délai après lequel un message en attente expirera si son destinataire ne l'a pas lu (option message_lifetime). La durée de vie d'un message est exprimée en jours.
Lorsqu'un message expire, il est supprimé de la base de données. En raison de cet ajout, la structure de la base de données a changé. Votre ancienne base de données de messages sera automatiquement convertie vers le nouveau format après en avoir fait une copie de sauvegarde. Si vous aviez encore une base de données au format v1.x, elle sera de même convertie au format v2.1.
La vérification des messages expirés a lieu une fois par jour juste après le backup de la base de données.
2.11
- Correction : la vérification des messages expirés provoquait une erreur.
Post support et commentaires ici
Description :
Connaissez-vous MemoServ ? Il s'agit d'un service disponible sur certains serveurs IRC et permettant d'envoyer un message à un utilisateur, qu'il soit connecté ou non. Bonne idée en soi si certains défauts majeurs ne le rendaient pas quasiment inutile :
- Il ne vous permet pas d'envoyer de messages si vous n'avez pas enregistré et identifié votre nick.
- Il ne permet pas d'envoyer de messages à un utilisateur n'ayant pas enregistré son nick.
- Lorsque vous avez un message, MemoServ vous en informe au moment de votre connexion au serveur et l'information est noyée dans les nombreuses notices que le serveur vous envoie à ce moment précis. Qui lit scrupuleusement ce flood lorsqu'il se connecte ? Pas moi. Par conséquent, il m'est arrivé de m'apercevoir que j'avais un message sur MemoServ 8 mois après qu'il ait été envoyé; ça se passe de commentaires.
MDS permet d'envoyer un message à une personne (qui n'a pas besoin d'être connectée) et de s'assurer que le message sera bien délivré dans les meilleurs délais.
Dès que le destinataire rejoindra un des chans sur lesquels le bot se trouve ou qu'il y parlera, donc dès qu'on pourra être certain qu'il y porte attention, un message lui sera affiché afin de lui indiquer qu'il a des messages non-lus.
Il pourra alors taper !lire (par défaut) pour les recevoir.
Si l'utilisateur ne lit pas ses messages, un rappel lui indiquant qu'il a des messages en attente s'affichera toutes les 30mn (réglable) s'il manifeste sa présence en parlant. Ce compteur de 30mn est réinitialisé si de nouveaux messages lui sont envoyés entre temps.
Lorsqu'un message est reçu, un accusé de réception est automatiquement envoyé Ã l'expéditeur pour l'en informer (optionnel).
Il est également possible pour le destinataire de confirmer avoir lu le message au moyen de la commande !lu <n° d'identifiant du message> (optionnel). Si une confirmation de lecture est envoyée, elle remplace l'accusé de réception.
Concernant la confidentialité, MDS s'assure du mieux qu'il peut qu'il ne délivrera pas un message à la mauvaise personne.
De plus, si l'identité de l'expéditeur d'un message présente une incohérence, le fait sera signalé au destinataire ainsi qu'une estimation du niveau de confiance qu'il peut lui accorder en fonction du nombre et de la gravité des anomalies détectées. Il sera alors libre de lui accorder ou non du crédit.
Ce système fonctionne conjointement avec les handles enregistrés sur l'eggdrop (et leurs listes de hosts associés), la vérification d'identité auprès de NickServ ou tout serveur de nick similaire (si disponible) et le recoupement de diverses informations disponibles afin de détecter les anomalies.
Avoir un nick enregistré ou un handle sur l'eggdrop augmente donc considérablement le niveau de sécurité et permet de s'assurer que personne ne pourra lire vos messages à votre place. Pour ceux qui n'ont ni handle, ni nick enregistré, le bot ne pourra faire mieux que de délivrer le message à la première personne portant le même nick.
Veuillez noter que le bon fonctionnement de ce système repose en partie sur une liste d'accès bien tenue, avec des masques de hosts pertinents et aussi précis que possibles (je parle évidemment de la liste d'accès de l'eggdrop).
Si vous utilisez des handles génériques, il est possible de les déclarer afin que le système de sécurité de MDS n'accorde pas trop de crédit à la reconnaissance par handle en ce qui les concerne.
L'idée de base d'un handle générique est de regrouper plusieurs utilisateurs ayant un host identique (utilisateurs d'un même bnc, d'un cybercafé, etc..) sous un même handle dit "générique".
Si l'on tente d'envoyer un message trop long pour être affiché intégralement chez le destinataire, le bot nous en informe et affiche la limite à ne pas dépasser. Cette limite est dynamique et est calculée en fonction du nom du chan, du nick de l'expéditeur, de la fioriture que vous avez choisie pour rendre bien visibles les messages recus, etc...
L'activation/désactivation du script sur chaque chan se fait au moyen de la commande de partyline .chanset #nomduchan [+/-]MDS
Notez que ceci concerne uniquement l'utilisation des commandes de la messagerie, ce qui veut dire qu'une personne ayant un message et manifestant sa présence sur un chan inactif sera quand même avertie qu'elle a un message non-lu.
Il est possible d'utiliser MDS pour envoyer des messages à des utilisateurs depuis d'autres scripts, une procédure existe dans ce but précis.
Voici comment utiliser cette fonction :
send_msg_to <destinataire>[,destinataire,...] <nom_du_script_appelant> <message>
- Le nom du ou des destinataires peut être un nick ou un handle.
- nom_du_script_appelant doit être le nom du script qui envoie le message.
Le destinataire recevra le message sous la forme :
"Message de nom_du_script_appelant envoyé le xx/xx/xxxx à xxhxx : blablabla".
MDS déclare le package "MDS" afin que vous puissiez vérifier sa présence depuis d'autres scripts au moyen de "package require MDS".
Les messages envoyés par ce biais ne sont pas soumis au contrôle de longueur minimale et maximale du message ou du nombre maximum de destinataires, et l'anti-flood ne s'en occupe pas. Soyez donc responsable dans la façon dont vous l'utilisez.
Commandes par défaut :
Envoyer un message depuis un chan :
!msg <destinataire>[,destinataire,...] <message>
Envoyer un message depuis un message privé :
/msg nom_du_bot msg <destinataire>[,destinataire,...] <message>
Recevoir ses messages non-lus depuis un chan :
!lire
Recevoir ses messages non-lus depuis une commande privée :
/msg nom_du_bot lire
Confirmer la lecture d'un message depuis un chan :
!lu <n° d'identifiant du message>
Confirmer la lecture d'un message depuis un message privé :
/msg nom_du_bot lu <n° d'identifiant du message>
Afficher la liste des destinataires ayant des messages en attente :
!messages
Changelog :
1.0
- 1ère version publique
1.01
- Correction : demander l'affichage de la liste des destinataires ayant d'un message ne provoque plus d'erreur si ladite liste est vide.
- Correction : créer manuellement le fichier base de données plutôt que le laisser être créé automatiquement n'empêche plus le script de fonctionner.
1.02
- Correction : lorsque le bot détectait une anomalie dans l'identité du destinataire, une erreur se produisait parfois.
- Correction : terminer la liste de destinataires par une virgule (lors d'un envoi multi-destinataires) ne pose plus de problème.
- Correction : dans certains cas, relever ses messages au moyen de la commande "/msg nomdubot lire" provoquait une erreur.
- Correction : la version d'eggdrop est désormais correctement détectée.
- Correction : la confirmation d'envoi à plusieurs destinataires s'affiche maintenant correctement.
- Ajout : une nouvelle option permet de régler un délai avant de signaler à un utilisateur qu'il a de nouveaux messages lorsqu'il rejoint un chan.
2.0
- Restructuration importante du script : sécurité renforcée contre les fraudes, refonte du fonctionnement interne, modification du format de la base de données (si vous possédez une base de données d'un ancien format, elle sera automatiquement convertie).
- Correction : le cas où un destinataire a des messages à la fois sur son nick et sur son handle (et que ces 2 derniers sont différents) est maintenant géré.
- Modification : l'activation/désactivation du script sur un chan se fait maintenant au moyen d'un flag udef (.chanset #nomduchan [+/-]MDS)
Veuillez noter que le script est activé par défaut sur tous les chans lors de son 1er lancement.
- Ajout : si un utilisateur a déjà pris connaissance d'un accusé de réception, il n'est plus possible d'envoyer une confirmation de lecture en plus. Ceci évite de recevoir des doubles confirmations.
- Ajout : une nouvelle option permet d'imposer une longueur minimale aux messages envoyés.
- Ajout : protocole permettant à d'autres scripts d'utiliser MDS pour envoyer des messages aux utilisateurs.
- Correction : bugs divers
2.1
- Correction : meilleur gestion des caractères spéciaux dans les nicks
- Correction : bug lors de la vérification d'identité au cas où Nickserv n'est pas disponible (merci à qr3nt)
- Modification : en raison des problèmes rencontrés par les utilisateurs n'ayant défini aucun chan statique dans leur fichier eggdrop.conf, la messagerie n'est désormais plus activée automatiquement sur tous les chans lors du 1er lancement du script. Vous devrez donc l'activer manuellement sur chaque chan au moyen de la commande : .channel set #nomduchan +MDS (Ã taper en partyline)
- Ajout : nouvelle option permettant de fixer une limite au nombre de messages qu'un même utilisateur peut avoir en attente (option max_messages_per_recipient). Les accusés de réception et les confirmations de lecture ne comptent pas.
- Modification : il n'est maintenant plus possible d'envoyer un message à l'eggdrop.
- Modification : si l'option permettant d'envoyer une confirmation de lecture est désactivée (option AR_enabled), l'id du message n'est plus affiché au destinataire car cette information est inutile.
- Ajout : nouvelle option (admin_flags) permettant selon leurs flags, d'exempter certains utilisateurs des restrictions suivantes lors de l'envoi d'un message : contrôle du nombre maximum de destinataires (option max_recipients), contrôle de flood lors de l'envoi de messages (option cmdflood_msg) et contrôle du nombre maximum de messages en attente pour un destinataire donné (option max_messages_per_recipient)
- Ajout : nouvelle option permettant de définir un délai après lequel un message en attente expirera si son destinataire ne l'a pas lu (option message_lifetime). La durée de vie d'un message est exprimée en jours.
Lorsqu'un message expire, il est supprimé de la base de données. En raison de cet ajout, la structure de la base de données a changé. Votre ancienne base de données de messages sera automatiquement convertie vers le nouveau format après en avoir fait une copie de sauvegarde. Si vous aviez encore une base de données au format v1.x, elle sera de même convertie au format v2.1.
La vérification des messages expirés a lieu une fois par jour juste après le backup de la base de données.
2.11
- Correction : la vérification des messages expirés provoquait une erreur.
Post support et commentaires ici
Changelog
Version 1 par (07/12/2010)55 téléchargements
Description :
Connaissez-vous MemoServ ? Il s'agit d'un service disponible sur certains serveurs IRC et permettant d'envoyer un message à un utilisateur, qu'il soit connecté ou non. Bonne idée en soi si certains défauts majeurs ne le rendaient pas quasiment inutile :
- Il ne vous permet pas d'envoyer de messages si vous n'avez pas enregistré et identifié votre nick.
- Il ne permet pas d'envoyer de messages à un utilisateur n'ayant pas enregistré son nick.
- Lorsque vous avez un message, MemoServ vous en informe au moment de votre connexion au serveur et l'information est noyée dans les nombreuses notices que le serveur vous envoie à ce moment précis. Qui lit scrupuleusement ce flood lorsqu'il se connecte ? Pas moi. Par conséquent, il m'est arrivé de m'apercevoir que j'avais un message sur MemoServ 8 mois après qu'il ait été envoyé; ça se passe de commentaires.
MDS permet d'envoyer un message à une personne (qui n'a pas besoin d'être connectée) et de s'assurer que le message sera bien délivré dans les meilleurs délais.
Dès que le destinataire rejoindra un des chans sur lesquels le bot se trouve ou qu'il y parlera, donc dès qu'on pourra être certain qu'il y porte attention, un message lui sera affiché afin de lui indiquer qu'il a des messages non-lus.
Il pourra alors taper !lire (par défaut) pour les recevoir.
Si l'utilisateur ne lit pas ses messages, un rappel lui indiquant qu'il a des messages en attente s'affichera toutes les 30mn (réglable) s'il manifeste sa présence en parlant. Ce compteur de 30mn est réinitialisé si de nouveaux messages lui sont envoyés entre temps.
Lorsqu'un message est reçu, un accusé de réception est automatiquement envoyé Ã l'expéditeur pour l'en informer (optionnel).
Il est également possible pour le destinataire de confirmer avoir lu le message au moyen de la commande !lu <n° d'identifiant du message> (optionnel). Si une confirmation de lecture est envoyée, elle remplace l'accusé de réception.
Concernant la confidentialité, MDS s'assure du mieux qu'il peut qu'il ne délivrera pas un message à la mauvaise personne.
De plus, si l'identité de l'expéditeur d'un message présente une incohérence, le fait sera signalé au destinataire ainsi qu'une estimation du niveau de confiance qu'il peut lui accorder en fonction du nombre et de la gravité des anomalies détectées. Il sera alors libre de lui accorder ou non du crédit.
Ce système fonctionne conjointement avec les handles enregistrés sur l'eggdrop (et leurs listes de hosts associés), la vérification d'identité auprès de NickServ ou tout serveur de nick similaire (si disponible) et le recoupement de diverses informations disponibles afin de détecter les anomalies.
Avoir un nick enregistré ou un handle sur l'eggdrop augmente donc considérablement le niveau de sécurité et permet de s'assurer que personne ne pourra lire vos messages à votre place. Pour ceux qui n'ont ni handle, ni nick enregistré, le bot ne pourra faire mieux que de délivrer le message à la première personne portant le même nick.
Veuillez noter que le bon fonctionnement de ce système repose en partie sur une liste d'accès bien tenue, avec des masques de hosts pertinents et aussi précis que possibles (je parle évidemment de la liste d'accès de l'eggdrop).
Si vous utilisez des handles génériques, il est possible de les déclarer afin que le système de sécurité de MDS n'accorde pas trop de crédit à la reconnaissance par handle en ce qui les concerne.
L'idée de base d'un handle générique est de regrouper plusieurs utilisateurs ayant un host identique (utilisateurs d'un même bnc, d'un cybercafé, etc..) sous un même handle dit "générique".
Si l'on tente d'envoyer un message trop long pour être affiché intégralement chez le destinataire, le bot nous en informe et affiche la limite à ne pas dépasser. Cette limite est dynamique et est calculée en fonction du nom du chan, du nick de l'expéditeur, de la fioriture que vous avez choisie pour rendre bien visibles les messages recus, etc...
L'activation/désactivation du script sur chaque chan se fait au moyen de la commande de partyline .chanset #nomduchan [+/-]MDS
Notez que ceci concerne uniquement l'utilisation des commandes de la messagerie, ce qui veut dire qu'une personne ayant un message et manifestant sa présence sur un chan inactif sera quand même avertie qu'elle a un message non-lu.
Il est possible d'utiliser MDS pour envoyer des messages à des utilisateurs depuis d'autres scripts, une procédure existe dans ce but précis.
Voici comment utiliser cette fonction :
send_msg_to <destinataire>[,destinataire,...] <nom_du_script_appelant> <message>
- Le nom du ou des destinataires peut être un nick ou un handle.
- nom_du_script_appelant doit être le nom du script qui envoie le message.
Le destinataire recevra le message sous la forme :
"Message de nom_du_script_appelant envoyé le xx/xx/xxxx à xxhxx : blablabla".
MDS déclare le package "MDS" afin que vous puissiez vérifier sa présence depuis d'autres scripts au moyen de "package require MDS".
Les messages envoyés par ce biais ne sont pas soumis au contrôle de longueur minimale et maximale du message ou du nombre maximum de destinataires, et l'anti-flood ne s'en occupe pas. Soyez donc responsable dans la façon dont vous l'utilisez.
Commandes par défaut :
Envoyer un message depuis un chan :
!msg <destinataire>[,destinataire,...] <message>
Envoyer un message depuis un message privé :
/msg nom_du_bot msg <destinataire>[,destinataire,...] <message>
Recevoir ses messages non-lus depuis un chan :
!lire
Recevoir ses messages non-lus depuis une commande privée :
/msg nom_du_bot lire
Confirmer la lecture d'un message depuis un chan :
!lu <n° d'identifiant du message>
Confirmer la lecture d'un message depuis un message privé :
/msg nom_du_bot lu <n° d'identifiant du message>
Afficher la liste des destinataires ayant des messages en attente :
!messages
Changelog :
1.0
- 1ère version publique
1.01
- Correction : demander l'affichage de la liste des destinataires ayant d'un message ne provoque plus d'erreur si ladite liste est vide.
- Correction : créer manuellement le fichier base de données plutôt que le laisser être créé automatiquement n'empêche plus le script de fonctionner.
1.02
- Correction : lorsque le bot détectait une anomalie dans l'identité du destinataire, une erreur se produisait parfois.
- Correction : terminer la liste de destinataires par une virgule (lors d'un envoi multi-destinataires) ne pose plus de problème.
- Correction : dans certains cas, relever ses messages au moyen de la commande "/msg nomdubot lire" provoquait une erreur.
- Correction : la version d'eggdrop est désormais correctement détectée.
- Correction : la confirmation d'envoi à plusieurs destinataires s'affiche maintenant correctement.
- Ajout : une nouvelle option permet de régler un délai avant de signaler à un utilisateur qu'il a de nouveaux messages lorsqu'il rejoint un chan.
2.0
- Restructuration importante du script : sécurité renforcée contre les fraudes, refonte du fonctionnement interne, modification du format de la base de données (si vous possédez une base de données d'un ancien format, elle sera automatiquement convertie).
- Correction : le cas où un destinataire a des messages à la fois sur son nick et sur son handle (et que ces 2 derniers sont différents) est maintenant géré.
- Modification : l'activation/désactivation du script sur un chan se fait maintenant au moyen d'un flag udef (.chanset #nomduchan [+/-]MDS)
Veuillez noter que le script est activé par défaut sur tous les chans lors de son 1er lancement.
- Ajout : si un utilisateur a déjà pris connaissance d'un accusé de réception, il n'est plus possible d'envoyer une confirmation de lecture en plus. Ceci évite de recevoir des doubles confirmations.
- Ajout : une nouvelle option permet d'imposer une longueur minimale aux messages envoyés.
- Ajout : protocole permettant à d'autres scripts d'utiliser MDS pour envoyer des messages aux utilisateurs.
- Correction : bugs divers
2.1
- Correction : meilleur gestion des caractères spéciaux dans les nicks
- Correction : bug lors de la vérification d'identité au cas où Nickserv n'est pas disponible (merci à qr3nt)
- Modification : en raison des problèmes rencontrés par les utilisateurs n'ayant défini aucun chan statique dans leur fichier eggdrop.conf, la messagerie n'est désormais plus activée automatiquement sur tous les chans lors du 1er lancement du script. Vous devrez donc l'activer manuellement sur chaque chan au moyen de la commande : .channel set #nomduchan +MDS (Ã taper en partyline)
- Ajout : nouvelle option permettant de fixer une limite au nombre de messages qu'un même utilisateur peut avoir en attente (option max_messages_per_recipient). Les accusés de réception et les confirmations de lecture ne comptent pas.
- Modification : il n'est maintenant plus possible d'envoyer un message à l'eggdrop.
- Modification : si l'option permettant d'envoyer une confirmation de lecture est désactivée (option AR_enabled), l'id du message n'est plus affiché au destinataire car cette information est inutile.
- Ajout : nouvelle option (admin_flags) permettant selon leurs flags, d'exempter certains utilisateurs des restrictions suivantes lors de l'envoi d'un message : contrôle du nombre maximum de destinataires (option max_recipients), contrôle de flood lors de l'envoi de messages (option cmdflood_msg) et contrôle du nombre maximum de messages en attente pour un destinataire donné (option max_messages_per_recipient)
- Ajout : nouvelle option permettant de définir un délai après lequel un message en attente expirera si son destinataire ne l'a pas lu (option message_lifetime). La durée de vie d'un message est exprimée en jours.
Lorsqu'un message expire, il est supprimé de la base de données. En raison de cet ajout, la structure de la base de données a changé. Votre ancienne base de données de messages sera automatiquement convertie vers le nouveau format après en avoir fait une copie de sauvegarde. Si vous aviez encore une base de données au format v1.x, elle sera de même convertie au format v2.1.
La vérification des messages expirés a lieu une fois par jour juste après le backup de la base de données.
2.11
- Correction : la vérification des messages expirés provoquait une erreur.
Post support et commentaires ici