Bonjour Patrick,
Il s'agit d'un bug, que je viens de créer dans notre Jira:
http://ci-obm.linagora.com/jira/browse/OBMFULL-5629.
Cordialement,
David
Le 09/12/2013 18:03, Patrick BOSSARD a écrit :
Bonjour à tous
Je suis face à un pb étrange concernant une utilisatrice et ses mails
de rappels d'evt (eventalert)
Coté configuration de son compte, elle a une valeur d'alerte par
défaut spécifiée dans ses préférences (que je retrouve bien dans
userobmpref)
obm=# select * from userobmpref where userobmpref_user_id=573;
userobmpref_id | userobmpref_user_id | userobmpref_option |
userobmpref_value
----------------+---------------------+----------------------+-------------------
470 | 573 | set_todo | todo_priority
475 | 573 | set_cal_last_hour | 18
3021 | 573 | set_cal_display_days | 0111110
3022 | 573 | set_cal_alert | 900
471 | 573 | set_date | d M Y
(5 lignes)
Elle accepte toutes les notifications par email, et reçoit
parfaitement toutes les invitations/notifications d'evts
Pourtant, en créant un evt par défaut en création rapide (double click
+ titre + validation), aucune entrée n'est inscrite dans la table
eventalert.
J'ai fait Le test suivant avec l'utilisateur concerné (id 573) :
Création de 3 evt avec alertes :
* event_id=439733 : alerte par défaut defaut : en complétant le RDV
* event_id=439735 : alerte defaut2 : creation rapide, en ne faisant
que le valider (du coup, quand je le consulte, je ne vois pas
d'alerte ...)
* event_id=439736 : alerte manuelle où j'ai configuré l'alerte
manuellement à 10 mn.
Aucune alarme n'est crée dans la table eventalert pour L'evt 439735 :
obm=# select * from eventalert where eventalert_user_id=573 order by
eventalert_event_id;
eventalert_timeupdate | eventalert_timecreate | eventalert_userupdate |
eventalert_usercreate | eventalert_event_id | eventalert_user_id |
eventalert_duration
-----------------------+----------------------------+-----------------------+-----------------------+---------------------+--------------------+---------------------
| 2013-01-15 16:07:36.7574 | |
573 | 62488 | 573 |
900
| 2013-12-09 08:22:31.320057 | |
573 | 62512 | 573 |
600
| 2013-12-09 08:17:06.6345 | |
573 | 435596 | 573 |
600
| 2013-11-28 08:21:54.032995 | |
573 | 436950 | 573 |
900
| 2013-11-28 08:20:37.672355 | |
573 | 436951 | 573 |
900
| 2013-12-09 09:39:43.251737 | |
573 | 439215 | 573 |
600
| 2013-12-09 08:18:09.091322 | |
573 | 439216 | 573 |
600
* | 2013-12-09 11:37:59.112713 | |
573 | 439733 | 573 |
900*
* | 2013-12-09 11:39:21.528987 | |
573 | 439736 | 573 |
600*
(9 lignes)
Au bout du temps imparti, les alarmes pour les evt 439733 et 439736
sont bien envoyées, mais comme on peut s'y attendre, rien pour l'evt
439735
Le hic c'est que l'on peut ainsi "zapper" des réunions importantes (ce
qui a été effectivement le cas).
Je n'ai pas la possibilté de mesurer si ce phénomène touche d'autres
agents.
Comment expliquer ce phénomène ? y a il un flag associé au user
désactivant les alarmes par défaut ?
Merci à vous,
Patrick Bossard.
--
Patrick BOSSARD - PDG/IMN/IDM/RIC
IFREMER centre de Brest
BP 70 29280 Plouzane FRANCE
Tel : 02 98 22 44 09 - Fax: 02 98 22 45 46
Email:[email protected]
_______________________________________________
Obm mailing list
[email protected]
http://list.obm.org/mailman/listinfo/obm
_______________________________________________
Obm mailing list
[email protected]
http://list.obm.org/mailman/listinfo/obm
