rub a écrit:

Par la suite, je pense qu'il y aura d'autres dev ou mod qui vont utiliser le mail (envoie de news, d'informations, ect...) et c'est pour ca que je pense qu'il ne faut pas gérer les email au niveau de la notification mais à un niveau plus global...

OK, fais comme tu le sens :-) Mon besoin personnel est qu'un utilisateur générique "famille" puisse être associé à plusieurs adresse email et que chacune puisse être notifiée par mail de manière indépendante via l'interface d'administration. Je ne veux pas être obligé de notifier systématiquement mon oncle lorsque je notifie mon cousin, alors qu'ils se connectent avec le même compte utilisateur générique.

z0rglub a écrit:

adresse email et que chacune puisse être notifiée par mail de manière indépendante via l'interface d'administration. Je ne veux pas être obligé de notifier systématiquement mon oncle lorsque je notifie mon cousin

Dans ce cas, je prends Thunderbird et je leur fais une petite bafouille à chacun (en plus je la garde).

Je pense que pour une fois tu t'écartes bien trop de la fonction de base de PWG, la gestion des images.
Et si on imagine des envois partiels, les emails devraient être par groupe ou par catégorie (dans ce cas = tous les membres y ayant accès).

z0rglub a écrit:

Je vais trop loin ? c'est pourtant ce qui est possible avec la notification par flux RSS. Chaque utilisateur peut avoir N flux distincts qu'il interroge à fréquence variable.

Bon, ce n'est pas très important dans le fond, tant pis si on ne peut pas notifier indépendamment.

Le flux RSS individuel, tel que tu l'a conçu est très bien.
Je ne dis pas que la notification par mail individuelle ne serait pas bien elle aussi.
Mais on s'écarte, il faut gérer les images, savoir permettre simplement de faire des choses attendues et inattendues (surprenantes).

Allez moi aussi, j'aime faire des concessions (rub garde la notification individuelle dans un petit coin de tes brillantes idées, on ne sait jamais le "chef" a peut être encore une bone justification).

J'ai besoin de définir des paramètres pour la notification par mail (du style un texte perso inclus dans le mail).

Pour ca, 2 propositions:
  o p1: Créer une nouvelle table
  o p2: Utiliser la table #_config

p1 ne me tente pas, donc je partirais plus sur p2.

Par contre, ce qui me géne, c'est que pour la table #_config est chargé entièrement dans $conf, or je n'ai pas envie de charger à chaque fois les paramètres NBM qui ne serviront que pour la NBM.

Donc, je propose de faire évoluer la table #_config pour ajouter un champs type (valeur par defaut 'global').
$conf sera chargée dans les données de #_config where type='global'.

Pour NBM, je prendrais #_config where type='nbm'.

Une fonction load_conf($types = array()) dans functions.inc.php, permettra de charger les tabelaux suivant les types voulus.

Vous être ok?

rvelices a écrit:

Cette variable ne sera pas trop longue quant meme. non ?

Justement si ca sera une variable comme la variable "page_banner" où l'utilisateur pourra mettre ce qu'il lui chante (appelons-la "nbm_mail_content"). Pour la variable "page_banner", c'est pas grave qu'elle soit longue car elle est utilisé sur toutes les pages, par contre, la variable "nbm_mail_content" ne sera utilisé uniquement que pour la notification par mail.

rub a écrit:

Dans [Subversion] r1091, il y a une première maquette de la NBM.
Pour mon histoire de paramètres, je fais quoi? (table #_config, table #_config + type, nouvelle table?)

En ce qui concerne la demande de dev pour les urls complets, je prefere que tu commences a utiliser les fonctions make_xxx_url (meme si les urls sont relatifs) et ensuite je regarderai quel est le meilleur moyen pour rendre les urls complets sans tout casser...

Pour le parametre... S'il faut avoir un seul et independant de la langue de l'utilisateur, tu peux commencer par le mettre dans le config_default (super facile a faire) et on peut decider apres ou le mettre dans la base ...

Juste en passant, en anglais on dit sent et non sended (si tu fais un repassage dans les langues et dans le nom des variables).

cf http://forum.phpwebgallery.net/viewtopi … 415#p32415 sur une petite question concernant $user['forbidden_categories'] pour la notification par mail. (Mis dans un topic à part, car pas uniquement lié à NBM)

rvelices a écrit:

Rub, est-ce que t'as besoin d'un coup de main pour ce developpement (sql, php ou html) ?
C'est pour pouvoir l'integrer dans la 1.6, mais en meme temps il y a risque qu'on se marche sur les pieds ...

Merci...
En fait, je pensais que ce que j'avais fait... était correct... (pour moi le php et l'html, c'est nouveau et je suis preneur de conseil).
J'ai aussi repris le principe de ce qui a été fait c'est à dire de recharger les élements au post, ect...
Ce que j'ai fait n'est pas intégrable dans la v1.6?

rvelices a écrit:

- il y a un moyen tout simple (en utilisant JavaScript) de cocher tout ou rien et ceci sans refaire une demande au serveur

Je voudrais bien connaitre le moyen en JavaScript, par contre, je ne penses qu'on utilise et qu'il faille utiliser le JavaScript pour le dev de PWG, c'est pour ca que je suis parti sur des submit.

rvelices a écrit:

- la fonction do_action_send_mail_notification est appele aussi pour le send et le prepare -> plusieurs requetes sont faites en double, alors que ce n'est pas necessaire ...

Oui, je sais mais dans le dernier commit, les requêtes ne sont plus les mêmes dans les 2 cas.
Il y a deux fois des requêtes car dans le prepare, je recherche la liste des candidats pour la notification et dans le send, je rechcerche les infos pour l'envoi.
J'avais essayé de passer les infos sous formes de tableaux de tableaux pour que dans le post, il ne faille pas refaire les requêtes mais ca n'a pas été concluant et vu que généralement dans chaque post (dans PWG) on refait les requestes.
Je me suis dit que j'allais faire les requêtes 2 fois.
De plus, le fait de refaire les requêtes permet de rafraichir les données

Quelle serait ta solution pour ne pas faire les requêtes 2 fois?