z0rglub a écrit:

- bien respecter les conventions de style (décrites dans la section
  privée du forum). Elles ne sont pas du tout respectées dans les
  fichiers que j'ai lu. Si comme Nicolas tu as du mal avec ces
  conventions, fais ton commit, je reformates et tu étudieras la
  différence.

J'avais commencé les dev sans en avoir eu connaissance.
J'ai simplement appliqué mes normes.
Je vais repasser sur le code (ca doit être les majuscules, ect...)
Mais, si tu refais une passe ca sera parfait... C'est pas toujours simple de se plier à une nouvelle norme....

z0rglub a écrit:

- ne pas nommer include/functions_news_notification.inc.php mais
  include/functions_notification.inc.php car le mot "news" fait penser
  au MOD news, et cela n'a rien à voir.

OK. D'ailleurs, j'aimais pas news mais j'avais rien de mieux ;-)
Les fonctions d'inscriptions/désincriptions seront par contre, je pense, dans une autre unité.

z0rglub a écrit:

- la première des choses à faire, c'est de créer une demande
  "notification par mail" dans l'outil de suivi. On pourra voir
  l'avancée du travail dans les meilleures conditions. Un peu comme
  nicolas et la demande 261.

Je ne savais pas.
C'est fait ici

z0rglub a écrit:

- tu me fais peur en disant "suppression user" ! qui veux-tu supprimer ?

Dans admin/user, il est possible de supprimer un ou des utilisateurs, il faut donc supprimer l'enregistrement présent dans la nouvelle table avec l'id sélectionné. Non?

z0rglub a écrit:

- Le nouveau menu, dans [Administration>Général>Notification] par
  exemple.

ok

z0rglub a écrit:

- pour la nouvelle table, on aura donc un nouveau fichier dans
  install/db :-) et une modification de
  install/phpwebgallery_structure.sql

sur...

z0rglub a écrit:

- que veux-tu dire par "pas d'intarface" ? Je pensais que tu ferais une
  liste des utilisateurs ayant un mail, avec la possibilité de notifier
  les utilisateurs sélectionnés ou tous les utilisateurs, ou ceux d'une
  liste de groupes, etc. Avec en face de chaque utilisateur la
  date/heure de la dernière notification. Avec bien sûr une gestion
  multipage (donc il faudra qu'on réfléchisse ensemble à factoriser avec
  la page [Administration>Identification>Utilisateur]), bref, un truc
  chiadé :-)

Par interface, uniquement un contenu dynamique comme des listes, ect...
Je pensais effectivement à un truc comme tu as décrit...
Je voyais aussi par suite des nouveaux groupbox sur l'interface pour gérer les futurs/probables parmètres modifiables par les admin.
Tout à fait ok, pour faire un truc multi-page...
On pourrait comme le panier fait un mode mode global | mode unitaire.
Par le menu admin/notification, le mode global
A partir du menu admin/user, le  mode unitaire...

z0rglub a écrit:

- concernant les étapes, je suis OK sur le principe évidemment. La règle
  à respecter est la suivante : chaque commit dans Subversion aboutit à
  un état stable. On ne commit pas une modification qui va tout casser
  chez les copains.

C'est évident!

rvelices,

Alors...

Le chey_key va effectivement servir pour le subscribe/unsubsribe des utilisateurs par liens.
Ca permet d'avoir un clef unique sur plusieurs caractères non séquentiel.
Le user_id étant trop simple pour ce cas.
C'est le même principe que la notification RSS.

Pourquoi une nouvelle table:
  o Même principe que la notification RSS
  o Dans le schéma actuelle, les tables user sont nombreuses
  o La table user_infos est plus à mon gout la table user_parametre ou user_config

Sinon, effectivement, la notification par mail est dans l'ensemble apprécié par tous (exemple de mon site perso), même belle-maman et maman ont compris... ;-) [Ma mère vient d'avoir son 1er pc de we, et d'ailleurs maitrise parfaitement la navigation dans PWG... comme quoi, PWG une application à la simple et puissante...]

Mais, hormis le fait de "remplacer" la notification RSS car Maman Rub n'y pige rien au RSS, il faut aussi voir la notification par mail comme un complement indispensable de la notification par RSS.

En effet, même si les infos sont les mêmes, la grande différence est que la notification RSS est effectuée sur demande de l'utilisateur quand il veut
alors que la notification par mail est faite sur ordre du webmaster pour une action bien précise (ajout de photos, ect...).

