Bonjour rub.

Il y a tellement de topics sur ce forum que je suis passé à coté de celui là qui m'interesse pourtant particulièrement (mais visiblement, mis à part toi, je suis le seul...).

rub a écrit:

Ce qui donnera:
o 4 nouveaux commentaires utilisateur
o 37 nouveaux éléments/images
o 39 catégories mises à jour (contenant 955 nouveaux éléments/images)

Je vote pour. Personnellement, j'irai même encore plus loin : Pourquoi ne pas donner la possibilité au webmaster d'ajouter un (court) texte libre au mail et au RSS de notification ? Ce texte serait généralisé pour tous les "abonnés" à la notification que ce soit par mail ou par RSS. Pas question ici  de commencer à cibler un tel ou un autre ou un groupe de quidam recevra le texte additionnel.

J'explique mon raisonnement fondé sur un besoin perso :

Sur mon site, j'impose aux visiteurs souhaitant s'enregistrer de spécifier une adresse email valide et fonctionnellle bien que (dixit zOrglub) l'email devient négligeable en branche 1.5. Ceci me permet néanmoins d'avertir les nouveaux "enregistrés" que leur accès a été validé.

Bref, récemment, un user n'a pas joué le jeu et m'a mis un email d'apparence valide mais ne débouchant nulle part (le filou). Et pas moyen de l'avertir bien entendu. Par contre, je sais qu'il s'est enregistré sur le RSS. Un petit message par le flux aurait réglé le pb.

Il y a plein d'autres applications possible comme annoncer à tous que la galerie est fermée pour maintenance par exemple.

Voilà, je relance donc la discussion sur ce sujet qui, j'espère, intéressera du monde.

vimages a écrit:

- n'oubliez pas que toutes annonces de mises à jour automatiques par flux comme par mail doivent être absolument subordonnées à l'autorisation pour le destinataire d'accéder aux dossiers concernés.....

Celà va de soit. Je ne vois pas l'intérêt de notifier les users sur des modifs de galeries dont ils n'ont pas accès. Mon second site, par exemple, n'affiche aucune galerie si on est un guest. Il faut absolument s'enregistrer pour voir quelque chose. Dans ce cas, les notifications pour les guests sont inutiles.

- l'ajout de texte dans le mail devrait en effet être possible...  mais si l'envoi est automatique lors de la synchro des nouvelles images ( logique car le faire manuellement conduira toujours à des erreurs ou des oublis..) , cela implique de pouvoir modifier le corps du mail en amont.

D'accord... et pas d'accord. En fait, j'imagine l'ajout d'un texte additionnel à la notification par une simple zone de texte dans la partie Admin de PWG (pourquoi pas dans la section "Configuration"). Cette zone de texte serait activée par une case à cocher. Case cochée = Tous les users abonnés à la notification RSS et / ou mail recoivent le message même s'il n'y a pas de remontées de modifications sur les galeries. Case décochée = Notification classique habituelle.

Je pense que celà doit rester une fonction d'exception pour des évènements bien particuliers comme une annonce de galerie verrouillée pour cause de maintenance.

le fichier include/conf_local pourrait être utilisé

Tout à fait pour ! Cela permettrait à chacun de paramètrer les items de ses notifications à sa convenance; dans la limite des possibilités offertes, bien entendu.

Ca reste peut-être un peu maigre comme spécifs pour une éventuelle intégration au projet.... J'y réfléchi plus amplement et je reviens.

vimages a écrit:

