Ok ! Vu !
Effectivement, maintenant que tu le dis, je fais le rapprochement avec le "$feed_cache = array(...". Dans ces conditions, j'avoue ne pas voir ce qui est bloquant dans cette évolution.
Grace à la comparaison entre les array, on remonte le nombre de catégories, leur nom et le nombre d'images par catégories. En faisant abstraction de la date de mise à disposition de l'image (#images.date_available) qui, à mon sens n'a plus lieu d'être (en ce qui concerne la notification tout du moins), on devrait obtenir toutes les infos nécéssaires et correctes dans le flux.
... Je réfléchis encore...
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).
Je vais peut-être sortir une grosse co...rie mais j'ai une idée qui pourrait permettre de tout récupérer dans le "Tag" et #feeds.cache.
Pourquoi ne pas générer automatiquement un marquant pour chaques catégories (virtuelles et physiques) ainsi que pour chaques images, commentaires,... (et plus si affinités). Ce marquant doit être de la forme la plus simple possible, un bigramme lettre-chiffre suffirait.
Le tout est d'additionner tous les marquants dans le "Tag" de barnabé un peu sur le principe d'un arbre de Huffman. Ainsi, l'utilisateur barnabé aurait un Tag unique de la forme A1B2C5, ou A1 représenterait une catégorie mère physique visible de barnabé, B2 une catégorie mère virtuelle et C5 une image de la catégorie virtuelle B2.
Si l'admin supprime l'accès de barnabé à la catégorie B2, on aura alors la chaine Tag = A1. En comparaison avec l'état précédent stocké dans #feeds.cache, on retrouve la catégorie supprimée.
Je sais, c'est un peu confus. Je viens de pondre çà sans trop réfléchir aux implications. Je vais creuser la question si mon approche parait acceptable.
Et puis, la longueur de la chaine ainsi générée risque d'être illimitée et peut poser un pb.
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.
zOrglub a écrit:
- 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)
Ennuyeux, effectivement... Et avec un Tag supplémentaire comportant le cumul des catégories accéssibles par barnabé et comparé au #feeds.cache ?
Ce qui donnerai :
- t1 : 3 catégories (animaux, paysages, people) toutes accessibles à l'utilisateur barnabé -> Tag "barnabé" = C3
- 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é -> Tag "barnabé" = C3-1 => C2
- t4 : barnabé interroge son flux RSS, en branche 1.5, 1 catégorie supprimée (reste à savoir laquelle...)
- t5 : l'administrateur ajoute 2 catégories (N&B et business), inaccessibles à barnabé -> Tag "barnabé" = C2
- t6 : barnabé interroge son flux RSS, aucune nouveauté
- t7 : l'administrateur rend la catégorie N&B accessible à barnabé -> Tag "barnabé" = C2+1 => C3
- t8 : barnabé interroge son flux RSS, en branche 1.5, 1 nouvelle catégorie.
ou considérer que c'est beaucoup de réflexion pour pas grand chose finalement
Personnellement, je ne pense pas. Pour moi, PWG est très bien en tous points. Mais la gestion des upload et la notification (qui nous intéresse ici) pourrait être mieux. Et une mauvaise info de notification peut être dommageable pour les users.
C'est un avis très personnel et motivé par l'emploi que je fais de PWG.
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.
J'aimerai bien aider sur cette partie qui m'intéresse beaucoup mais tout n'est pas complètement câblé dans ma tête pour tout comprendre sans fautes...
Je vais résumer les propos de zOrglub pour voir si j'ai bon ou si je suis à l'ouest :
Le #feed_cache est un champ tableau identifié pour un flux RSS, donc pour un user et reprend les catégorie visibles par ce user. Il est initialisé à une certaine valeur qui est comparée à un tableau "caché" en base au moment de la requète de flux RSS.
C'est là que je pense avoir raté une marche : Ce tableau "caché", il est défini par quoi ? Serait-il de la forme Id_user, Catégories_visibles, Nb_images_dans _catégorie, ... ?
Je suis largué, hein ?
Désolé....
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 ?
nous sommes exactement sur la même longueur d'onde !!!!
merci.
eric.
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.
Au fait, la notification RSS (que je ne maitrise pas d'ailleurs :o) ne me donne pas le nom précis de la catégorie mise à jour, juste un lien vers la page d'accueil du site.
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. ??....
ouarf!
et sinon :
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.
je suis tout à fait d'accord !
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.
- 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.....
- 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.
- le fichier include/conf_local pourrait être utilisé pour valider cette fonction, mais aussi pour valider ou non les paramètres inclus dans le mail (nbe images, terme utilisé : image ou éléments.., nbe commentaires, etc....)
eric.
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.
Dans la version 1.6.0, sera incorporer la notification des nouveaux éléments par mails qui se base sur le même moteur de recherche des éléments.
Que pensez-vous des évolutions suivantes pour le fils RSS et les mails:
o pour chaque ligne "nouveaux ???" associé un lien sur la recherche d'éléments avec les bons paramètres pour les retrouver!
o Modifier le libellé "nouveaux éléments" car éléments n'est pas forcement clair pour les utilisateurs. Je mettrai images mais vu qu'il n'y a pas que ca je propose "nouveaux éléments/images"
o Afficher le nombre d'éléments associés au nouvelles catégories en plus des nouvelles images (car par exemple, vous avez ajouté des nouvelles images avec catégories "physiques", la notification est faite mais le user "ruru" n'a pas accés aux catégories... après l'admin créé des catégories virtuelles est donne les droits au user "ruru"... la notification n'indique que les catégories mais pas les éléments/images)
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)