J'ai plein de petites idées pour essayer de rendre sympa le NBM, mais le temps n'est pas tjs la, j'espère rendre une copie assez sympa pour la 1.6.

D'ailleurs, j'ai un collègue béta-testa qui l'utilise et me remonte plein de petites demandes...


A suivre donc...

Effectivement, on aurait pu faire un hash, mais j'ai gardé la même philosophie que ce qui avait été fait.

Oui, j'avais dans l'idée de mettre des liens (lesquels exactement, je ne sais pas encore?[categ, recherche, plus récents, etc...]) pour accéder aux nouveautés. (donc une meilleure gestion des liens categ privé, serait bien venu)

Pour les tables, chacun ses gouts, moi j'aime bien divisés en parties fonctionnelles. Je pense que ca doit être pour ca que la table user a été découpée recemment en user et user_info. Et puis, il faut voir aussi que seules les user avec mails sont présents dans la table notification.. mais bon, pas de "polémique"... rire...

Pour la stucture de la table:
  o c'est du (0,1) entre la table user et notification.
  o c'est du (1,1) entre la table notification et user
  o la PK de la table notification est bien le user_id (comme le reste)
  o une clef unique est posée sur check_key (pour unicité et traitement sql)


Par contre pour les liens, j'ai pe besoin de ton aide (rvelices et les autres).
J'ai regardé vite fait dans le code et pour le chemin des fichier php on utilise des chemins relatifs (normal) par contre dans mon mail, je voudrais avoir l'adresse complete (comme qd on passe le curseur sur un lien et que l'adresse s'affiche dans la barre du bas). Et je ne veux pas utiliser le paramètre gallery_url qui n'est qu'un point d'entrée (par exemple mon site à l'adresse www.yyy.fr\pwg mais je communique sur www.yyy.fr).

Comment faire par exemple pour afficher dans le mail par exemple "http://site.free.fr/phpwebgallery/category.php?cat=recent_pics" "category.php?cat=recent_pics" étant le seule partie connue?

Etant débutant en php, je suis sur qu'on va me trouver la solution en 2 secondes...

comme ca à chaud 2 facons de faire:
  o faire une nouvelle table email supplémentaire (adresse supplémentaires disponible pour tous les autres dev)
  o ajout un champs email dans la table de notification par mail (adresse uniquement pour Notification)

La question est donc (outre l'aspect technique, cette liste d'email doit elle servir que pour la notification par mail ou pour les fonctionnalités de pwg?

rub a écrit:

Par contre pour les liens, j'ai pe besoin de ton aide (rvelices et les autres).
J'ai regardé vite fait dans le code et pour le chemin des fichier php on utilise des chemins relatifs (normal) par contre dans mon mail, je voudrais avoir l'adresse complete (comme qd on passe le curseur sur un lien et que l'adresse s'affiche dans la barre du bas). Et je ne veux pas utiliser le paramètre gallery_url qui n'est qu'un point d'entrée (par exemple mon site à l'adresse www.yyy.fr\pwg mais je communique sur www.yyy.fr).

Comment faire par exemple pour afficher dans le mail par exemple "http://site.free.fr/phpwebgallery/category.php?cat=recent_pics" "category.php?cat=recent_pics" étant le seule partie connue?

Etant débutant en php, je suis sur qu'on va me trouver la solution en 2 secondes...

Tu peux utiliser la fonction cookie_path .

z0rglub a écrit:

Peux-tu expliquer de manière complète le principe de fonctionnement ? (je ne comprends pas l'intérêt de #user_mail_notification.check_key pour l'instant).

Le #user_mail_notification.check_key, pour les dev fait à ce jour, n'est pas d'une grand utilité.
Mais il va servir par la suite pour communiquer avec le site. Le #user_mail_notification.check_key sert donc de clef de controles.
Pratiquement, dans le texte du mail envoyé aux utlisateurs, il y aura les petites phrases du style:
  => Pour vous désinscrire, cliquez sur le lien suivant.
  => Pour vous inscrire, cliquez sur le lien suivant.
Ce lien sera http:\truc.fr\pwg\unsubcribe.php?chech_id=jshjdshjkhjkfhjkhdj.

z0rglub a écrit:

A ma connaissance, dans PWG, les mails sont utilisés uniquement pour le changement automatique de mot de passe. Cette fonctionnalité sera désactivée pour les utilisateurs de type générique.