Pensez vous que pour la notification par mail, la fonction joindra au mail (dans le contenu, car dans le titre ça risque de coincer si il y plusieurs catégories) le nom de la ou les cat. mises à jour, et le chemin (l'arborécence) y menant. ??....

+1

C'est vrai que la notification actuelle est très bien mais serait encore mieux en remontant le nom des catégories mises à jour. Et ce, par mail comme par RSS (ne soyons pas radins ;)).

Ca pourrait avoir la forme :

XX catégories mises à jour
         - n éléments / images dans la catégorie Catégorie_mère_N\Catégorie_fille_N\Catégorie_fille_N...
         - n éléments / images dans la catégorie Catégorie_mère_N+x\Catégorie_fille_N\Catégorie_fille_N...
         - ...

De même, pourquoi pas, pour la notification des admins sur une nouvelle inscription :

X nouveaux utilisateurs enregistrés - à valider :
         - Nom_User_1
         - ...
         - Nom_User_X

Si j'osais, je pousserai le vice jusqu'à adapter le texte avec les valeurs transmises. Par exemple :
1 nouvel utilisateur enregistré
x nouveaux utilisateurs enregistrés

Mais, bon, on n'en ai pas là. Si on obtient déja les bonnes remontées de valeurs, ce sera pas mal. Et celà valoriserait la fonction de notification.

Je suis totalement d'accord sur le fond du topic. Il faut donner plus de détails dans le flux RSS, et dans la notification en général. N'oublions pas que la fonctionnalité de notification n'est apparue qu'en branche 1.5 et que j'avoue avoir voulu faire simple pour le premier jet. Donc la liste des nouveaux utilisateurs, les noms des auteurs des commentaires à valider, les chemins complets des catégories nouvelles et mises à jour, ça me semble très bien.

Un problème subsiste toujours depuis l'arrivée de cette fonctionnalité, évoqué pendant la phase de spécification, il n'a pas toujours pas trouvé de solution. Quoique... Pour rappel, le problème est énoncé dans le 2eme post du topic précédemment cité. J'ai peut-être une solution à proposer.

Ajout de la colonne #feeds.cache qui contient un tableau listant toutes les catégories accessibles et le nombre d'images pour chacune des catégories. Ce tableau serait sérialisé avant d'être stocké dans la base. A chaque requête de notification par un lecteur de flux RSS, le tableau est reconstruit pour l'instant présent et comparé au tableau "caché" en base. La comparaison catégorie par catégorie permettrait de détecter les catégories apparues par jeu de permissions entre 2 requêtes de notification.

$feed_cache = array(
  125 => 54, // 54 photos dans la catégorie 125
  145 => 12, // 12 photos dans la catégorie 145
);

Votre avis sur la question ?

Pour bien comprendre, il faut que je donne un exemple concret au problème qui me préoccupe. Imaginons la galerie suivante, à plusieurs instants t:

- t1 : 3 catégories (animaux, paysages, people) toutes accessibles à l'utilisateur barnabé
- t2 : barnabé interroge son flux RSS pour la première fois, il est indiqué "3 nouvelles catégories"
- t3 : l'administrateur rend la catégories "people" inaccessible à barnabé
- t4 : barnabé interroge son flux RSS, en branche 1.5, rien n'est indiqué (alors qu'on devrait dire qu'une catégorie a disparu)
- t5 : l'administrateur ajoute 2 catégories (N&B et business), inaccessibles à barnabé
- t6 : barnabé interroge son flux RSS, aucune nouveauté
- t7 : l'administrateur rend la catégorie N&B accessible à barnabé
- t8 : barnabé interroge son flux RSS, en branche 1.5, aucune nouveauté (alors qu'on devrait dire qu'une catégorie est apparue)

D'où vient le problème ? Lorsque barnabé interroge le flux à l'instant t8, PWG cherchent toutes les photos apparues depuis t6. C'est la date de mise à disposition de l'image au sens global (#images.date_available) qui est utilisé. En effet, PWG ne versionne pas les autorisations d'accès.

La solution que je propose serait qu'à chaque interrogation du flux, PWG fasse une capture de la liste des catégories accessible et que cette liste soit stockée dans #feeds.cache. Ce mécanisme permettrait de voir si de nouvelles catégories sont apparues, indépendamment de toute notion de date de mise à disposition.

En même temps, il s'agit d'un bug assez dur à reproduire et qui n'est intéressant que d'un point de vue très technique... donc c'est surtout rub qui doit comprendre la problématique. Proposer une autre solution éventuellement, ou considérer que c'est beaucoup de réflexion pour pas grand chose finalement.

Tu y es presque. J'ai traduit "cumul des catégories" en "nombre de catégories" (personnellement, je ne sais pas sommer 2 catégories). Dans le cache (rafraîchit à chaque interrogation du flux, je rappelle), indiquer le nombre de catégories ne suffit pas, c'est trop vague, on ne peut pas savoir quelle catégorie est apparue (et je vois dans la reprise de l'exemple que tu l'as bien compris). Il faut donc "cacher" la liste des identifiants des catégories accessibles à l'instant t.

Dans l'exemple précédent, je n'ai parlé que des catégories. Or, les liens virtuels entre images et catégories ne sont pas datés, donc on retombent dans le même cas. C'est pour cela que je propose d'indiquer en supplément le nombre d'image pour chaque catégorie. Dans l'idéal, il faudrait donner les identifiants de toutes les images pour chaque catégorie, mais ça ferait vraiment trop de choses à stocker dans le cache.

En bref, liste des {id catégorie, nombre d'images dans la catégorie} est un bon compromis pour pouvoir donner une information plus juste qu'actuellement.

Eric, ce que tu proposes est l'exacte réplique de ce que je propose 3 posts plus haut :-), sauf que moi, j'ajoute le nombre d'image par catégorie. Je te laisse encore réfléchir pour te rendre compte que tu vas aboutir aux mêmes conclusion que moi normalement (parti comme tu l'es).