Tout à fait d'accord

z0rglub a écrit:

Aujourd'hui, l'adresse email est dans la table #users. Elle est unique pour chaque utilisateur. Je rappelle que cette table peut être externalisée. Si je faisais le dev, je mettrais l'adresse mail dans #user_mail_notification.mail_address. Le lien avec la table #users via #user_mail_notification.user_id permet uniquement de déterminer la liste des catégories accessibles, afin de limiter la notification aux éléments pertinents.

Et dans ce cas, on perd le lien pour l'envoi des mots de passe car la table #user_mail_notification ne doit être utilisée que par la notification.
En fait pour moi, j'ai plusieurs solutions à soumettre mais ca dépend de comment on veut gérer la liste d'email... explication à la suite...

z0rglub a écrit:

La date de notification par mail est liée à la table #user_mail_notification, tout comme la date de notification par flux est liée à la table #user_feed.

Ca, c'est bien evident

z0rglub a écrit:

Je rappelle qu'un utilisateur de #users peut avoir N flux différents, chacun complètement indépendant. C'est utile pour des gens comme moi, qui utilisent un flux au boulot et un autre flux à la maison, je reçois les notifications 2 fois évidemment, mais je n'en perd aucune.

Ce qui totalement vrai pour la notification RSS mais pas pour celle par mail (cf mon petit layus sur les différences mail/rss...)

Ma question n'est pas vraiment ca!

Prenons des exemples:
user normal ruben n'a besoin d'un seul enregistrement dans la table (il est tout seul et puisque c'est pas lui qui fait la demande d'envoi de mail, il n'y a qu'un flux...
=> Pas de soucis avec le schéma actuel

user generique "famille ruru", email pour belle-maman et mamynou, faut-il 1 ou 2 flux?

Si 1 flux (1 ligne dans table #user_mail_notification), belle-maman et maminou recevrons les mêmes infos, si beau-papa s'ajoute, la date de dernière notification sera la même que pour les 2 autres

Si 2 flux (x lignes dans table #user_mail_notification), belle-maman et maminou recevrons les mêmes infos, si beau-papa s'ajoute, la date de dernière notification sera différente (à null) que les 2 autres jusqu'a la prochaine notification.

Schéma:
Si 1 flux, on peut faire:
  o nouvelle table email (user_id, principale, email_adress) , suppression email_adress de #users
  ou
  o on stocke les email_adresse séparé par des ";" dans un même champs
  ou
  o nouvelle table email_alias (alias_id, email_adress) (n lignes par id) dans #user ajout alias_id  et suppression de email_adress

Si 2 flux:
  o ajout email_adresse dans #user_mail_notification. Dans #user, l'adresse principale reportée dans #user_mail_notification et ajout de x lignes nécessaises pour le reste des email
  ou
  o ajout email_adresse dans #user_mail_notification. Nouvelle table email_alias (cf au dessus) modif #user (cf au dessus). Report de toutes les adresses dans #user_mail_notification.


Je n'ai pas vraiment de choix préféré des besoins, si c'était moi de trancher, je dirais 1 flux et un seul par user_id pour la notification par mail et ajout de la table email_alias.

Si je faisais le dev, j'aurai comme clef primaire de #user_mail_notification le couple {user_id,mail_address}. C'est tout simplement la solution la plus souple. Pour un jeu de permissions donné et une adresse mail. Par défaut, l'adresse email est celle de #users.mail_address, à moins que l'utilisateur en donne une autre.

Je ne sais pas ce que tu comptais faire, mais avec 1 "flux mail", tu comptais n'envoyer qu'un seul mail avec tout le monde en copie ? (ça ne me plairait pas pour mon site personnel) Ou bien envoyer autant de mails que d'adresses email associées au flux ?

Dans tous les cas, fais comme tu le sens. Tu as davantage réfléchi que moi sur la problématique. Prends mes remarques comme des avis, pas comme des obligations :-)

shameleon a écrit:

ca serai bien en plus d'envoyer le mail qu'on puise choisir si on desire qu'il mette aussi ce qui est de noveau (du moin les noveau dossier ou quoi) et pas touteles photo cat ca risque d'etre long si on a mis 200 photo en plus

shameleon, dans le mail, on ne cite pas chaque changement dans une liste exhaustive mais simplement en indiquant le nombre de changements. Regarde ce que fais la modification RSS, c'est les même informations...